3 ms·

> Does anyone even work with assembly anymore? I do, but very rarely code in assembly. Usually just read output of C++ compiler. It’s hard to beat well-writte

> Does anyone even work with assembly anymore? I do, but very rarely code in assembly. Usually just read output of C++ compiler. It’s hard to beat well-written manually vectorized C++ code. Even when the compiler obviously doing something wrong: https://developercommunity.visualstudio.com/content/problem/350355/the-compiler-optimized-a-single-very-fast-instruct.html https://developercommunity.visualstudio.com/content/problem/... The compiler appears to know about typical latency figures for these instructions, i.e. it reorders them when It can if it gonna help. > how is software keeping up with hardware advances? Barely. The only way to approach advertised compute performance of CPUs is SIMD instructions. Despite available in mainstream CPUs for couple decades now (Pentium 3 launched in 1999), modern compilers can only auto-vectorize very simple code. Fortunately, these instructions are available as C and C++ compiler intrinsics. Supported by all modern compilers and quite portable in practice (across different compilers building for the same architecture). > Do newer low-level languages like Rust and Go really utilize the massive advances that have taken place? Both are worse than C++. About what to start with… I would start with picking either CPU or GPGPU. GPUs have way more raw computing power. Programming models are entirely different between them. If you’ll pick GPU, I’d recommend “CUDA by example” book, helped me when I started GPGPU programming. BTW, for GPUs, assemblies and instruction sets are proprietary i.e. no one works with assembly. There’re low-level assembly-like things, Nvidia PTX, MS shader assembly, but these instructions are not executed by hardware, GPU drives compiles them once again into proprietary stuff. Don’t know good books for CPU SIMD, I started organically with some random articles and Intel reference, but I had many years of C and C++ programming when I did. Not sure it’ll work for you.

adamnemecek 7y ago
> Both are worse than C++. How so?
- Const-me 7y ago
  If you need performance, you must embrace vector nature of the hardware. Intel makes CPUs and invented many of these instructions sets, they also make a C++ compiler, and their implementation of intrinsics is what's adopted by other compilers. They also provide decent documentation. Intel doesn't support any golang or rust packages or language extensions.
  - adamnemecek 7y ago
    You can use intrinsics from rust. You can use intrinsics from a lot of languages. https://github.com/AdamNiederer/faster https://github.com/AdamNiederer/faster In fact, in Rust, they are easier to use.
    - Const-me 7y ago
      > You can use intrinsics from rust Right, I know there’s some support. > You can use intrinsics from a lot of languages. Yes. However, Intel (the guys making CPUs actually implementing these instructions) only supports them for C/C++. Just because you can use them from other languages (e.g. modern .NET has them as well, System.Numerics.Vectors) doesn’t necessarily mean it’s a good idea to do so. > In fact, in Rust, they are easier to use. That’s not “in fact”, that’s your opinion. Personally, I don’t think simple is good. When I code at that level of abstraction, I want to get whatever instructions are implemented by CPU. No more, no less. I’ve looked at example on the front page. There’re two methods to compute rsqrt in SSE/AVX, fast approximate one (rsqrtps), and precise one (sqrtps, divps). There’re several methods to compute ceil/floor, again with different tradeoffs. Do you know which instructions their example compile into? Neither do I. Also, one tricky part of CPU SIMD is cross-lane operations (shuffle, movelh/movehl, unpack, etc). Another one is integers: the instruction set is not comparable to any programming language, saturated versions of + and -, relatively high-level operations like psadbw, pmaddubsw, palignr, lack of something simple (e.g. can’t compare unsigned bytes for greater/less, only signed ones). For trivially simple algorithms that compute same math on wide vectors of float values, you better use OpenCL and run on GPU. Will likely be faster.
      - adamnemecek 7y ago
        You can link the exact same intrinsics in a rust binary to get the same intrinsics. > That’s not “in fact”, that’s your opinion. Personally, I don’t think simple is good. When I grow up I want to be as smart as you. And re: the faster project, you can use the exact same instructions. This is nothing about rust or not. Also, Rust is simply a better language for low level things even ignoring intrinsics.
mirceal 7y ago
of course someone works with it. someone has to write and maintain the tooling that eventually ends up as x86, right?
bitcoinmoney 7y ago
Can you share what you do for a living?
- Const-me 7y ago
  I've been developing software for living since 2000. Lately, working on CAD/CAM/CAE Windows desktop software, also some Linux embedded. Before that worked in game development, HPC (have not coded for supercomputers, just commodity servers i.e. Xeon + nVidia), realtime multimedia (video processing, encoding, broadcasting).

adamnemecek 7y ago

> Both are worse than C++. How so?

Const-me 7y ago
If you need performance, you must embrace vector nature of the hardware. Intel makes CPUs and invented many of these instructions sets, they also make a C++ compiler, and their implementation of intrinsics is what's adopted by other compilers. They also provide decent documentation. Intel doesn't support any golang or rust packages or language extensions.
- adamnemecek 7y ago
  You can use intrinsics from rust. You can use intrinsics from a lot of languages. https://github.com/AdamNiederer/faster https://github.com/AdamNiederer/faster In fact, in Rust, they are easier to use.
  - Const-me 7y ago
    > You can use intrinsics from rust Right, I know there’s some support. > You can use intrinsics from a lot of languages. Yes. However, Intel (the guys making CPUs actually implementing these instructions) only supports them for C/C++. Just because you can use them from other languages (e.g. modern .NET has them as well, System.Numerics.Vectors) doesn’t necessarily mean it’s a good idea to do so. > In fact, in Rust, they are easier to use. That’s not “in fact”, that’s your opinion. Personally, I don’t think simple is good. When I code at that level of abstraction, I want to get whatever instructions are implemented by CPU. No more, no less. I’ve looked at example on the front page. There’re two methods to compute rsqrt in SSE/AVX, fast approximate one (rsqrtps), and precise one (sqrtps, divps). There’re several methods to compute ceil/floor, again with different tradeoffs. Do you know which instructions their example compile into? Neither do I. Also, one tricky part of CPU SIMD is cross-lane operations (shuffle, movelh/movehl, unpack, etc). Another one is integers: the instruction set is not comparable to any programming language, saturated versions of + and -, relatively high-level operations like psadbw, pmaddubsw, palignr, lack of something simple (e.g. can’t compare unsigned bytes for greater/less, only signed ones). For trivially simple algorithms that compute same math on wide vectors of float values, you better use OpenCL and run on GPU. Will likely be faster.
    - adamnemecek 7y ago
      You can link the exact same intrinsics in a rust binary to get the same intrinsics. > That’s not “in fact”, that’s your opinion. Personally, I don’t think simple is good. When I grow up I want to be as smart as you. And re: the faster project, you can use the exact same instructions. This is nothing about rust or not. Also, Rust is simply a better language for low level things even ignoring intrinsics.

mirceal 7y ago

of course someone works with it. someone has to write and maintain the tooling that eventually ends up as x86, right?

bitcoinmoney 7y ago

Can you share what you do for a living?

Const-me 7y ago
I've been developing software for living since 2000. Lately, working on CAD/CAM/CAE Windows desktop software, also some Linux embedded. Before that worked in game development, HPC (have not coded for supercomputers, just commodity servers i.e. Xeon + nVidia), realtime multimedia (video processing, encoding, broadcasting).