vluft

I sure hope you are not.

9754 is 128/256 now, so 256/512 for that.

That supermicro system is 8-way; it's 4 dual-socket motherboards but they're one system, hooked together by backplane boards. You can price supermicro's complete-system-only stuff (all of it now, alas) out on thinkmate or similar sites, but a minimal config (and you'd never buy that for a minimal config) hits around $60k.

something that might be useful to you for that; you can get m.2 slot network adapters which you could use on (some) ITX boards. there's at least 1 & 10gbe ones available.

pass is not a gnu project.

I dunno, if your crypto choices were just "the best thing that won't be included in FIPS" you would do pretty well; blake3, chacha20, 25519 sigs & dh...

yup, for comparison, same file as above using all the threads (32) on my system, I get about 45ms with fully parallel permitted b3. It does run into diminishing returns fairly quickly though; unsurprisingly no improvements in perf using hyperthreading, but also improvements drop off pretty fast with more cores.

  b3sum --num-threads 16 /tmp/rand_1G ran
    1.01 ± 0.02 times faster than b3sum --num-threads 15 /tmp/rand_1G
    1.01 ± 0.02 times faster than b3sum --num-threads 14 /tmp/rand_1G
    1.03 ± 0.02 times faster than b3sum --num-threads 13 /tmp/rand_1G
    1.04 ± 0.02 times faster than b3sum --num-threads 12 /tmp/rand_1G
    1.07 ± 0.02 times faster than b3sum --num-threads 11 /tmp/rand_1G
    1.10 ± 0.02 times faster than b3sum --num-threads 10 /tmp/rand_1G
    1.13 ± 0.02 times faster than b3sum --num-threads 9 /tmp/rand_1G
    1.20 ± 0.03 times faster than b3sum --num-threads 8 /tmp/rand_1G
    1.27 ± 0.03 times faster than b3sum --num-threads 7 /tmp/rand_1G
    1.37 ± 0.02 times faster than b3sum --num-threads 6 /tmp/rand_1G
    1.53 ± 0.05 times faster than b3sum --num-threads 5 /tmp/rand_1G
    1.72 ± 0.03 times faster than b3sum --num-threads 4 /tmp/rand_1G
    2.10 ± 0.04 times faster than b3sum --num-threads 3 /tmp/rand_1G
    2.84 ± 0.06 times faster than b3sum --num-threads 2 /tmp/rand_1G
    5.03 ± 0.12 times faster than b3sum --num-threads 1 /tmp/rand_1G

(over 16 elided from this run as they're all ~= the 16 time)

further research suggests that GNU coreutils cksum will use libcrypto in some configurations (though not mine); I expect that both both your commands above are actually using sha-ni

not sure that tool is correct; on my openssl it shows same output as you have there, but not aes-ni which is definitely enabled and functional.

ETA: ahh you want to do that on libcrypto:

  iced-cpuid <...>/libcrypto.so.3:
    ADX AES AVX AVX2 AVX512BW AVX512DQ AVX512F AVX512VL AVX512_IFMA BMI1 BMI2 CET_IBT CLFSH CMOV D3NOW MMX MOVBE MSR PCLMULQDQ PREFETCHW RDRAND RDSEED RTM SHA SMM SSE SSE2 SSE3 SSE4_1 SSSE3 SYSCALL TSC VMX XOP XSAVE

this is less precise than the perf numbers as I don't really have a way to measure power directly, but with rerunning the benchmarks above locked to a cpu core, it boosted ~the same level for all 3 commands (about 5.5ghz), so should be ~the same power usage.

followup to this now with further blake3 improvements, on a faster machine now but with sha extensions vs single-threaded blake3; blake3 is about 2.5x faster than sha256 now. (b3sum 1.5.0 vs openssl 3.0.11). b3sum is about 9x faster than sha256sum from coreutils (GNU, 9.3) which does not use the sha extensions.

  Benchmark 1: openssl sha256 /tmp/rand_1G
    Time (mean ± σ):     576.8 ms ±   3.5 ms    [User: 415.0 ms, System: 161.8 ms]
    Range (min … max):   569.7 ms … 580.3 ms    10 runs

  Benchmark 2: b3sum --num-threads 1 /tmp/rand_1G
    Time (mean ± σ):     228.7 ms ±   3.7 ms    [User: 168.7 ms, System: 59.5 ms]
    Range (min … max):   223.5 ms … 234.9 ms    13 runs

  Benchmark 3: sha256sum /tmp/rand_1G
    Time (mean ± σ):      2.062 s ±  0.025 s    [User: 1.923 s, System: 0.138 s]
    Range (min … max):    2.046 s …  2.130 s    10 runs

  Summary
    b3sum --num-threads 1 /tmp/rand_1G ran
      2.52 ± 0.04 times faster than openssl sha256 /tmp/rand_1G
      9.02 ± 0.18 times faster than sha256sum /tmp/rand_1G

they had a whole series that would irretrievably die after 1700 idle hours due to a firmware bug.

yup. if you are picky about mobo selection, you can also do it all over one fiber thunderbolt cable; I have my desktop rackmounted and could go up to 165ft away for the desk.

you can run it with `--single-instance` (or `-1`) and you only pay (most of) that startup cost once.

you can at least get 96GB now, with 48GB dimms

another pretty easy optimization is swapping to https://github.com/minio/sha256-simd, particularly if you're on a process with the sha extensions.

versus just spawning a goroutine per attempt, it'll likely be much faster as well to just split the search space into number of cores and have one chugging away on each chunk of the search space. (I have a thing to do vanity git commit hashes and that's what I do for that; for 7 characters in the hash, it takes well under a second on my CPU on average)

