[HN Gopher] Cray-1 vs Raspberry Pi
___________________________________________________________________
Cray-1 vs Raspberry Pi
Author : stare_spb
Score : 323 points
Date : 2023-12-25 00:16 UTC (22 hours ago)
(HTM) web link (www.roylongbottom.org.uk)
(TXT) w3m dump (www.roylongbottom.org.uk)
| timthorn wrote:
| The author's CV is as interesting as the benchmarks
| earthscienceman wrote:
| link?
| timthorn wrote:
| I'm referring to the same page, under the "Background
| Activities" heading
| morbusfonticuli wrote:
| www.roylongbottom.org.uk/Cray 1 Supercomputer Performance
| Comparisons With Home Computers Phones and
| Tablets.htm#anchor1
| brcmthrowaway wrote:
| The author has the most British name ever.
| z3phyr wrote:
| The most British name belongs to Lord British.
| BMc2020 wrote:
| "In 1978, the Cray 1 supercomputer cost $7 Million, weighed
| 10,500 pounds and had a 115 kilowatt power supply. It was, by
| far, the fastest computer in the world. The Raspberry Pi costs
| around $70 (CPU board, case, power supply, SD card), weighs a few
| ounces, uses a 5 watt power supply and is more than _4.5 times
| faster_ than the Cray 1 "
|
| edit: thank you for the Christmas present, yc algorithm. God
| bless us every one.
| wolfgang42 wrote:
| "The comment above was for the 2012 Pi 1. In 2020, the Pi 400
| average Livermore Loops, Linpack and Whetstone MFLOPS reached
| 78.8, 49.5 and 95.5 times faster than the Cray 1."
|
| Apart from the Cray-1, that whole section is also worth reading
| for some interesting insights into relative speed differences
| between various modern CPUs as well. (Though I do wish it was
| presented in table rather than narrative form, it'd be a lot
| easier to follow that way; there are also more detailed tables
| further down the page.)
| LarsDu88 wrote:
| Ok, do Pi 5 now
| moffkalast wrote:
| Multiply Pi 4 results by 3 and you have the rough ballpark.
| jbverschoor wrote:
| I'm more impressed that the cray was that fast such a long time
| ago tbh
| amelius wrote:
| It was even faster in practice because the software was less
| bloated.
| stevenjgarner wrote:
| The primary operating system for the Cray-1 was the Cray
| Operating System (COS), which was a batch processing
| system. COS was specifically designed to exploit the
| hardware capabilities of the Cray-1, focusing on high-speed
| computation rather than on features like multi-user
| support. Given its focus on scientific and mathematical
| computations, COS supported compilers for languages like
| FORTRAN, which was the dominant language for scientific
| computing at the time. The Cray FORTRAN Compiler was highly
| optimized to take advantage of the Cray-1's vector
| processing capabilities. There was also a set of
| mathematical libraries optimized for its architecture.
| These libraries included routines for linear algebra,
| Fourier transforms, and other mathematical operations
| critical in scientific computing.
| pklausler wrote:
| COS supported time-sharing and multiple users quite well,
| actually, including interactive sessions.
|
| Trivia: Seymour was user U0100 on our in-house systems.
| chasil wrote:
| That all began with the CDC 6600.
|
| https://en.m.wikipedia.org/wiki/CDC_6600
| moffkalast wrote:
| > CDC's first products were based on the machines designed
| at Engineering Research Associates (ERA), which Seymour
| Cray had been asked to update after moving to CDC.
|
| > Cray has been credited with creating the supercomputer
| industry. Joel S. Birnbaum, then chief technology officer
| of Hewlett-Packard, said of him: "It seems impossible to
| exaggerate the effect he had on the industry; many of the
| things that high performance computers now do routinely
| were at the farthest edge of credibility when Seymour
| envisioned them.
|
| > One story has it that when Cray was asked by management
| to provide detailed one-year and five-year plans for his
| next machine, he simply wrote, "Five-year goal: Build the
| biggest computer in the world. One year goal: One-fifth of
| the above." And another time, when expected to write a
| multi-page detailed status report for the company
| executives, Cray's two sentence report read: "Activity is
| progressing satisfactorily as outlined under the June plan.
| There have been no significant changes or deviations from
| the June plan."
|
| > Cray avoided publicity, and there are a number of unusual
| tales about his life away from work, termed
| "Rollwagenisms", from then-CEO of Cray Research, John A.
| Rollwagen. He enjoyed skiing, windsurfing, tennis, and
| other sports. Another favorite pastime was digging a tunnel
| under his home; he attributed the secret of his success to
| "visits by elves" while he worked in the tunnel: "While I'm
| digging in the tunnel, the elves will often come to me with
| solutions to my problem."
|
| Well Seymour you are an odd fellow, but I must say you
| design a good mainframe.
| snvzz wrote:
| It'd make more sense to compare with a RISC-V that has Vector
| 1.0.
|
| Because a vector machine is what it was.
| cmrdporcupine wrote:
| Well, or compare to a GPU or a TPU
| snvzz wrote:
| Those are largely simd but not vector.
| cmrdporcupine wrote:
| That's fair. I haven't spent any time looking through the
| RISC-V vector extensions yet. I look forward to it, though.
| rwmj wrote:
| They are said to be "inspired" by classic Cray vector
| instructions, although I have of course never used a Cray
| :-( so I can't comment on how true that is. I did use a
| Convex C2[0] for a while which also had real vector
| instructions, but it was all hidden behind a compiler
| option.
|
| [0] https://en.wikipedia.org/wiki/Convex_Computer
| dan-robertson wrote:
| How is vector different from simd?
| IshKebab wrote:
| The RISC-V Vector extension allows the vector length to
| vary at runtime whereas with SIMD the vector length is
| fixed at compile time (128 bit, 256 bit etc.). It means
| the code is more portable basically.
|
| With x86 SIMD the standard solution is to compile the
| same code multiple times for different SIMD widths (using
| different instructions) and then detect the CPU at
| runtime. Though that is such a pain that it's only really
| done in explicitly numerical libraries (Numpy, Eigen,
| etc.). In theory with Vector you can compile once, run
| anywhere.
| dan-robertson wrote:
| That design seems like a reasonable thing for a high
| level language that could then be converted to different
| architectures' simd widths. But I'm kinda surprised it's
| good at the ISA level. Eg for something like a vectorized
| strlen, mightn't one worry that the cpu would choose
| vlen[1] too large causing you to load from cache lines
| (or pages!) that turn out to be unnecessary for finding
| the length of the string. With the various simd
| extensions on x86 or arm, such a routine could be
| carefully written to align with cache lines and so avoid
| depending on reading the next line when the string ends
| before it. I also worry about various simd tricks that
| seem to rely on the width. Eg I think there's some
| instruction to interpret each half-byte of one vector as
| an index into some vector of 16 things. How could these
| be ported to risc-v? Or maybe that's not the sort of
| thing their vector extensions are meant for.
|
| I guess part of my thinking here is that the ISA
| designers at intel, arm, aren't stupid, but they ended up
| with fixed widths for sse, neon, knights landing, avx,
| avx-512. Presumably they had reasons to prefer that to
| the dynamic risc-v style thing. So I wonder: are there
| some risc-v constraints the push this design (eg maybe
| low-power environments presumably pushed neon to have a
| small width and this made higher-power environments
| suffer; having a dynamic length might allow both to use
| the same machine code), or were there some reasons intel
| preferred to stick with fixed widths, eg making something
| that could only work on more expensive chips and thereby
| having something people can pay more for? Is there
| something reasonable written about why risc-v went with
| this design.
|
| [1] what do you even pass to vsetvl in this case as you
| don't know your string length.
| imtringued wrote:
| I'm not sure it is difficult to see why variable length
| SIMD makes sense. If you want to process 15 elements with
| a width of 8, you will need the function twice, once with
| SIMD processing whole batches of 8 elements and a scalar
| version of the same function to process the last 7
| elements. This makes it inherently difficult to write
| SIMD code even in the simple and happy case of data
| parallelism. With RISC-V all you do is set vlen to 7 in
| the last iteration.
|
| >what do you even pass to vsetvl in this case as you
| don't know your string length.
|
| I'm not sure what you are trying to say here. You must
| know the length of the buffer, if you don't know the
| length of the buffer, then processing the string is
| inherently sequential, just like reading from a linked
| list, since accessing even a single byte beyond the null
| terminator risks a buffer overflow. Why pick an example
| that can't be vectorized by definition?
| dfox wrote:
| Another point is that the CPU can sequence the multiple
| calls to its internal SIMD unit internally without that
| having to be done by user code. This in extreme case
| degrades to the Cray-1-like vector unit, which still has
| measurable preformance impact and can be implementated
| even in very resource constrained environments.
| dan-robertson wrote:
| I wonder if you're using a different definition of
| 'vectorized' from the one I would use. For example glibc
| provides a vectorized strlen. Here is the sse version: ht
| tps://github.com/bminor/glibc/blob/master/sysdeps/x86_64/
| m...
|
| It's pretty simple to imagine how to write an unoptimized
| version: read a vector from the start of the string,
| compare it to 0, convert that to a bitvector, test for
| equal to zero, then loop or clz and finish.
|
| I would call this vectorized because it operates on 16
| bytes (sse) at a time.
|
| There are a few issues:
|
| 1. You're still spending a lot of time in the scalar code
| checking loop conditions.
|
| 2. You're doing unaligned reads which are slower on old
| processors
|
| 3. You may read across a cache line forcing you to pull a
| second line into cache even if the string ends before
| then.
|
| 4. You may read across a page boundary which could cause
| a segfault if the next page is not accessible
|
| So the fixes are to do 64-byte (ie cache line) aligned
| accesses which also means page-aligned (so you won't read
| from a page until you know the string doesn't end in the
| previous page). That deals with alignment problems. You
| read four vector registers at a time but this doesn't
| really cost much more if the string is shorter as it all
| comes from one cache line. Another trick in the linked
| code is that it first finds the cache line by reading the
| first 16 bytes then merging in the next 3 groups with
| unsigned-min, so it only requires one test against a zero
| vector instead of 4. Then it finds the zero in the cache
| line. You need to do a bit of work in the first iteration
| to become aligned. With AVX, you can use mask registers
| on reads to handle that first step instead.
| camel-cdr wrote:
| > what do you even pass to vsetvl in this case as you
| don't know your string length.
|
| To the maximum, of course, `vsetvl x<not 0>, x0, ...`
| will do that for you.
|
| You might read over a page boundery, but there is an
| instruction for that `vle8ff.v`, it's a fault-only-first
| uni-stride load. That is, it doesn't fault when one of
| the later elements goes outside our page, and adjusts the
| vector length accordingly. [0]
|
| > With the various simd extensions on x86 or arm, such a
| routine could be carefully written to align with cache
| lines and so avoid depending on reading the next line
| when the string ends before it.
|
| In practice, on current very early hardware, doing just
| that is faster, and definitely possible. [1]
|
| > I also worry about various simd tricks that seem to
| rely on the width. Eg I think there's some instruction to
| interpret each half-byte of one vector as an index into
| some vector of 16 things
|
| I'm not aware of such an instruction, but rvv has
| vrgather.vv and vrgatherei16.vv to do something similar.
| Note that you can always return to "fixed-size"
| implementations if you really need to, buy just setting
| the vl accordingly. But for the most part I don't think
| this will be necessary. Do you have any specific problem
| in mind that may seem hard to do without fixed size SIMD?
|
| > I guess part of my thinking here is that the ISA
| designers at intel, arm, aren't stupid, but they ended up
| with fixed widths for sse, neon, knights landing, avx,
| avx-512.
|
| I mean, ARM now has something similar with SVE, and x86
| has a metric ton of legacy to work with and the market
| size to get adoption of whatever new instruction prefix
| they add. Edit: Also, didn't AVX10/AVX512vl go into a
| similar direction as SVE?
|
| > Is there something reasonable written about why risc-v
| went with this design.
|
| I'm not quite sure, but I remember that it was one thing
| from very early in the design. I think it's to have a
| mostly unified ecosystem for the binary app market. It
| also makes working with mixed precision easier, because
| it allows for the LMUL model.
|
| But RISC-V is extendable, the P (Packed SIMD) extension
| is currently in the works and aimed at the embedded
| market, for in GPR SIMD operations for DSP type
| applications. [2]
|
| [0] https://github.com/riscv/riscv-v-
| spec/blob/master/example/st...
|
| [1] https://camel-cdr.github.io/rvv-bench-
| results/canmv_k230/str...
|
| [2] https://lists.riscv.org/g/tech-p-ext/topics
| dan-robertson wrote:
| Thanks for all the detailed information! That answers a
| bunch of my questions and the implementation of strlen is
| nice.
|
| The instruction I was thinking of is pshufb. An example
| 'weird' use can be found for detecting white space in
| simdjson: https://github.com/simdjson/simdjson/blob/24b44
| 309fb52c3e2c5...
|
| This works as follows:
|
| 1. Observe that each ascii whitespace character ends with
| a different nibble.
|
| 2. Make some vector of 16 bytes which has the white space
| character whose final nibble is the index of the byte, or
| some other character with a different final nibble from
| the byte (eg first element is space =0x20, next could be
| eg 0xff but not 0xf1 as that ends in the same nibble as
| index)
|
| 3. For each block where you want to find white space,
| compute pcmpeqb(pshufb(whitespace, input), input). The
| rules of pshufb mean (a) non-ascii (ie bit 7 set)
| characters go to 0 so will compare false, (b) other
| characters are replaced with an element of whitespace
| according to their last nibble so will compare equal only
| if they are that whitespace character.
|
| I'm not sure how easy it would be to do such tricks with
| vgather.vv. In particular, the length of the input
| doesn't matter (could be longer) but the length of white
| space _must_ be 16 bytes. I'm not sure how the whole vlen
| stuff interacts with tricks like this where you (a)
| require certain fixed lengths and (b) may have different
| lengths for tables and input vectors. (and indeed there
| might just be better ways, eg you could imagine an
| operation with a 256-bit register where you permute some
| vector of bytes by sign-extending the nth bit of the
| 256-bit register into the result where the input byte is
| n).
| camel-cdr wrote:
| I'm actually doing something quite similar in my, in
| progress, unicode conversion routines.
|
| For utf8 validation there is a clever algorithm that uses
| three 4-bit look-ups to detect utf8 errors: https://githu
| b.com/simdutf/simdutf/blob/master/src/icelake/i...
|
| Aside on LMUL, if you haven't encountered it yet: rvv
| allows you to group vector registers when configuring the
| vector configuration with vsetvl such that vector
| instruction operate on multiple vector registers at once.
| That is, with LMUL=1 you have v0,v1...v31. With LMUL=2
| you effectively have v0,v2,...v30, where each vector
| register is twice as large. with LMUL=4 v0,v4,...v28,
| with LMUL=8 v0,v8,...v24.
|
| In my code, I happen to read the data with LMUL=2. The
| trivial implementation would just call vrgather.vv with
| LMUL=2, but since we only need a lookup table with 128
| bits, LMUL=1 would be enough to store the lookup table (V
| requires a minimum VLEN of 128 bits).
|
| So instead I do six LMUL=1 vrgather.vv's instead of three
| LMUL=2 vrgather.vv's because there is no lane crossing
| required and this will run faster in hardware: (see [0]
| for a relevant mico benchmark) #
| codegen for equivalent of that function
| vsetvli a1, zero, e16, m2, ta, ma vsrl.vi
| v16, v10, 4 vsrl.vi v12, v12, 4
| vsetvli zero, a0, e8, m2, ta, ma vand.vi v16,
| v16, 15 vand.vi v10, v10, 15
| vand.vi v12, v12, 15 vsetvli a1, zero, e8,
| m1, ta, ma vrgather.vv v18, v8, v16
| vrgather.vv v19, v8, v17 vrgather.vv
| v16, v9, v10 vrgather.vv v17, v9, v11
| vrgather.vv v8, v14, v12 vrgather.vv
| v9, v14, v13 vsetvli zero, a0, e8, m2, ta, ma
| vand.vv v10, v18, v16 vand.vv v8, v10, v8
|
| This works for every VLEN greater than 128 bits, but an
| implementation with larger VLENs do have to do a
| theoretically more complex operation.
|
| I don't think this will be much of a problem in practice
| though, as I predict most implementations with a smaller
| VLEN (128,256,512 bits) will have a fast LMUL=1
| vrgather.vv. Implementations with very long VLENs (e.g.
| 4096 bits, like ara) could have a special fast path
| optimizations for smaller lookup ranges, although it
| remains to be seen what the hardware ecosystem will
| converge to.
|
| I'm still contemplating whether or not to add a non
| vrgather version and runtime dispatch based on large
| VLENs or quick performance measurements. In my case this
| would require almost >30 instructions when done
| trivially. Your example would require about about 8 eq +
| 8 and vs 4 shuffle + 4 eq, that isn't that bad.
|
| vrgather.vv is probably the most decisive instruction
| when it comes to scaling to larger vector lengths.
|
| [0] https://camel-cdr.github.io/rvv-bench-
| results/canmv_k230/byt...
|
| PS: I just looked over my optimized strlen implementation
| and realized it had a bug. That's fixed now, and the hot
| path didn't change, just the setup didn't work correctly.
| Findecanor wrote:
| TPUs tend to be specialised for matrix multiplications, often
| at low precision.
| voxadam wrote:
| Has anyone taped out a RISC-V CPU with hardware vector support
| yet?
| snvzz wrote:
| Yes, several, with the Vector 1.0 specification.
|
| Some of them (Kendryte K230, a MCU) have already shipped to
| people.
|
| Years ago, some chips shipped, with 0.7.1 (incompatible, pre-
| ratification). One of them is the TH1520, SoC in some SBCs
| released earlier this year.
| hooverd wrote:
| The RPi, unlike the Cray-1, does not offer ample sitting space.
| wolfgang42 wrote:
| Somebody made a Cray-themed Pi Zero cluster which perhaps fits
| the bill (if you're a mouse, that is): https://www.clustered-
| pi.com/blog/clustered-pi-zero.html
| linker3000 wrote:
| There's also a Z80 build.
|
| https://rc2014.co.uk/1865/crayzee-eighty/
| geerlingguy wrote:
| Nor does it have quite the panache in its spartan design.
| tom_ wrote:
| But for the price of the Cray, even without adjusting for
| inflation, you could buy a useful number of chairs. And just
| think of the electricity cost savings!
| DonHopkins wrote:
| It's not just for sitting. The ultimate hacker fantasy is to
| get laid on a Cray-1 couch!
| m463 wrote:
| yeah, the pi cases have been disappointing.
|
| Few have adequate cooling. (flirc is good, the ones with fans
| are just annoying)
|
| I'd love to have a pi case that had a built-in breadboard.
|
| ...or a case with comfortable seating.
| intrasight wrote:
| I like the Flirc aluminum case. My Pi 5 case arrived last
| week. Now waiting for my new Pi.
| widea wrote:
| Why not?
| nullhole wrote:
| There's a line in the Jurassic Park book where a character is
| made suspicious by an offhand assertion (by Nedry) that he is
| using a _multi XMP system_.
|
| Rpi4s are nice, in a sense, because you can only rarely honestly
| claim that the speed of the system is holding you back. Most
| times, presumably, it's the efficiency of the operations you are
| telling it to execute.
| Firerouge wrote:
| The lack of I/O to the cpu might be the counterpoint to this. A
| single (exposed) PCIe lane might be enough for any singular
| task, but you're likely to start bogging down your bandwidth if
| you need to do any serious simultaneous tasks like network
| above a gbit, nvme disk IO, additional display or additional
| parallel computing like a GPU.
| Cacti wrote:
| it's easy to forget how many bits needs to be pushed down a
| graphics pipeline, per pixel, per frame. in fact forget the
| pipeline, just pushing the bits down the wire fast enough is
| a non-trivial task.
| nullhole wrote:
| I agree. I was a bit too flip in my original comment; there
| are regular tasks now that simply require multiples of the
| data throughput that the 1980s Cray machines were capable
| of.
|
| The simpler point I was aiming at was just that: the amount
| of computational power at the fingertips of so many of us
| is huge, and it's important to appreciate that.
| Uehreka wrote:
| > Rpi4s are nice, in a sense, because you can only rarely
| honestly claim that the speed of the system is holding you
| back.
|
| As someone who uses them for a variety of purposes, I gotta
| note that they have pretty huge limitations. Like, the moment
| graphics enter the picture (no pun intended) you're moving an
| order of magnitude slower than most desktops or laptops. Not to
| mention that support for hardware video encode/decode (which,
| especially decode, we generally take for granted) aren't always
| available depending on the library or tool you're working with.
|
| Like yes, you can totally run a serviceable web server on a Pi
| and serve a blog or a small web app, but let's not get carried
| away here.
| moffkalast wrote:
| Requiring a small nuclear reactor to power it aside, the Pi 5
| feels far more like it's up to the task of a full desktop
| machine. Admittedly I haven't tried anything but headless
| workloads on mine so far, but it's so much snappier it's
| genuinely unreal. I'm really looking forward to seeing how
| much faster lidar localization and just SLAM in general runs
| on it once ROS support is sorted.
|
| Although they did remove the h264 decoder and encoder which
| is a bummer, like you say it's hard to get working support
| for it anyway. Vulkan + regular GPU acceleration might be
| easier. And it still only has 4 cores which is crap for
| desktop multitasking.
| eesmith wrote:
| From the novelization of the movie "War Games", starting at
| https://archive.org/details/wargames00davi/page/n117/mode/2u...
| :
|
| > "Jesus," David said. "That's a Cray 2!"
|
| > "Ten of them." McKittrick said.
|
| > "I didn't know they were out yet."
|
| > McKittrick almost preened. "Only ten. Come on, I want to show
| you something."
| qingcharles wrote:
| I'd just bought the latest and most expensive Intel x86 CPU in
| 2013 and built myself a new rig. My wife walked into the office,
| "You're not working, I can tell that, but I'm not sure what
| you're doing?" she said looking at the graphs on my screen.
|
| "I'm calculating to see when my PC would have been the fastest on
| Earth. It looks like in 1992 it would be able to out-compute the
| latest Dept of Defense $90m supercomputer that filled an entire
| room, would you believe?"
|
| "That's lovely. How will that help us pay our credit bills?"
|
| Jesting aside. There is a bunch of data for this, like this set
| here:
|
| https://en.wikipedia.org/wiki/TOP500
|
| And if you extrapolate backwards or find older data, like I did,
| I came to the conclusion that if I took my PC back to 1981 it
| would actually be faster than every computer on Earth combined,
| or some insane statistic like that.
| kevin_thibedeau wrote:
| The other fun thing is to find out the most recent year your
| phone would have made the bottom of the top 500 list.
| bifftastic wrote:
| Looks like June 2002 for Pixel 8
| hulitu wrote:
| My phone is so dumb down that any comparison is useless. It
| is like driving a Ferrari through a corn field.
| shagie wrote:
| One of my favorite machines from Top500 is SystemX.
|
| https://www.top500.org/system/173736/
|
| When it was commissioned in 2004, this array of 1100x Apple
| PowerPC 970 systems was the 7th most powerful computer on the
| list.
|
| It's Linpack Performance was 12,250.00 GFlop/s.
| iancmceachern wrote:
| My favorite was the 33rd in line at the time which was made
| up of 1700 sony PS3s
|
| https://www.google.com/amp/s/phys.org/news/2010-12-air-
| plays...
| Cacti wrote:
| When the DoE claimed the PS3 could be a dual purpose
| munition, they weren't kidding.
| PaulRobinson wrote:
| Saddam Hussein did try to buy a load of PlayStations at
| some point.
| hulitu wrote:
| He also had WMDs. /s
| iancmceachern wrote:
| And Anna Nicole married for love
|
| (Great line in the movie Shooter"
| Cockbrand wrote:
| They were more or less cousins, as they were both based on
| the PowerPC CPU architecture.
| porbelm wrote:
| However the Sony Cell had just a PowerPC controlling
| core. The real magic, and why it was used in
| supercomputers at the time, is in its Stream cores; they
| were highly tailored for vector and floating point maths.
| geeB wrote:
| About the same headline number as a $350 Xbox Series X!
| Although fp64 vs fp32 and Linpack vs peak.
| zoky wrote:
| You forgot the best part: It was colloquially referred to as
| the "Big Mac".
| shagie wrote:
| First capture - https://web.archive.org/web/20040724145729/
| http://www.tcf.vt...
|
| Last capture - https://web.archive.org/web/20070606024231/h
| ttp://www.tcf.vt...
|
| An FAQ from somewhere in the middle - https://web.archive.o
| rg/web/20060708113430/http://www.tcf.vt...
| Havoc wrote:
| For a second there I thought there was a new sbc called cray.
| Well played
| fastneutron wrote:
| When I see comparisons like this, the first thought I have is not
| the benchmarks, but rather what the most "heroic" real-world
| calculation of the day would have been on something like the
| Cray-1, and how to replicate those calculations today on
| something like a RPi. Weather/climate models? Rad-hydro?
|
| The fidelity would almost certainly be super low compared to
| modern FEA software, but it would be a fun exercise to try.
| ip26 wrote:
| You could always start with loading up Spec '06, which contains
| micro kernels of such "heroic" workloads.
| simbolit wrote:
| One of the early customers was the European Centre for Medium-
| Range Weather Forecasts, so, wild guess, they probably used it
| for medium-range weather forecasts.
| ithkuil wrote:
| > they probably used it for medium-range weather forecasts
|
| in europe
| defrost wrote:
| FWiW Australia used a CDC Cyber 205 for occassional weather
| modelling and other mathematical work in the early 1980s.
|
| ( There was a seperate dedicated weather computer, this one
| was used for 'other' jobs like speculative weather
| modelling, monster group algebraic fun, et al.)
|
| https://en.wikipedia.org/wiki/CDC_Cyber
|
| The UK was the first customer: In 1980,
| the successor to the Cyber 203, the Cyber 205 was
| announced. The UK Meteorological Office at Bracknell,
| England was the first customer and they received their
| Cyber 205 in 1981.
| pietjepuk88 wrote:
| I thought the ECMWF models were (and always have been)
| global?
| jorvi wrote:
| > European Centre for Medium-Range Weather Forecasts
| checkyoursudo wrote:
| Only centred on Europe.
| fastneutron wrote:
| Numerically, I'm currently what this would have looked like.
| I'm talking about the governing equation set, discretization
| methods, data, etc. It would be a fun project to try and
| implement a toy model like that.
| magicalhippo wrote:
| > It would be a fun project to try and implement a toy
| model like that.
|
| If you really want a challenge, do it using pen, paper and
| a slide rule, like in the old days[1]. Just make sure to
| apply appropriate smoothing of the input data first[2].
|
| [1]: https://www.smithsonianmag.com/history/how-world-war-
| i-chang...
|
| [2]: https://arxiv.org/abs/2210.01674
| DonHopkins wrote:
| A Cray-1 could execute an infinite loop in 7.5 seconds!
| ant6n wrote:
| In a similar way how Chuck Norris counted to infinity..
| twice?
| DonHopkins wrote:
| Yes, but without being a homophobic sack of shit!
|
| https://www.thepinknews.com/2021/01/13/chuck-norris-
| homophob...
|
| https://www.theguardian.com/world/2012/jun/27/chuck-
| norris-a...
|
| https://www.thepinknews.com/2017/08/08/chuck-norris-
| endorses...
| belter wrote:
| Quite impressive, but can't avoid noticing you did not, go
| near a higher challenge, like compiling a C++ program in
| under 4 weeks... \s
| bee_rider wrote:
| You could get some vintage matrices from SuiteSparse (formerly
| the university of Florida sparse matrix collection).
| devoutsalsa wrote:
| 3-D rendering? We had a super computing club in early 90s high
| school. I remember creating wireframe images, uploading then to
| a Cray XMP at Lawrence Livermore for the computation, and then
| downloading finished results.
| buryat wrote:
| nuclear weapons simulations
|
| the first machine went to Los Alamos
|
| https://www.theatlantic.com/technology/archive/2014/01/these...
| acqq wrote:
| The demand for the huge calculations for the design of
| nuclear weapons started in WW II already:
|
| https://ahf.nuclearmuseum.org/ahf/history/human-computers-
| lo...
|
| "The staff in the T-5 group included recruited women who had
| degrees in mathematics or physics, as well as, wives of
| scientists and other workers at Los Alamos. According to
| Their Day in the Sun: Women of the Manhattan Project, some of
| the human computers were Mary Frankel, Josephine Elliot,
| Beatrice "Bea" Langer, Augusta "Mici" Teller, Jean Bacher,
| and Kay Manley. While some of the computers worked full time,
| others, especially those who had young children, only worked
| part time.
|
| General Leslie R. Groves, the Director of the Manhattan
| Project, pressured the wives of Los Alamos to work because he
| felt that it was a waste of resources to accommodate
| civilians. As told by Kay Manley, the wife of Los Alamos
| physicist John Manley, the recruitment of wives can also be
| traced to a desire to limit the housing of "any more people
| than was absolutely necessary." This reason makes sense given
| the secretive nature of Los Alamos and the Manhattan Project.
| SEDs, a group of drafted men who were to serve domestically
| using their scientific and engineering backgrounds, also
| worked in the T division."
| fastneutron wrote:
| > rad-hydro
|
| These are incredibly expensive even on today's hardware. If
| you look through some of the unclassified ASCI reports from
| the early 2000s, 3D calculations of this equation set were
| implied to be leadership-class computations. At the time of
| the Cray, it must've been coarse-grid 1D as the standard,
| with 2D as the dream.
| gshubert17 wrote:
| I toured an NCAR (National Center for Atmospheric Research)
| facility in Boulder around 1979; got to sit on a seat on their
| Cray-1. So yes, weather and climate calculations.
| pge wrote:
| Not the Cray-1, but the Navy used a Cray 90 a few years later
| for CFD calculations modeling flow around ship hulls (code
| written in Fortran).
|
| I wish I had access to the code I wrote back then - what took
| minutes or hours on the Cray could probably run in seconds on a
| RPi now...
| whitej125 wrote:
| Years ago when my daughter was around 5 I was showing her a
| raspberry Pi zero I had just picked up. I told her - years ago
| before Daddy was your age a computer like this used to be as big
| as a house. Her response was - "houses were that small?"
| utopcell wrote:
| Smart kid, thinking out of the box!
| speed_spread wrote:
| It comes naturally when the box is so small!
| zx8080 wrote:
| :) Did showing raspPi to your daughter have any result (like
| interested in tech or anything)?
| whitej125 wrote:
| Honestly she loves all her subjects in school. I'd say the
| "engineering tendency" that she picked up from her mom and I
| (both eng) is the desire the go deep on learning something. I
| see it when it comes to math, but equally see it when it
| comes to music or history.
| tonymet wrote:
| Have you seen houses from the 1920s -- she's not that far off
| lagniappe wrote:
| they say the 2020's is the new 1920's in that regard
| bboygravity wrote:
| Have you seen (tiny) houses in 2023s (large cities) -- she's
| not that far off.
| tgv wrote:
| I've lived in them for most of my life. Quite roomy.
| mattnewton wrote:
| In your household, the children tell the dad jokes to dad.
| chacham15 wrote:
| I like telling dad jokes...he usually laughs
| graphe wrote:
| Your dad is named he?
| ben_w wrote:
| He for short, Hehehe is the full name ;P
| nextaccountic wrote:
| Maybe not a house, but depending on your age a large room for
| sure
| blackoil wrote:
| Is there any software apart from benchmarks that will make it
| feel that fast. All softwares that I use feel more advanced
| version of things that I ran on my 386. GUI, IDE, compiler,
| office...
|
| I understand that the exercise may still be theoretical as any sw
| used by Met now will be designed for million time fast computers.
| But there should exist some software that would have required
| Cray to run then.
| xcv123 wrote:
| No. The Cray-1 ran batch processing jobs, mostly scientific
| simulations which took hours or days to compute. It had a
| terminal interface and wasn't used for real time interactive
| applications.
| timthorn wrote:
| IIRC, in real world installations the Cray would have been
| paired with a minicomputer or mainframe.
| yjftsjthsd-h wrote:
| So should we pair with a PiPDP-11?:)
| flyinghamster wrote:
| The Wiki article on the Cray-1 indicates that it had a Data
| General Eclipse as its front-end processor.
| jasonwatkinspdx wrote:
| It was a later machine than the Cray-1, but I remember seeing
| a post on the jsoftware forums from someone that ran
| interactive APL on a Cray. Having a REPL to access a machine
| like that in that era must have been quite something.
| pinewurst wrote:
| Crays were not good interactive machines for a few reasons,
| but lacking virtual memory was the most notable.
| yummypaint wrote:
| The best bet might be an old physics code written in fortran.
| Maybe calculation of scattering cross sections from matrix
| elements or something with alot of vectorizable linear algebra.
| KeplerBoy wrote:
| A lot of the stuff that took hours back then can now be done in
| sub-seconds.
|
| Think about mechanical engineering: Back then they might have
| simulated how cars deform in a crash. Now we can perform
| similar simulations in real-time for fun in our video games.
| Afaik it's hardly ever done because no one actually needs
| physically accurate models in games, but it could be done.
|
| Same goes for rendering back then they rendered each frame of
| toy story for a good few hours, now we achieve arguably better
| graphics in real time.
| Eisenstein wrote:
| > Think about mechanical engineering: Back then they might
| have simulated how cars deform in a crash. Now we can perform
| similar simulations in real-time for fun in our video games.
| Afaik it's hardly ever done because no one actually needs
| physically accurate models in games, but it could be done.
|
| BeamNG is basically that.
| AureliusMA wrote:
| You beat me to it! Such a fun game
| qup wrote:
| I think there's something to be said for the wait period. The
| time to anticipate the result makes it feel very worthwhile,
| especially when only a handful of machines on the planet can
| do the calculation.
|
| It all feels very mundane when I can do it on my slow
| commodity laptop in under a second.
| mikewarot wrote:
| I wonder where a Raspberry Pi Pico - based on the RP2040 fits in
| all of that.
| dgacmu wrote:
| A lot slower - roughly 100x - because most of these benchmarks
| measure FLOPS and the rp2040 doesn't have native floating
| point, so it has to emulate it, taking it down to 1-3 MFLOPS vs
| the 160 MFLOPS of the cray-1.
|
| If you compared integer operations it would be a lot closer,
| but that's not really what the cray was designed for. (The
| rp2040 at 125mhz * 2 cores is in a pretty similar range)
| DonHopkins wrote:
| The Cray-1 has a much better couch.
| qgin wrote:
| We need to bring back computer seating
| Y_Y wrote:
| I've sat on my raspi 3b a couple of times. Can't honestly
| recommend it.
| ianburrell wrote:
| Make seats that are 19" wide and meant to go in front of
| racks. Or ones that are rack-mounted and pull out.
| Animats wrote:
| The Cray-1's padded seats cover the power supplies. I was sad
| to see the Cray-1 at the Computer Museum in Mountain View being
| used as storage for catering supplies for some event in the
| lobby.
| webprofusion wrote:
| Dude fix your website certificate, come on.
| wannacboatmovie wrote:
| This site is served over plain HTTP. Not only does he not need
| to fix anything, you should fix your broken web browser that's
| "upgrading" to HTTPS when no one, especially the site owner,
| asked it to.
| DonHopkins wrote:
| I knew a guy who worked at one of the national labs that had its
| own Cray-1 supercomputer, in a machine room with a big
| observation window that visitors could admire it through.
|
| Just before a big tour group of VIPs he knew would come by, he
| hid inside the Cray-1, and waited patiently for them to arrive.
|
| Then he casually strolled out from inside the Cray-1, pulling up
| the zipper of his jeans, with a sheepish relieved expression on
| his face, looked up startled at the tour group gaping at him
| through the window, and scurried off!
| codezero wrote:
| To which they said, "Urine; A lot of trouble."
| qgin wrote:
| It's wild to imagine that 40 or so years from now, someone will
| have a drawer full of cheap plastic boxes, each with more power
| than the fastest computing cluster of 2023... promising to
| themselves that one day they're finally going to build that hobby
| project with one of them.
| avg_dev wrote:
| such a dystopian future... I hope we are not still using
| plastic then :)
| niederman wrote:
| How is this dystopian? Plastic is a really great material --
| and way more eco-friendly than metal for building computers.
| It's only mass-produced single-use plastics like water
| bottles that are bad for the environment.
| huytersd wrote:
| I wish we could come up with a plastic that would
| biodegrade after a fixed amount of time say 200 years.
| bbarnett wrote:
| You want the stored carbon in plastics to escape??
|
| The best outcome for plastics, would be to bury them very
| deep (like nuclear waste), where they could eventually
| become some new oil like substance. No carbon escape.
| huytersd wrote:
| Yeah but no one is burying the plastic, it's too
| expensive. So realistically I'd much rather have the
| plastic breakdown so it's not everywhere for 10k years.
| djaychela wrote:
| How is it more eco-friendly? AFAIK Most plastics used in
| such applications are not practically recyclable, whereas
| metals are.
| ryandrake wrote:
| Didn't the Apollo guidance computer, which took people to the
| moon, have 4K of RAM? Today, _1 million times_ that barely runs
| the OS and a few Chrome tabs.
| jes wrote:
| I hope the following from Wikipedia is helpful:
|
| The computer had 2048 words of erasable magnetic-core memory
| and 36,864 words of read-only core rope memory. Both had
| cycle times of 11.72 microseconds. The memory word length was
| 16 bits: 15 bits of data and one odd-parity bit. The CPU-
| internal 16-bit word format was 14 bits of data, one overflow
| bit, and one sign bit (ones' complement representation). [1]
|
| 1. https://en.wikipedia.org/wiki/Apollo_Guidance_Computer
| jojobas wrote:
| Russians ran computers with ferrite-plate RAM of similar size
| on submarines well into 90s or maybe even 00s. Still using
| software written for them on Kilo submarines in some sort of
| VMs.
| chasd00 wrote:
| I've looked inside that capsule. I wouldn't ride in it to the
| grocery store!
| huytersd wrote:
| You really think so? Aren't we at the end of Moore's law, so
| I'm really doubtful that we'll see massive leaps like that.
| aembleton wrote:
| People have been saying that for at least twenty years
| bbarnett wrote:
| I remember people saying this in the 80s!
| RetroTechie wrote:
| Moore's law will die when we have 3D stacks of silicon thick
| enough that even integrated liquid cooling can't keep it
| cool. With feature sizes measured in a few atoms.
|
| Or when economics of fabricating such structures just aren't
| worth it.
| jamiek88 wrote:
| Yeah made out of not silicon.
|
| Moores 'law' is a human driven law.
|
| Computing is basically the absolute center of our society.
|
| As long as our civilization exists we will spend massive
| resources on this.
|
| Thus as long as it's physically possible we'll have
| progress.
| topspin wrote:
| > Aren't we at the end of Moore's law
|
| Three semi manufacturers are telling their investors they'll
| be at 2nm (or something) in late 2024 or 2025. So no, Moore's
| law has not seen its end, despite ~40 years of predictions to
| the contrary.
| boznz wrote:
| This is actually quite depressing considering the amount of
| Raspberry pi's doing tasks like watering a plant, Reminds me of
| Marvin the paranoid android.
| Dork1234 wrote:
| You can always replace them with RP2040 which have integer
| performance similar to the Cray-1 if that makes you feel
| better.
| upon_drumhead wrote:
| Esp32 ( https://www.espressif.com/en/products/socs/esp32 ) are
| what most folks should be using to do that stuff. It's a great
| platform to build upon.
| throwup238 wrote:
| ESPHome even comes with a well thought out sprinkler
| controller module:
| https://esphome.io/components/sprinkler.html
|
| It supports valves, pumps, schedules, etc. I programmed mine
| once a few years ago with YAML (no code!) and now I just
| power cycle them once every month or so. Been running great.
| speed_spread wrote:
| I've come to the conclusion that the value of the RPI is not so
| much in the hardware platform but rather in being the cheapest
| Linux running computer you can buy. Its much easier to program
| for than any embedded board.
| topspin wrote:
| > Its much easier to program for than any embedded board.
|
| Indeed. I work in both MCUs and full-featured Linux
| environments and there is zero value to using the former for
| non-safety critical, non-power constrained, low precision
| applications. Running a sprinkler system on an RPi is an
| entirely reasonable choice: you have ample storage for
| history, trivially simple remote control using a variety of
| protocols and media and ample compute to operate high level
| languages and run easily maintained programs, including nice-
| to-haves like continuous integration of public weather data
| to optimize your schedule against prevailing rainfall.
|
| Can you shoehorn all that into a ESP32 + micropython or
| whatever? Sure. I'll bet someone already has. And they spent
| 10x the time it would have taken otherwise. At least.
| m463 wrote:
| ...freeing up a human to come inside and read hn
| travisgriggs wrote:
| The article has Android phone comparisons. Any idea how the
| iPhones stack up against the Cray-1?
| hulitu wrote:
| My Android phone can not do any batch processing out of the
| box. You need 3 layers of emulation to be able to run a shell.
| wannacboatmovie wrote:
| I'm waiting for the follow-up from Jeff Geerling where he fits a
| Raspberry Pi into a Cray-1 enclosure.
| arbitrandomuser wrote:
| Or as many as he can with networking
| squarefoot wrote:
| I would totally love a Cray1 shaped PC enclosure. A even
| smaller one for Raspberry Pis would also be cool.
| smcameron wrote:
| https://www.thingiverse.com/thing:2610764
| internet101010 wrote:
| I've gone through the pi rabbit hole to the kubernetes/swarm
| level. Just skip that stuff at this point and get a mini pc. The
| money comes out to be the same and I promise it is way less of a
| hassle.
| fuzztester wrote:
| What make and model would you recommend for a mini PC? I was
| thinking of getting one lately.
| nielsole wrote:
| I got a used Lenovo ThinkCentre M910q i5-6500T 4x2.5GHz 8GB
| RAM 240GB SSD for 100 EUR.
|
| Plenty fast for a couple of VMs with web servers. It's also a
| lot better for 24/7 than RPi, as I was always struggling with
| SD card wear
| implements wrote:
| See also Dell OptiPlex 9020 Mini (i5-4590T 4x2GHz 16GB) -
| that class of "One Litre PC" make an excellent VPS / multi-
| VM setup.
| fuzztester wrote:
| Thanks.
| mherrmann wrote:
| TL; DR: ten years ago, Raspberry Pis and Android phones were a
| handful times faster. Nowadays, they are around 100 times faster.
| Pretty impressive, considering they fit in our pockets.
| hulitu wrote:
| Thank god they have a modern OS to slow them down. /s
| moffkalast wrote:
| No /s required, Wirth's law holds far more solidly than
| Moore's law. You may live to see man made software bloat
| beyond your comprehension.
| benj111 wrote:
| The pi Pico would be an interesting comparison.
|
| It doesn't have an fpu, and not much ram so it might actually be
| a close race for some of these tests.
| moffkalast wrote:
| Well I'm anxiously anticipating the first Micropython build for
| the Cray-1.
| auselen wrote:
| Recognizing the domain, you can read about the early history of
| benchmarks: http://www.roylongbottom.org.uk/whetstone.htm
| chatnealbot wrote:
| i wonder how moore's law figured into the pricing - for a nuclear
| simulation, makes sense you'd want to pay a lot, or basic science
| or political things like apollo moon missions, but for weather or
| commercial applications, if you wait a few years might not be
| worth to pay for cray right away, though there's marketing aspect
| of how advanced your product is.. maybe this was before moores
| law though
| kergonath wrote:
| > if you wait a few years might not be worth to pay for cray
| right away
|
| And then you don't get anything done because there is always a
| better computer just around the corner. Most of the time,
| proposals are written for hardware that already exist and don't
| need the absolute best. If you have some CFD or MHD
| calculations to do for a rocket engine or a nuclear reactor,
| you don't care about the computer on which it ran, just that it
| ran on time and did not hold the whole project back. Even
| cutting edge science does not require cutting edge hardware
| most of the time.
|
| Just like buying a desktop next year won't help you play games
| today, at some point you have to settle and accept that your
| hardware will be outdated by the time it comes online (it's a
| bit better now, but leading HPC clusters still get obsolesced
| quite quickly).
|
| > maybe this was before moores law though
|
| The exponential character of available CPU time on larger
| computers was apparent before Moore's law.
| dianeb wrote:
| As interesting as this article is as a comparison to a 40 year
| old supercomputer, the reality is that computers really are
| artifacts of an era and their place in the progress or regress of
| technology is possibly valid. Today's world's fastest computer is
| a Cray:
|
| https://www.top500.org/news/frontier-remains-no-1-in-the-top...
|
| So, how does the Raspberry Pi stack-up against today's computers?
___________________________________________________________________
(page generated 2023-12-25 23:01 UTC)