31–36 of 36 posts
Earlier quoted context omitted.
This is assembly, not pure Go Well, if you're going to dip into pedantic mode, couldn't the language maintainers just define Go to include a few relevant Assembly instruction sets? (Not taking a dig at you but rather at the above level of pendantry.)
Not without tying Go to one architecture, no. When C programmers write inline assembly, they don't pretend it's C code.
Earlier quoted context omitted.
Not without tying Go to one architecture, no. When C programmers write inline assembly, they don't pretend it's C code.
Go has it's own form of assembly which it compiles to multiple architectures.
Seems the point of it is to enable easier porting of assembly between architectures, by providing a consistent syntax.
I was expecting something akin to LLVM assembly language, but no, they're come up with their own bizarre high-level assembly-language intended to map fairly directly to various different instruction-sets. It's not an abstraction layer in the usual sense; the exposed register-set and instruction-set are faithful to the target architecture.
It's a finite register machine which isn't just faithfully exposing the underlying architecture. Not something we often see. iirc SPIR and GNU Lightning are both finite register machines, but, to quote Douglas Adams, this has made a lot of people very angry and been widely regarded as a bad move.
How is it compiled? Presumably it doesn't get translated to LLVM as an intermediary.
It strikes me as an awful lot of work. Does their high-level assembler really outperform LLVM? Would've thought a project of that sort would deserve to exist in its own right, not just as an obscure component of Go.
One thing to note is that the benchmark is running on a Skylake Platinum chip which has two AVX512 FMAs. You need a Gold 6000 series and above to see any benefit from AVX512. In most other cases the CPU throttles down some insane amount and there’s no to little benefit.
You don't use FMA (or any multiplication) for SHA2. The throttling is a big issue.
Did you guys get to test Epyc at CloudFlare?
The 7401P seems pretty special. Like really great $ per perf. I think SuperMicro are coming out with 1 socket Epyc boards/servers.
Earlier quoted context omitted.
Go has it's own form of assembly which it compiles to multiple architectures.
I followed npongratz's link. Interesting read. Seems the point of it is to enable easier porting of assembly between architectures, by providing a consistent syntax. I was expecting something akin to LLVM assembly language, but no, they're come up with their own bizarre high-level assembly-language intended to map fairly directly to various different instruction-sets. It's not an abstraction layer in the usual sense;…
TAOS operating system used such a virtual ISA, and was able to achieve around 90% efficiency of native code. The worst case was PowerPC which fell to 80%. That's pretty darn good, IMO.
Earlier quoted context omitted.
Not without tying Go to one architecture, no. Not trying hard enough to prove the null hypothesis. If you're going full pedantic mode, why stop at one ISA? Just throw in the most relevant dozen. (Heck, I even spelled that out!)
That doesn't escape the problem. If you do that, your new definition of the core Go language is no longer cross-platform.
Earlier quoted context omitted.
I followed npongratz's link. Interesting read. Seems the point of it is to enable easier porting of assembly between architectures, by providing a consistent syntax. I was expecting something akin to LLVM assembly language, but no, they're come up with their own bizarre high-level assembly-language intended to map fairly directly to various different instruction-sets. It's not an abstraction layer in the usual sense;…
It's a finite register machine which isn't just faithfully exposing the underlying architecture. Not something we often see. iirc SPIR and GNU Lightning are both finite register machines, but, to quote Douglas Adams, this has made a lot of people very angry and been widely regarded as a bad move. TAOS operating system used such a virtual ISA, and was able to achieve around 90% efficiency of native code. The worst cas…
Interesting OS. Its 'VP code' looks like a precursor to Java bytecode/HotSpot, but much more low-level and RISC-ey.
Inferno OS's 'Dis' VM took a similar to approach to VP code, if I understand correctly.
I presume that, in 1991 when the article was written, "JIT" wasn't yet in the techies' parlance. It's not used anywhere in the article.