Which would be a problem with connexions through Paris, where (being a symbol or symptom or French centralism) most big train stations are terminus from one direction. Montparnasse, Gare de Lyon, Austerlitz, Gare de l'Est and Gare du Nord are connected via the subway network (or you can walk a 5 minutes stroll between the last two) but you can still get a connection 'through' Paris when buying tickets.
For an ESL reader who'd gone through hundreds of 'best-seller modern English-speaking' novels and a high technical English fluency, fresh out of To Kill a Mockingbird (which was a shock, I had such a hard time at first) then Salinger and Hemingway, Gatsby was such a wonderful experience - I really didn't care for any character, plot, content... but the way FSF wrote was so compact and different. I can still remember the joy I felt, surprised that 'you can do that in English?'.
Yes, civilian radarstuff (Mode S, SSR, ADS-B as you said, and other multilateration schemes) use 1090 (downlink and broadcast) and 1030 MHz (uplink). Closer to military uses, IFF might also use the same frequencies.
You might need more memory for this secondary training workload. But yeah, donating/selling the 'network' time for high-intensity, low memory footprint workloads (thinking number crunching, monte-carlo stuff, maybe brute-force through a series of problems...) might end up making sense.
I'm thinking of sequences of 'put the sharded dataset through the ten thousand 2kW GPUs, then wait on network - all-reduce - then spike again - a mostly-synchronous all-on/all-off loop. Watching how quick they get to boost-frequency I can see where the worries come from.
Ah thanks, of course. I was thinking of dealing with millions of (Geo)JSON files adding up to terabytes, without copying/duplicating them though, mostly indexing. I used to do that with postgres foreign data wrappers and had hopes for duckdb :-). But that's a question for SO or other forum.
And now I'm curious whether there's a way to actually index external files (make these queries over 600GB faster) and have this index (or many indices) be persistent. I might have missed that when I looked at the docs...
One way to improve performance is to unroll loops and inline code. Unfortunately this increases code size and puts pressure on the instruction cache, making a program sometimes slower. It's probably a lot harder to balance these out in the compiler than to just... sometimes try.
A very good read, thanks for taking the time to put pen to paper and sharing the little useful scripts and tricks. There's a world of heavy-handed hacking out there to use. I used to build hundreds of patched kernels or glibcs to simulate complex systems behaviour (failing read()/write(), incomplete fsync, syscalls in general or the network stack erroring out in all possible ways...) and scenarios of those. Happy to see this explained so simply.
Gets trickier when you're using dGPS. And you need at least 2 antennas/receivers to know direction of arrival. Beamforming in the direction(s) of the expected satellite(s) seems to help a lot with e.g. starlink. But you'll need a phased array and a beamformer.
Not saying it's surprising. My day job is doing exactly this, not in any FAANG.
Working on a platform that hides so many low-level details is a challenge, and the fact people have to go to such length to get access to it is noteworthy. 'maxas' was noteworthy and unneeded on many (most ?) other platforms.
Not saying Intelstuff or armstuff is 'easier' but at least you get access and are tooled to work on the actual low-level asm.
From experience with these kinds of specs, one might be better off clearly stating things that are left to the compiler implementation (and thus should have no impact -?-on the verifiability of the spec).
I'm particularly fond of the Ozaki scheme https://arxiv.org/html/2306.11975v4 and its recent refinements. Hopefully it trickles down to standard HPC libraries soon.
Seems to me there's a trend of applying explicit distributed
systems (network of small-SRAM-ed cores each with some SIMD, explicit high-bandwidth message-passing between them, maybe some specialized ASICs such as tensor cores, FFT blocks...) looking at tenstorrent, cerebras, even kalray... out of the CUDA/GPU world, accelerators seem to be converging a bit. We're going to need a whole lot of tooling, hopefully relatively 'meta'.
I was under the impression (and from experience too) that the very stable oscillators were finicky and sensitive to temperature swings and in general costly to use properly in "hard" environments.
I'm happy to learn this is not the case for every good oscillator. TIL.
I think having Greenland annexed might also be a problem for the Danish. Europe might subsidize Novo Nordisk's losses, switch to distributing the meds all throughout Europe. And it seems the loss of such a society-transformative drug (and having millions of people gaining back all their lost weight would be a difficult/untenable political position for this administration. Just surprised not to see this much in the current news.
Sibling in thread says there's already an US alternative, anyway.
Aside from life-saving medicine, I was thinking that the un-availability (not 'available with tariffs' but 'we're not selling it to the US anymore') of Ozempic in the US might become a political problem, maybe more so than many other trade-war hits. Maybe it's easy to manufacture it locally but the time-gap until it's up and running might be too much to swallow...
You can get a very accurate timestamp from GNSS. What lots of people do then is slave a PLL based on a local oscillator, to be able to get time between two GNSS captations. Or to be able to extrapolate when they have no GNSS signal.
Now suppose someone is spoofing your GNSS signals, it's pretty hard to replace a constellation with another one whilst maintaining time consistency for you. One way to detect spoofing is comparing what a local clock is saying to whatever the GNSS is giving. A local, unfudgeable, stable, accurate clock is a good reference for this.
I think I've seen some amazing Blender hacker put Cycles to the test on a machine with both NVIDIA and Intel GPUs. Love it that their API seems that portable and able to parrallelize on heterogeneous hardware. Amazing software work.
Part of the FFT can be accelerated on GPU hardware, which is full of butterfly-like instructions within warps. Using overlap-and-add/overlap-and-save and cuFFTDx can also make use of heavy parrallelism within shared memory. I had a hard time reproducing the tcFFT paper (for lack of time and tensor core skills I guess) but you can also keep your data in Tensor Core registers too, apparently.
I'm far from able to understand american politics but didn't Dems get far more money in the last election than Republicans? I've read about twice as much? What would big (social media oligarchs/moguls ?) donors flipping back bring about?
With most Machine Learning algorithms I used to get shapley values or other 'explainable AI' metrics (for a large cost compared to simple inference, yes), it's very unsettling and frustrating to work without them now on LLMs.
Ada has asserts, but also pre/postconditions and contracts, invariants, type predicates, not null pointers. Most can be checked statically through SPARK ... with some effort.
All the while I've been calling C and C++ code (hard stuff but C++ interop is ... hard) from Ada for 15+ years and calling Ada code from C too. python from Ada and Ada from python too. Ada from Java through JNI. Writing postgres extensions in Ada. It's not always a panacea but it's possible.