I believe there's a hint towards the end of the article:
> Note: Perlmutter’s “AI performance” is based on Nvidia’s half-precision numerical format (FP16 Tensor Core) with Nvidia’s sparsity feature enabled.
FP16 is a 16 bit floating point format. FLOPS for top 500 are measured with LINPACK HPL, which says it is over 64 bit floating point values (I think):
> HPL is a software package that solves a (random) dense linear system in double precision (64 bits) arithmetic on distributed-memory computers. It can thus be regarded as a portable as well as freely available implementation of the High Performance Computing Linpack Benchmark.
"These FP16 operations are very useful for some kinds of calculations."
ML for example. If you use 16bit precision you can fit the model in half the memory and your lookups are twice as fast. Newer GPU models offer "mixed precision mode" It takes some doing to get that working in your tooling though.
Less than it used to! Apex now offers automatic mixed precision on cublas operations, so you get a good bit of result even without a significant code change.
I'm another user of the predecessor to Conducto. We're using it to orchestrate very large regression test (usually ~40-50k independent processes run as part of the regression testing).
I also use conducto's predecessor to manage "data science" workflows (simlar to https://www.conducto.com/docs/advanced/data-science) on a large computer. It is miles ahead of the alternatives we've tried (and built).
The biggest win we've gotten with conducto comes from the composability. We can ship part of our application as a function which returns conducto nodes. Someone else can call this function an stick it into their own tree (code, not configuration!)
Our integration test suite builds a conducto tree ships containing test code from 4ish different libraries (developed by 2 different teams), each of which includes it's own tree-building functions. Likewise, we ship many of our applications for the large computer as functions which return conducto nodes. Users just call our functions and embed our portion of the workload into their own trees.
I've been going with this style for things like reading files (with retries) or any sort of loop that feels awkward.
while (1) {
int ret = ...;
if (ret == ...) break;
if (ret == some_other_condition) break;
// additional termination conditions....
// do exactly one thing
}
in C, it items[0] could segfault, the fault could be caught by a signal handler which does some unbounded amount of work, then populates the appropriate memory location and returns...
More realistically, the page of memory that items[0] is sitting on could be swapped to disk, requiring the OS to do some big operation.
trying to write a piece of code with the big-O you are looking for generally has a huge number of caveats. I'm undecided on whether this is a feature (abstraction) or a flaw (easily misleading)
And "print items[0]" is actually O(n) where n is the size of the string. Maybe even O(n^2) if the item is a big number and a binary to decimal conversion is required.
But it is doesn't matter here because we have chosen n to be the size of the array, because it is what we are studying.
Here it is big-O "constant time" because the execution time doesn't depend on on the size of the array, assuming it is really big. Not that every call of the function will take the same time to run.
The reality is much more complicated, with things like caches to take into account. As a result, complexities under O(n) often don't mean much in practice. But the higher you go, the more important it becomes. As you get to O(n^2) it is time to take a hard look at your algorithms, or make really sure that n is small and stays small.
I think you (and others) are misunderstanding the purpose of the big-O notation. It is used to discuss about algorithms, not about their implementation.
Another option for interesting generative art would be generative music.
There's tons of opensource audio/music generation software (ChucK, supercollider/overtone, csound, vcvrack), and there's a fun (expensive) world of modular synthesizers lurking around the corner (euclidean rhythm generation is a common technique, many people use logic gates with random of sequenced high/low signals to create interesting patterns, random voltage generation is used for pitches, etc).
If you go super far down the rabbit hole, I've seen examples of people doing generative visual art with a modular synthesizer, modulating video loop parameters, or running oscilloscopes. Anything is possible!
CERN uses PTP on steroids for physics experiments: https://white-rabbit.web.cern.ch/