undefined

points

[-]

One thing compilers still struggle with is exploiting weird microarchitectural quirks or timing behaviors that aren't obvious from the ISA spec, especially with memory, cache and pipeline tuning. If a new RISC-V core doesn't expose the same prefetching tricks or has odd branch prediction you won't get parity just by porting the same backend. If you want peak numbers sometimes you do still need to tune libraries or even sprinkle in a bit of inline asm despite all the "let the compiler handle it" dogma.

by cogman103 hours ago|

parent|

[-]

While true, it's typically not going to be impactful on system performance.

There's a reason, for example, why the linux distros all target a generic x86 architecture rather than a specific architecture.

by spockz3 hours ago|

parent|

[-]

Not all. CachyOS has specific builds for v3, v4, and AMD Zen4/5: https://wiki.cachyos.org/features/optimized_repos/

by thesuperbigfrog1 hours ago|

parent|

prev|

[-]

Ubuntu recently added a more specific target for AMD64v3:

https://discourse.ubuntu.com/t/introducing-architecture-vari...

by adrian_b3 hours ago|

parent|

prev|

[-]

Some applications may target a generic x86 architecture without any impact on performance.

However, other applications which must do cryptographic operations, audio/video processing, scientific/technical/engineering computing, etc. may have wildly different performances when compiled for different x86-64 ISA versions, for which dedicated assembly-language functions exist.

by cogman102 hours ago|

parent|

[-]

Granted, these applications do exist. They are simply becoming more and more rare. I'd also say that there's been a pretty steady dedicated effort to abstracting the assembly. It's still pretty low level, as in you are caring about the specific instructions being used, but it's also not quite assembly in both C++/rust.

Java, interestingly enough, is somewhat leading the way here with their Vector API. I think they actually have one of the better setups for allowing someone to write fast code that is platform independent.

C++ is also diving into this realm. 26 just merged in now SIMD instructions.

That is the bulk of the benefit of diving down into assembly.

https://en.cppreference.com/w/cpp/numeric/simd.html

by adrian_b2 hours ago|

parent|

[-]

I would not say that such applications are becoming more and more rare.

Most of the applications whose performance matters for me, because I must wait a non-negligible time for them to do their job, are dependent on assembly implementation for certain functions invoked inside critical loops. I do not see any sign of replacements for them. On the contrary, Intel, AMD and Arm continue to introduce special instructions that are useful in certain niche applications and taking advantage of them will require additional assembly language functions, not less.

For me, there is only one application that I use and which consumes non-negligible computer time and which does not depend on SIMD optimizations, which is the compilation of software projects.

by bobmcnamara3 hours ago|

prev|

[-]

> The optimizations that'd be applied to ARM and MIPS would be equally applicable to RISC-V.

There's no carry bit, and no widening multiply(or MAC)

by Findecanor1 hours ago|

parent|

[-]

RISC-V splits widening multiply out into two instructions: one for the high bits and one for the low. Just like 64-bit ARM does.

Integer MAC doesn't exist, and is also hindered by a design decision not to require more than two source operands, so as to allow simple implementations to stay simple. The same reason also prevents RISC-V from having a true conditional move instruction: there is one but the second operand is hard-coded zero.

FMAC exists, but only because it is in the IEEE 754 spec ... and it requires significant op-code space.