4 ms·

"X outperforms C/C++/Rust/Golang". Only if the code design in C/C++/Rust/Golang is bad.

nvy 3y ago
For the time being. But C on x86 hasn't been a good model of what the CPU is actually doing for a while now and eventually we'll have a better way to harness the computing power available to us.
- anonymoushn 3y ago
  immintrin.h seems tough to beat.
- starbugs 3y ago
  C was never intended to be a model of what the CPU is actually doing. This is purely an optimization issue and the article compares apples to oranges for clicks.
- throwaway17_17 3y ago
  I want to be optimistic and agree that ‘we’ll have a better way to harness the computing power available to us’, but at this point it’s been years or maybe decades of propping up the x86 ISA while actual operation of the computing device drifts further away. I certainly understand the desires of processor manufacturers to want to be able to maintain an ISA and then be able to implement a machine that can change underneath it to realize performance gains. However, this has left the status quo utterly entrenched and I can not see what would make them change this behavior. I really would get onboard with an alternative ISA that was more in line with actual architectural features of modern processors and I often wonder why we could not have an extra compilation (jit or aot) step from x86 to some other format. But the trend seems to be going the opposite direction for all the large scale processor manufacturer/designers toward a more abstracted interface at the lowest level. I’ve seen various comments that basically boil down to “you can’t change the ISA because then C/C++/Rust programs would loose performance in benchmarks in the short term”, and this resistance only reinforces maintaining current trends. So… what are you assuming happens that prompts the shift toward a better way to harness computing power?
  - anonymoushn 3y ago
    What architectural features would you like to surface that are currently papered over in x86?
    - throwaway17_17 3y ago
      My particular interests would see me appreciating access to cache structure, cache behavior, prefetching, cache coherency, memory management unit control, instruction pipelining, and maybe register renaming control. I am not particularly qualified to try and design a better ISA, I just know there are some things I would like the option to control at some times (or at least I imagine I would). A lot of the list above is about exposing more of the architecture to user control as a general principle. However, I’d rather see some areas of hardware design change to facilitate something other than coding paradigms and practices that stretch back nearly 40 years. Chisnall’s ‘C is not a Low Level Language’ article discusses several architectural directions I would like to see happen, but also talks about how as long as the ISA remains the same moving to new programming styles/philosophies continues to be a difficult proposition.
      - anonymoushn 3y ago
        I see. These things sound swell, though for stuff like controlling register renaming it sounds hard for the instruction decode overhead to be worth it. Currently you can use prefetch intrinsics for prefetching and the level of cache management available is mostly non-temporal stores and explicit allocation of L3 space to specific cores (which ends up meaning specific processes if you are careful). The world has mostly not adopted existing tools for writing 10-100x faster software (simd, huge pages, computing both branches then using a blend or cmov when this is sufficiently cheap, software prefetching, collection APIs that support bulk updates so that they can use all of these things instead of adding totally unnecessary dependency chains to the resulting program, etc.) so i'm not optimistic about things getting better if CPUs grow a thousand times more memory bandwidth and cores and begin to support very wide scatter/gather like GPUs.
  - emodendroket 3y ago
- mgaunard 3y ago
  C is a pretty good model in part because all ISAs were designed with C in mind.
