5 ms·
Most of it is written to take advantage of special hardware instructions in CPUs. If you take OpenSSL (a C library), it's got many assembly code paths as well.
by giovannibajo1 10y ago
Most of it is written to take advantage of special hardware instructions in CPUs. If you take OpenSSL (a C library), it's got many assembly code paths as well.
I'm not sure why this should be a problem, it just shows attention to performance in my opinion.
- pcwalton 10y agoOpaque assembly blocks that the compiler doesn't understand the effects of are actually suboptimal for performance.
- drchickensalad 10y agoGenerally yes, specialized no.
- dlsniper 10y agoIs this a general thing or a Go specific one? This generic statement seems to be false given how many optimizations that actually need assembly exist in Go and not only.
- pjmlp 10y agoIt is a general thing and quite common. Either you keep adding intrisics to the compiler, or outsource it to an external Assembler. Even managed languages have bytecode Assemblers available.
- dlsniper 10y agoIs this a general thing or a Go specific one? This generic statement seems to be false given how many optimizations that actually need assembly exist in Go and not only.
- Cthulhu_ 10y agoOnly if the compiler is aware of and can translate code into e.g. ARM-specific sha instructions. If not, then the developer is still smarter than the compiler and should use assembly to use those specific instructions.
- shinigami 10y agoRarely true for low level crypto code.