This year's small computer

[kriesel]

Originally Posted by ewmayer

That recipe sounds vaguely familiar, though I have a measly 3 R7s, the maximum I could accommodate without expanding the footprint (really, 18"L x 12"W x 7"H 3D bounding box) of said build and allowing plenty of airflow to the GPUs.

I notice you mention fan guards - I've been looking for R7-suitable (or specific) ones, w/o success. Can you provide link(s)?

I went with an 8-gpu-nominal frame and 6-slot motherboard recently, for extra/adequate space. 120mm fan guards for the front-mounted, (direct mount to normal plastic case fans) Some of the 6 front-mounted fans are exposed and will get guards front and back for safety.
qty 10 https://www.ebay.com/itm/Lot-of-10-C...n/332335416149
qty 4 https://www.ebay.com/itm/4pcs-120mm-...n/271653618206

80mm for some cpu coolers qty 5 (Will require some custom mounting;; purpose is to keep straying cables away from the blades)
https://www.ebay.com/itm/80mm-Wire-C...e/153425613223

For gpu-face fans, won't your frame-surround screen handle that?
I suppose you could tape some 80mm guards in place, 3 per RadeonVII.

[ewmayer]

Originally Posted by kriesel

80mm for some cpu coolers qty 5 (Will require some custom mounting;; purpose is to keep straying cables away from the blades)
https://www.ebay.com/itm/80mm-Wire-C...e/153425613223

For gpu-face fans, won't your frame-surround screen handle that?
I suppose you could tape some 80mm guards in place, 3 per RadeonVII.

I decided against a custom mesh-screen surround, instead going with a pair of galss-top monitor stands (pair because max-height = 4", will flip bottom one upside down and epoxy or screws the 4 foot-bottoms to this of the top one, creating an 8" glass-top-and-bottom open-sided enclosure. Only the R7 on the extreme left end of the frame needs the fan guards, so 3 will suffice.

Thanks 4 the links - I contacted seller to see if they came with mounting screws, he said no, so since I was gonna need to order some kind of PC-screw-set anyway, ordered the following 2 items on Amazon:

https://www.amazon.com/Uxcell-a15111...dp/B01AGA9VTO/ - Amzn only had the $4.99 5-pack in black, and 10-pack leaves plenty of extras for future use

https://www.amazon.com/Sutemribor-Pe...dp/B07F71KFMQ/ -- 300pc screw variety pack, I need the smallest-shortest for the fans.

I can cut a pair of 10"-long alu. strips from same batch I used for the custom floating-above-CPU mounting brackets for GPU #3 and use my handy-dandy drill press and tap&die set to create mounting holes for the fan-guard screws, then stick small pcs of 2-sided tape on the ends of the Alu. strips and use those to stick to the fan-side of the GPU.

[Xyzzy]

https://www.raspberrypi.org/products/raspberry-pi-400

[paulunderwood]

Originally Posted by Xyzzy

https://www.raspberrypi.org/products/raspberry-pi-400

Neat. It just requires a modern monitor and maybe a huge USB HDD/SSD.

[Xyzzy]

https://www.clockworkpi.com/devterm

https://pocket.popcorncomputer.com/

[LaurV]

Originally Posted by Xyzzy

https://www.clockworkpi.com/devterm

https://pocket.popcorncomputer.com/

We played for the last 2-3 weeks with a Banana Pi M64, together with other boards (read "versus"), to select the hardware for a future product for an industrial customer. It is amazing what that little board can do. The board itself is not a big deal, those guys have some better boards, but the CPU from Allwinner is a wonder, beating all the competition by far, for the peanuts it costs. My struggle was not with the hardware, I am "expert" at "metal" programming, but with the Linux (to which I suck, and the support is not much, compared with "other fruits" Pi-es around), but fortunately I have colleagues who know what to type in those terminals
It worth having a look, especially if your goal is not connecting it to mipi LCD and other strange hardware, but to make applications, i.e. use it as a learning computer, then give it a try. I mean, out-of-the-box, with a keyboard, mouse, hdmi monitor, install ubuntu or debian from the linked page, the board works very nice. Adding hardware to it and recompiling the linux, playing with the device tree, etc, that is another story.
BTW, is Ernst's toy digesting ARM64 yet?

[ewmayer]

Originally Posted by LaurV

BTW, is Ernst's toy digesting ARM64 yet?

You'll need to be specific as to what you man by "toy". If you mean Mlucas, it's had Arm64 128-bit SIMD assembly support since 2017. I no longer run it my little Odroid because that is too slow, only currently running it on the last of the batch of 12 Samsung Galazy 7 Android broke-o-phones I bought in the used/for-parts market in early 2019.

ATM, based on test-compiles from Laurent Desnogues, am making some code-fiddles to try to get it to build using the Clang compiler on the new Apple M1 - identical instruction set, and I use an older version of Clang myself on my old Macbook classic where I do most of my code editing and proof-of-principle work, but the version of Clang on M1 is doing some macro-inlining-related optimizations - and lowering the -O* level did not cure this - which GCC-on-Arm64 does not do, and Laurent hit "ran out of registers" errors on a pair of core-FFT macros which max out the GCC macro-arglist limit of 30. Hopefully have something buildable by the new year.

[Mark Rose]

Originally Posted by ewmayer

You'll need to be specific as to what you man by "toy". If you mean Mlucas, it's had Arm64 128-bit SIMD assembly support since 2017. I no longer run it my little Odroid because that is too slow, only currently running it on the last of the batch of 12 Samsung Galazy 7 Android broke-o-phones I bought in the used/for-parts market in early 2019.

ATM, based on test-compiles from Laurent Desnogues, am making some code-fiddles to try to get it to build using the Clang compiler on the new Apple M1 - identical instruction set, and I use an older version of Clang myself on my old Macbook classic where I do most of my code editing and proof-of-principle work, but the version of Clang on M1 is doing some macro-inlining-related optimizations - and lowering the -O* level did not cure this - which GCC-on-Arm64 does not do, and Laurent hit "ran out of registers" errors on a pair of core-FFT macros which max out the GCC macro-arglist limit of 30. Hopefully have something buildable by the new year.

It seems the M1 has some undocumented instructions that may be useful for Mlucas: https://gist.github.com/dougallj/7a7...e7c36dc75e0d6f

[ewmayer]

Originally Posted by Mark Rose

It seems the M1 has some undocumented instructions that may be useful for Mlucas: https://gist.github.com/dougallj/7a7...e7c36dc75e0d6f

Interesting, but ugh - that kind of nonportability is only worth it if it offers huge performance benefits for one's application.

Brief update re. Mlucas-on-M1: Laurent Desnogues has a gcc-under-brew build working, we are playing around to see what maximizes total throughput on the big+little processor pair. I need to ask him how much detail I may release publicly, for now let me just say that 4-threaded performance on the big core alone is well more than 10x that of my Odroid C2, clock-for-clock. (But the C2 ain't exactly world-beating, so that's not saying all that much, except "the M1 doesn't suck").

I finished debug of some code mods designed to accommodate clang-on-M1's tighter-than-gcc macro-#args constraint, tested on my Odroid but waiting to hear whether it solves his Clang build issues on M1. We want both build options to be able to compare timings, clearly - the asm shouldn't care too much, but all the surrounding C code might.

[Xyzzy]

https://blog.jmdawson.co.uk/lichee-n...it-run-debian/

[LaurV]

Originally Posted by Xyzzy

https://blog.jmdawson.co.uk/lichee-n...it-run-debian/