anonymoushn 3y ago
Golang's compiler is not great. The main way to achieve acceptable performance in golang is to use their weird asm dialect.
- umvi 3y ago
  Golang's compiler is so fast though that I can iterate much faster so I'm willing to accept slightly worse performance than C++. C++ I waste so much time just waiting (esp. if I'm using a lot of templatized header only libraries)
  - john_the_writer 3y ago
    But by that logic ruby is faster still since the compile time is 0. Less than zero really because it can be modified in flight.
    - fredrikholm 3y ago
      The trade offs between the two are huge. Go programs compile in less than a second, or several seconds for huge projects, where idiomatic Go gets you within the same order of magnitude to that of C(++), with some memory overhead. Concurrency is first class, GC pauses exist but are seldom an issue. Idiomatic Ruby runs several orders of magnitude slower, with a huge memory overhead, and is rife with runtime gymnastics. Concurrency is an expensive hack, with stop-the-world GC.
    - Mawr 3y ago
      Only if the compilation speed difference is worth the loss of performance. That seems unlikely for most use cases because the speed gain is small while the performance loss is severe.
- Kiuhrly1 3y ago
  Somehow I can't find a source for this but it's well known that Go prefers compilation speed over runtime performance. Doesn't help that they implement the entire compiler stack themselves so it definitely misses optimisations that other compilers can already do. Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?
josephg 3y ago
(Edit: my mistake, I misread the comment I was replying to assuming it claimed these languages themselves were equivalent.) Why would the performance of these languages be identical? These languages aren’t the same in lots of ways. Golang has a GC and gives you much less control over memory layout than any of the other languages you mentioned. It also has a very different concurrency model, which will vastly change the performance characteristics of multithreaded code. Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc) Rust has much better noalias analysis - which allows the compiler to make optimizations that aren’t available in general purpose C or C++ code. (Since nobody adds noalias to all their variables in C, for a variety of reasons). Unlike the others, C doesn’t support monomorphization (without disgusting macro tricks). Monomorphization cuts both ways with performance - since it bloats executables (and thus hurts the branch predictor and cache) while generating more efficient code. These languages aren’t the same. There’s lots of reasons they will perform differently both at the limits of what we can optimize and in the average case of everyday code. It’s wild that you would consider them to all be the same.
- PartiallyTyped 3y ago
  > Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc) There's a rust front-end for gcc as well.
  - josephg 3y ago
    Is it ready for use? Last I saw it was far from feature complete.
    - PartiallyTyped 3y ago
      Afaik the borrow-checker is missing - please correct me if I am wrong - but that doesn't stop you from using it. You could very well use `rustc` for the borrow-checker and compile with GCC on any other backend. The borrow-checker only expresses that your code is sound according the rust spec.
deleted 3y ago
[deleted]

nvy 3y ago

For the time being. But C on x86 hasn't been a good model of what the CPU is actually doing for a while now and eventually we'll have a better way to harness the computing power available to us.

anonymoushn 3y ago
immintrin.h seems tough to beat.
starbugs 3y ago
C was never intended to be a model of what the CPU is actually doing. This is purely an optimization issue and the article compares apples to oranges for clicks.
throwaway17_17 3y ago
I want to be optimistic and agree that ‘we’ll have a better way to harness the computing power available to us’, but at this point it’s been years or maybe decades of propping up the x86 ISA while actual operation of the computing device drifts further away. I certainly understand the desires of processor manufacturers to want to be able to maintain an ISA and then be able to implement a machine that can change underneath it to realize performance gains. However, this has left the status quo utterly entrenched and I can not see what would make them change this behavior. I really would get onboard with an alternative ISA that was more in line with actual architectural features of modern processors and I often wonder why we could not have an extra compilation (jit or aot) step from x86 to some other format. But the trend seems to be going the opposite direction for all the large scale processor manufacturer/designers toward a more abstracted interface at the lowest level. I’ve seen various comments that basically boil down to “you can’t change the ISA because then C/C++/Rust programs would loose performance in benchmarks in the short term”, and this resistance only reinforces maintaining current trends. So… what are you assuming happens that prompts the shift toward a better way to harness computing power?
- anonymoushn 3y ago
  What architectural features would you like to surface that are currently papered over in x86?
  - throwaway17_17 3y ago
    My particular interests would see me appreciating access to cache structure, cache behavior, prefetching, cache coherency, memory management unit control, instruction pipelining, and maybe register renaming control. I am not particularly qualified to try and design a better ISA, I just know there are some things I would like the option to control at some times (or at least I imagine I would). A lot of the list above is about exposing more of the architecture to user control as a general principle. However, I’d rather see some areas of hardware design change to facilitate something other than coding paradigms and practices that stretch back nearly 40 years. Chisnall’s ‘C is not a Low Level Language’ article discusses several architectural directions I would like to see happen, but also talks about how as long as the ISA remains the same moving to new programming styles/philosophies continues to be a difficult proposition.
    - anonymoushn 3y ago
      I see. These things sound swell, though for stuff like controlling register renaming it sounds hard for the instruction decode overhead to be worth it. Currently you can use prefetch intrinsics for prefetching and the level of cache management available is mostly non-temporal stores and explicit allocation of L3 space to specific cores (which ends up meaning specific processes if you are careful). The world has mostly not adopted existing tools for writing 10-100x faster software (simd, huge pages, computing both branches then using a blend or cmov when this is sufficiently cheap, software prefetching, collection APIs that support bulk updates so that they can use all of these things instead of adding totally unnecessary dependency chains to the resulting program, etc.) so i'm not optimistic about things getting better if CPUs grow a thousand times more memory bandwidth and cores and begin to support very wide scatter/gather like GPUs.
