supercomputer progress

Number of cores isn't the problem. For fairly tightly-coupled tasks such as simulations, the issue is interconnect latency between cores, and the required bandwidth goes roughly as the cube or Moore's law, so it ran out of gas long ago.

One thing that zillions of cores could do for SPICE is to do all the stepped parameter runs simultaneously. At that point all you need is infinite bandwidth to disk.

I couldn't get out of there fast enough, and have never looked back.

Cheers

Phil Hobbs

It wouldn't need to be as general as that--one could simply sort for the most-connected nodes, and sort by weighted graph distance so as to minimize the number of connections across the chunks of netlist, then adjust the data structures for communication appropriately.

It also wouldn't parallellize as well as FDTD, say, because there's less computation going on per time step, so the communication overhead is proportionately much greater.

The FFTW profiler works pretty well IME, but I agree, doing it with the whole program isn't trivial.

Cheers

Phil Hobbs

In the 1990s meaning of the words, in fact. My 2011-vintage desktop box runs 250 Gflops peak (2x 12-core Magny Cours, 64G main memory, RAID5 disks).

My phone is a supercomputer by 1970s standards. ;)

Cheers

Phil Hobbs

And no more possible to build at that time than in ancient Rome. It's amazing how rapidly technology changes when spurred by the profit motive.

Climate simulation uses enormous multi-CPU supercomputer rigs.

OK, I suppose that makes your point.

My phone probably has more compute power than all the computers in the world about 1960.

And lets you watch cat videos anywhere you go.

At the time I was doing that stuff the FPS-120 array processor attached to a PDP-11 or Vax was the poor man's supercomputer. Provided you had the right sort of problem it was very good indeed for price performance. (it was still fairly pricey)

I got to port our code to everything from a humble Z80 (where it could only solve trivial toy problems) upwards to the high end Cray. The more expensive the computer the more tolerant of IBM extensions they tended to be. The Z80 FORTRAN IV I remember as being a stickler for the rules.

They are basically fluid in cell models with a fair number of parameters per cell but depending on your exact choice of geometry only 6 nearest neighbours in a 3D cubic computational grid (worst case 26 cells).

That is a very regular interconnectivity and lends itself to vector processing (which is why we were using them) though for another problem.

A handful of FLIC practitioners used tetrahedral or hexagonal close packed grids (4 nearest neighbours or 12 nearest neighbours).

When I was involved in such codes for relativistic particle beams we used its cylindrical symmetry to make the problem more tractable in 2D. The results agreed remarkably well with experiments so I see no need to ridicule other FLIC models as used in weather and climate research.

This whole hairball is summarized in Amdahl's Law:

.

Joe Gwinn

Not exactly. There's very little serial execution required to parallellize parameter stepping, or even genetic-algorithm optimization.

Communications overhead isn't strictly serial either--N processors can have several times N communication channels. It's mostly a latency issue.

Cheers

Phil Hobbs

In general, yes. But far too far down in the weeds.

Amdahl's Law is easier to explain to a business manager that thinks that parallelism solves all performance issues, if only the engineers would stop carping and do their jobs.

And then there are the architectures that would do wondrous things, if only light were not so damn slow.

Joe Gwinn

People often focus on the fact that the size of the chip limits the speed without considering how the size might be reduced (and the speed increased) using multi-valued logic. I suppose the devil is in the details, but if more information can be carried on fewer wires, the routing area of a chip can be reduced, speeding the entire chip.

I've only heard of memory type circuits being implemented with multivalued logic, since the bulk of the die area is storage and that shrinks considerably. I believe they are up to 16 values, so four bits in place of one, but I only see TLC which has 8 values per cell. Logic chips are much harder to find using multi-valued logic. Obviously there are issues with making them work well.

Parallelism for exploring a wide range starting parameters and then evolving them based on how well the model fits seems to be in vogue now. eg

Anyone who has ever done it quickly learns that by far the most important highest priority task is the not the computation itself but the management required to keep all of the cores doing useful work!

It is easy to have all cores working flat out but if most of the parallelised work being done so quickly will be later shown to be redundant due to some higher level pruning algorithm all you are doing is generating more heat and only a miniscule performance gain (if that).

SIMD has made quite a performance improvement for some problems on the Intel and AMD platforms. The compilers still haven't quite caught up with the hardware though. Alignment is now a rather annoying issue if you care about avoiding unnecessary cache misses and pipeline stalls.

You can align your own structures correctly but can do nothing about virtual structures that the compiler creates and puts on the stack misaligned spanning two cache lines. The result is code which executes with two distinct characteristic times depending on where the cache line boundaries are in relation the top of stack when it is called!

It really only matters in the very deepest levels of computationally intensive code which is probably why they don't try quite hard enough. Most people probably wouldn't notice ~5% changes unless they were benchmarking or monitoring MSRs for cache misses and pipeline stalls.

Yup. In my big EM code, that's handled by The Cluster Script From Hell. ;)

Well, your average hardcore numerical guy would proably just buy two clusters and pick the one that finished first. ;)

Fifteen or so years ago, I got about a 3:1 improvement in FDTD speed by precomputing a strategy that let me iterate over a list containing runs of voxels with the same material, vs. just putting a big switch statement inside a triply-nested loop (the usual approach).

I mentioned it to another EM simulation guy at a conference once, who said, "So what? I'd just get a bigger cluster."

Cheers

Phil Hobbs

what is fast core memory?

Not so; it's WEATHER mapping and prediction that uses the complex data sets for a varied bunch of globe locations doing sensing, to make a 3-d map for the planet's atmosphere. Climate is a much cruder problem, no details required. Much of the greenhouse gas analysis comes out of models that a PC spreadsheet would handle easily.

A very expensive item:

An oxymoron.