4 ms·

"And that's what we're talking about here, compilation speed, not computational equivalence." I believe the original poster meant generated code when (s)he wro

"And that's what we're talking about here, compilation speed, not computational equivalence." I believe the original poster meant generated code when (s)he wrote about compiler performance; the compile time is rather irrelevant for something that gets done once; what's relevant is the speed of the generated code which then runs the next billion times (or more). So let's get back to the performance of the code generated by the Rust compiler, shall we?

steveklabnik 8y ago
That performance is mostly really good at the moment. There's some things to do, but we're already roughly at the same place C and C++ are.
- Annatar 8y ago
  ...Which means you have lots of ground to cover before you reach parity with Fortran (phase 1), and then reach parity with CUDA Fortran (phase 2).
  - civility 8y ago
    You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html As for GPUs, no contest.
    - Annatar 8y ago
      Benchmarks are meaningless. I know from experience at looking at the generated assembler code and intel Fortran's SIMD code that it's faster. Take a look at the generated code and then we can discuss it, but not before. I'm not going to beat myself in C when I calculate a 100 million by 100 million matrix in Fortran. ifort will generate SIMD code with CPU autodetection and use machine code seqencing best for that processor, plus in Fortran a matrix is a normal variable type like any other. I'm not beating that with C (and I really know C). And just so you know, my information isn't old, I come from supercomputing.
      - civility 8y ago
        > Benchmarks are meaningless. Random anecdotes are meaningless. I've looked at plenty of generated code, and I've written plenty of SIMD assembly too. If you can't measure it, you can't compare it or improve it. There's nothing to discuss.
        Annatar 8y ago
        So if you looked at it, where are the assembler listings to compare? Let me see, I want to see too! If there is nothing to discuss and you plain refuse to do what I told you, why reply? Until you do exactly what I told you, there is nothing to see here. I have zero tolerance for people who won't listen. Move along, move along.
        civility 8y ago
        It's very weird you have the presentation of an impudent 20 year old but you share an irrational preference for Fortran, which is something I'm only used to seeing in people who are past their mid 50s. "Move along"? You're very full of yourself, and I think that explains why you aren't as smart as you think you are.
        Annatar 8y ago
        What you are or aren't used to seeing is about relevant to me as the last year's snow. You're free to think whatever the hell you want, that being a basic human right. Move along now, nothing to see here.
      - igouy 8y ago
        If you can contribute better Fortran programs for those Intel Fortran measurements, please do. https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/ifc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://salsa.debian.org/benchmarksgame-team/benchmarksgame/blob/master/CONTRIBUTING.md https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
civility 8y ago
If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell. > So let's get back to the performance of the code generated by the Rust compiler, shall we? "Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality of life.
- Annatar 8y ago
  Slow compilation speed is never a problem, I doubt anyone besides you cares about it. What is important is whether it generates fast code. Taking a long time to compile is fine if I get very fast code. I'm not going to be compiling code anywhere near as many times as I'm going to be running it.
  - civility 8y ago
    You really think it's just me? Take care.
    - Annatar 8y ago
      I do. Computers for most people are tools to perform final work faster, not a purpose unto itself which is all about programmer's convenience. A programmer's job is to be as uncomfortable and to suffer as much as possible so that the users could suffer as little as possible or not at all. This "developer convenience" attitude should be reproached or even financially penalized, so that such prima donnas finally come down to earth and start taking responsibility for their (shitty) software.
      - civility 8y ago
        Compilers don't have to be slow to generate good code (at least not as slow as Rust). If you prefer them slow, you're just choosing to be ineffective like some idiotic martyr. Suffering for it's own sake is just stupid.

steveklabnik 8y ago

That performance is mostly really good at the moment. There's some things to do, but we're already roughly at the same place C and C++ are.

Annatar 8y ago
...Which means you have lots of ground to cover before you reach parity with Fortran (phase 1), and then reach parity with CUDA Fortran (phase 2).
- civility 8y ago
  You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html As for GPUs, no contest.
  - Annatar 8y ago
    Benchmarks are meaningless. I know from experience at looking at the generated assembler code and intel Fortran's SIMD code that it's faster. Take a look at the generated code and then we can discuss it, but not before. I'm not going to beat myself in C when I calculate a 100 million by 100 million matrix in Fortran. ifort will generate SIMD code with CPU autodetection and use machine code seqencing best for that processor, plus in Fortran a matrix is a normal variable type like any other. I'm not beating that with C (and I really know C). And just so you know, my information isn't old, I come from supercomputing.
    - civility 8y ago
      > Benchmarks are meaningless. Random anecdotes are meaningless. I've looked at plenty of generated code, and I've written plenty of SIMD assembly too. If you can't measure it, you can't compare it or improve it. There's nothing to discuss.
      - Annatar 8y ago
        So if you looked at it, where are the assembler listings to compare? Let me see, I want to see too! If there is nothing to discuss and you plain refuse to do what I told you, why reply? Until you do exactly what I told you, there is nothing to see here. I have zero tolerance for people who won't listen. Move along, move along.
        civility 8y ago
        It's very weird you have the presentation of an impudent 20 year old but you share an irrational preference for Fortran, which is something I'm only used to seeing in people who are past their mid 50s. "Move along"? You're very full of yourself, and I think that explains why you aren't as smart as you think you are.
        Annatar 8y ago
        What you are or aren't used to seeing is about relevant to me as the last year's snow. You're free to think whatever the hell you want, that being a basic human right. Move along now, nothing to see here.
    - igouy 8y ago
      If you can contribute better Fortran programs for those Intel Fortran measurements, please do. https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/ifc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://salsa.debian.org/benchmarksgame-team/benchmarksgame/blob/master/CONTRIBUTING.md https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

civility 8y ago

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell. > So let's get back to the performance of the code generated by the Rust compiler, shall we? "Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality of life.

Annatar 8y ago
Slow compilation speed is never a problem, I doubt anyone besides you cares about it. What is important is whether it generates fast code. Taking a long time to compile is fine if I get very fast code. I'm not going to be compiling code anywhere near as many times as I'm going to be running it.
- civility 8y ago
  You really think it's just me? Take care.
  - Annatar 8y ago
    I do. Computers for most people are tools to perform final work faster, not a purpose unto itself which is all about programmer's convenience. A programmer's job is to be as uncomfortable and to suffer as much as possible so that the users could suffer as little as possible or not at all. This "developer convenience" attitude should be reproached or even financially penalized, so that such prima donnas finally come down to earth and start taking responsibility for their (shitty) software.
    - civility 8y ago
      Compilers don't have to be slow to generate good code (at least not as slow as Rust). If you prefer them slow, you're just choosing to be ineffective like some idiotic martyr. Suffering for it's own sake is just stupid.