lua is used by mod APIs because it's very performant and extremely easy to embed in C/C++.

> especially difficult for new-to-programming gamers with great ideas to pick up

and you're proposing haskell or erlang as an alternative first programming language for somebody?

> Is it still blogspam if this paragraph exists in the end of the post?

yes

yup. I pay $25/mo happily but would go up to at least $100 without blinking. I do between 1k and 2.5k searches per mo, and also use the summarizer a bit. Compared to DDG (which I was using before), I haven't done a bang to fall back to google in months at least. DDG searches were better on some topics but on average slightly worse than google for me, Kagi is fairly consistently better and being able to block domains is fantastic.

for cookware generally it's used to distinguish from stainless

I'm curious what your workflow is that not having any disk caching would have acceptable performance.

other than both being electron apps (and admittedly electron was made for atom), Atom and VS Code share no common codebase.

yup, though that means you're wasting that core's compute; something with green threads where language runtime does a cross-core interrupt to submit syscall then continues execing other green threads until it gets a user interrupt for syscall completion would be pretty neat.

(ETA: and indeed looks like they're considering support for that in io_uring! https://lwn.net/Articles/869140/)

With cross-core interrupts and user-mode interrupt handlers (as in some new intel cpus), you could even do something without polling (interrupt for submission) where the core user-mode code is running on _never_ context switches (obviously except for scheduling) and you just have a dedicated kernel core or cores off doing kernel things.

well, at that point they might as well not implement it, as it will be well and truly useless

I have a 4u, not a 3u, but sliger has one now that should be pretty good. https://www.sliger.com/products/rackmount/3u/cx3151a/ has a riser for doing a modern (heh) sized graphics card.

heck, you'll have difficulty fitting a 4090 in a 4U without special right-angle pcie power connectors

tripplite has an 18u (SRQ18U) than can do 37" deep; I've had one for a few years and it works well. You'll still here 40mm screamers running at full speed, but it cuts down on noise a lot.

the only available fiber optic thunderbolt cables I'm aware of right now are from corning, and they are thunderbolt 3. I'm running 5120x1440@120hz through it (and a variety of USB); 4k144hz would be about 35% more bandwidth. Corning lists the cable as supporting 2x4k or 1x5k (presumably both at 60hz); 5k is the same bandwidth as mine, and 2x4k is some what more but less than 4k144hz. Total bandwidth on the cable is 40g and bandwidth needed for 4k144hz is about 32g I believe. can't guarantee it'd work, but 4k120hz probably does?

fiber optic DP cables are maybe $70 or $80 and work pretty well in my experience.

on the pricier side if you have something with TB support, you can do display and USB over that to a fiber optic TB cable (about $400); this is my current setup for my racked PC in another room to my office, with a TB hub (caldigit TS4) that splits out display and USB.

> Municipal broadband: the best broadband in the entire United States is provided by the municipality of Chattanooga.

You can even get 25G from EPB now, though the 10G is good enough for me, frankly. That being said, there's several locations in the US where 10G residential fiber is broadly available; frequently either municipal or co-op (e.g. Utopia Fiber in Utah), though I believe EPB was first in 2015.