4 ms·
Last time I checked a hyper thread is ~75% slower than a normal one, so it’s roughly a 50 core cpu.
by Asmod4n 5y ago
Last time I checked a hyper thread is ~75% slower than a normal one, so it’s roughly a 50 core cpu.
- reitzensteinm 5y agoThis depends heavily on your memory access patterns. If you're chasing dependent loads around memory, like traversing a long fragmented linked list due to garbage code, you will get an absolutely perfect 100% speed up. If you're already saturating the ALU on one thread, adding another to the core will probably slow you down with context switching and cache contention, and indeed well written numeric simulations on supercomputers often turn it off entirely. However, most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety.
- Const-me 5y ago> most software we run resembles the garbage pointer chasing variety more than the finely tuned numerical variety. To be fair, crappy pointer-heavy data structures is not the only possible reason. Some useful algorithms are inherently serial. For instance, all streaming parsers, compressors, or cryptography are inherently serial algorithms. An implementation gonna be relatively slow not because of RAM latency, but due to continuous chain of data dependencies between sequential instructions. It’s technically possible to implement single-threaded code to handle multiple streams concurrently. Practically, more often that not it’s prohibitively complicated to achieve. However, doing that in hardware with two hardware threads running on the same core is way more manageable in terms of software complexity.
- reitzensteinm 5y agoYeah, garbage code was a little unfair. I actually experimented with parallel fetching of multiple values out of a large persistent vector years ago, and saw nearly linear speed up for up to four fetches in parallel. The code was awful and it would need to be a compiler generated thing for sure.
- Const-me 5y ago> The code was awful and it would need to be a compiler generated thing for sure. C++ templates technically work, Eigen [1] is made entirely of them and the performance is pretty good. However, writing and debugging code in that style is hard, and the code is unreadable. I tried T4 [2] to generate AVX intrinsics-heavy C++ code. At least the programming language is sane as opposed to C++ template metaprogramming. However, the code generation adds friction. Also, IDE integration is less than ideal, apparently Microsoft only cared about consuming T4 from C# projects. I basically gave up, and usually writing normal C-like code with SIMD intrinsics, with just a few preprocessor macros, and no template metaprogramming. Unrolling things manually when necessary. At least the code is readable this way, and not too hard to debug. The compilers have these non-standard keywords/attributes to forcefully inline functions, they allow to reuse code instead of copy-pasting. [1] https://eigen.tuxfamily.org/index.php?title=Main_Page https://eigen.tuxfamily.org/index.php?title=Main_Page [2] https://en.wikipedia.org/wiki/Text_Template_Transformation_Toolkit https://en.wikipedia.org/wiki/Text_Template_Transformation_T...
- reitzensteinm 5y agoThat's interesting, thanks. TIL about T4/Eigen. Actually, for my specific use case using AVX512 gather intrinsics would probably have worked OK and been cleaner - although I've heard they're pretty slow.