- emodendroket 3y ago
mgaunard 3y ago
C is a pretty good model in part because all ISAs were designed with C in mind.

anonymoushn 3y ago

Golang's compiler is not great. The main way to achieve acceptable performance in golang is to use their weird asm dialect.

umvi 3y ago
Golang's compiler is so fast though that I can iterate much faster so I'm willing to accept slightly worse performance than C++. C++ I waste so much time just waiting (esp. if I'm using a lot of templatized header only libraries)
- john_the_writer 3y ago
  But by that logic ruby is faster still since the compile time is 0. Less than zero really because it can be modified in flight.
  - fredrikholm 3y ago
    The trade offs between the two are huge. Go programs compile in less than a second, or several seconds for huge projects, where idiomatic Go gets you within the same order of magnitude to that of C(++), with some memory overhead. Concurrency is first class, GC pauses exist but are seldom an issue. Idiomatic Ruby runs several orders of magnitude slower, with a huge memory overhead, and is rife with runtime gymnastics. Concurrency is an expensive hack, with stop-the-world GC.
  - Mawr 3y ago
    Only if the compilation speed difference is worth the loss of performance. That seems unlikely for most use cases because the speed gain is small while the performance loss is severe.
Kiuhrly1 3y ago
Somehow I can't find a source for this but it's well known that Go prefers compilation speed over runtime performance. Doesn't help that they implement the entire compiler stack themselves so it definitely misses optimisations that other compilers can already do. Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?

josephg 3y ago

(Edit: my mistake, I misread the comment I was replying to assuming it claimed these languages themselves were equivalent.) Why would the performance of these languages be identical? These languages aren’t the same in lots of ways. Golang has a GC and gives you much less control over memory layout than any of the other languages you mentioned. It also has a very different concurrency model, which will vastly change the performance characteristics of multithreaded code. Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc) Rust has much better noalias analysis - which allows the compiler to make optimizations that aren’t available in general purpose C or C++ code. (Since nobody adds noalias to all their variables in C, for a variety of reasons). Unlike the others, C doesn’t support monomorphization (without disgusting macro tricks). Monomorphization cuts both ways with performance - since it bloats executables (and thus hurts the branch predictor and cache) while generating more efficient code. These languages aren’t the same. There’s lots of reasons they will perform differently both at the limits of what we can optimize and in the average case of everyday code. It’s wild that you would consider them to all be the same.

PartiallyTyped 3y ago
> Rust is limited to llvm, while C can be compiled with many other compilers - some of which produce better code in many cases. (Eg icc) There's a rust front-end for gcc as well.
- josephg 3y ago
  Is it ready for use? Last I saw it was far from feature complete.
  - PartiallyTyped 3y ago
    Afaik the borrow-checker is missing - please correct me if I am wrong - but that doesn't stop you from using it. You could very well use `rustc` for the borrow-checker and compile with GCC on any other backend. The borrow-checker only expresses that your code is sound according the rust spec.

deleted 3y ago

[deleted]