I assume the idea is to have the entire constellation be the data center in question. Laser back haul transceiver bandwidth is in the same order of magnitude of rack-to-rack bandwidths [1][2]. I could see each sat being a rack and the entire mesh being a cluster.
Interesting, the protocol seems to assume symmetrical performance i.e. X-...->Y and Y-...->X will have the same latency so long as they follow the same path?
Very interesting! Nice work on your thesis. I am curious: if the data is not resident on the GPU (e.g. multi-TB datasets, line-rate packet inspection, etc.), is this approached bottle necked by the PCIe bus?
(You may have addressed this in your thesis, feel free to tell me to go RTFD ;)
There also exists cuda-gdb[1], a first-party GDB for NVIDIA's CUDA. I've found it to be pretty good. Since CUDA uses a threading model, it works well with the GDB thread ergonomics (though you can only single-step at the warp granularity IIRC by the nature of SM execution).
True, but unfortunately the response from Stanford has been to introduce triple and quad rooms ;)
This is not entirely their fault. Stanford is subject to Santa Clara County building regulations, and those tend not to be friendly to large university developments (or any large developments for that matter).
I vaguely recall the recent Escondido Graduate Village Residences (EVGR) construction taking a while to get through the regulatory pipeline.
The true underlying issue here is just that there is not enough quality housing for the number of students Stanford admits.
I agree in that freshmen should get the "experience" at least once. However, the way Stanford has arranged housing has meant that a good number of students will not live in a single for any of their 4 years.
Regarding Stanford specifically, I did not see the number broken down by academic or residential disability (in the underlying Atlantic article). This is relevant, because
> Some students get approved for housing accommodations, including single rooms and emotional-support animals.
buries the lede, at least for Stanford. It is incredibly commonplace for students to "get an OAE" (Office of Accessible Education) exclusively to get a single room. Moreover, residential accommodations allow you to be placed in housing prior to the general population and thus grant larger (& better) housing selection.
I would not be surprised if a majority of the cited Stanford accommodations were not used for test taking but instead used exclusively for housing (there are different processes internally for each).
edit: there is even a practice of "stacking" where certain disabilities are used to strategically reduce the subset of dorms in which you can live, to the point where the only intersection between your requirements is a comfy single, forcing Admin to put you there. It is well known, for example, that a particularly popular dorm is the nearest to the campus clinic. If you can get an accommodation requiring proximity to the clinic, you have narrowed your choices to that dorm or another. One more accommodation and you are guaranteed the good dorm.
Great read! I'm sure expensive enterprise tooling exists for busy kitchens to manage safety protocols (or not?), so it is very cool to see high quality tooling for this kind of thing out in the open. After watching so many Chubby Emu videos, I'm definitely scared straight.
Agreed! The gulf between pure-C++ CUDA and PTX is getting larger with these optimizations. My understanding is that Deepseek used PTX instructions that either had no corresponding C++ implemented (like `wgmma` mentioned in the article) or uncommon permutations of modifiers (`LD.Global.NC.L1::no_allocate.L2::256b`).
Arguably the OS includes the entire distribution, not just the kernel. MacOS ships the window server and the entire graphics stack, so the GUI is certainly part of MacOS, and so at least some OSes include a GUI.
There aren't any 1hr+ lectures, just some readings (selected from the manuals in `docs/`) and a bit of exposition from the professor before diving into the lab. Lots of "as needed" assistance
IMO this is kind of the tradeoff. In 140E we do touch on virtual memory (w/ coherency handling on our specific ARM core), FAT32 "from scratch", etc. but it comes at the expense of prerequisites. There is a lot of effort to "minify" the labs to their core lesson, but there is an inevitable amount of complexity that can't (or shouldn't) be erased.
People interested in a "read the manual and code it up on real hardware"-type guide should take a look at Stanford's CS140E[1] repo! Students write a bare metal OS for a Raspberry Pi Zero W (ARMv6) in a series of labs, and we open source each year's code.
[1] https://hackaday.com/2024/02/05/starlinks-inter-satellite-la... (and this is two years ago!) [2] https://resources.nvidia.com/en-us-accelerated-networking-re...