4 ms·

Are you implying that Rust isn't performant?

yellowapple 9y ago
If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.
- mikepurvis 9y ago
  Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.
  - madez 9y ago
    So, you say Python is totally missing the point and is wrong? Even when encoding videos, performance matters. Also, that optimizing compilation is important is no reason to not work on i386. This is a point Rust needs to fix. And not only i386 support, but also other architecture families, as host.
    - user5994461 9y ago
      Python is slow as fuck. All the heavy API and computation libraries are wrappers are C binaries that are optimized to death.
  - im3w1l 9y ago
    A fast edit-compile-run cycle makes development a lot more efficient in my experience.
    - mikepurvis 9y ago
      Right, definitely! But in that case, it's really incremental build time that's the important thing. Not that overall/first build time isn't important too, but in general I'd rather see my incremental build go down by 80% than my first build go down by 20%, and I think this is reflected in where the Rust team has historically applied their perf efforts, eg: https://blog.rust-lang.org/2016/09/08/incremental.html https://blog.rust-lang.org/2016/09/08/incremental.html (Appreciating as well that most incremental build gains come from avoiding unnecessary work, so they're as much the domain of the build system as they are of the compiler.)
  - user5994461 9y ago
    What languages do you come from? What is fast compilation for you? The compilation phase can take hours in C++. Up to a day when compiling huge projects will all the optimization flags. Live that for some time and it will quickly prove you that you were wrong. Compilation time matters.
    - qznc 9y ago
      Fast compilation: less than a second (feels like not waiting at all) Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time) To have fast compilation even with big projects is hard. Go, C, and D are usually fast. Scala is usually slow. I care about development builds primarily. The edit-compile-test loop must be really really fast. Optimization flags are irrelevant, because if performance matters you often must have them enabled for development as well.
      - pinkythepig 9y ago
        This is off topic a bit, but there is a solution for this: > Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time) See the thread here: https://askubuntu.com/questions/409611/desktop-notification-when-long-running-commands-complete https://askubuntu.com/questions/409611/desktop-notification-... TL;DR install undistract-me, add 2 lines to bashrc, and you will get a desktop popup when a command that takes longer than 10 seconds to complete is finished. Fedora does this by default on install and I have found it so handy. Kick off a compile etc, then just browse HN/reddit til I get the popup.
        qznc 9y ago
        Yes, this helps a little. As a fish user, I had to write more than two lines [0] though. A second monitor is detrimental, because the notification is too far away sometimes. [0] https://github.com/qznc/dot/blob/master/config/fish/config.fish#L61 https://github.com/qznc/dot/blob/master/config/fish/config.f...
    - todd8 9y ago
  - yellowapple 9y ago
    Right, but the problem is that - in the OpenBSD world - it's a price that's paid much more than once. Sure, that binary might be run millions of times, or it might be run only tens or hundreds or thousands of times before an update comes around. And that's just for one platform; OpenBSD supports lots of platforms, both 32-bit and 64-bit, and all of them are expected to be fully usable for (among other things) developing OpenBSD (which includes, you know, actually compiling OpenBSD). To rephrase that a bit: OpenBSD is designed to be a system where any user on any platform can contribute to OpenBSD using the tools included in OpenBSD's default install. Deviations from that will almost certainly receive a cold reception at best.

If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.

mikepurvis 9y ago
Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.
- madez 9y ago
  So, you say Python is totally missing the point and is wrong? Even when encoding videos, performance matters. Also, that optimizing compilation is important is no reason to not work on i386. This is a point Rust needs to fix. And not only i386 support, but also other architecture families, as host.
  - user5994461 9y ago
    Python is slow as fuck. All the heavy API and computation libraries are wrappers are C binaries that are optimized to death.
- im3w1l 9y ago
  A fast edit-compile-run cycle makes development a lot more efficient in my experience.
  - mikepurvis 9y ago
    Right, definitely! But in that case, it's really incremental build time that's the important thing. Not that overall/first build time isn't important too, but in general I'd rather see my incremental build go down by 80% than my first build go down by 20%, and I think this is reflected in where the Rust team has historically applied their perf efforts, eg: https://blog.rust-lang.org/2016/09/08/incremental.html https://blog.rust-lang.org/2016/09/08/incremental.html (Appreciating as well that most incremental build gains come from avoiding unnecessary work, so they're as much the domain of the build system as they are of the compiler.)
- user5994461 9y ago
  What languages do you come from? What is fast compilation for you? The compilation phase can take hours in C++. Up to a day when compiling huge projects will all the optimization flags. Live that for some time and it will quickly prove you that you were wrong. Compilation time matters.
  - qznc 9y ago
    Fast compilation: less than a second (feels like not waiting at all) Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time) To have fast compilation even with big projects is hard. Go, C, and D are usually fast. Scala is usually slow. I care about development builds primarily. The edit-compile-test loop must be really really fast. Optimization flags are irrelevant, because if performance matters you often must have them enabled for development as well.
    - pinkythepig 9y ago
      This is off topic a bit, but there is a solution for this: > Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time) See the thread here: https://askubuntu.com/questions/409611/desktop-notification-when-long-running-commands-complete https://askubuntu.com/questions/409611/desktop-notification-... TL;DR install undistract-me, add 2 lines to bashrc, and you will get a desktop popup when a command that takes longer than 10 seconds to complete is finished. Fedora does this by default on install and I have found it so handy. Kick off a compile etc, then just browse HN/reddit til I get the popup.
      - qznc 9y ago
        Yes, this helps a little. As a fish user, I had to write more than two lines [0] though. A second monitor is detrimental, because the notification is too far away sometimes. [0] https://github.com/qznc/dot/blob/master/config/fish/config.fish#L61 https://github.com/qznc/dot/blob/master/config/fish/config.f...
  - todd8 9y ago
- yellowapple 9y ago
  Right, but the problem is that - in the OpenBSD world - it's a price that's paid much more than once. Sure, that binary might be run millions of times, or it might be run only tens or hundreds or thousands of times before an update comes around. And that's just for one platform; OpenBSD supports lots of platforms, both 32-bit and 64-bit, and all of them are expected to be fully usable for (among other things) developing OpenBSD (which includes, you know, actually compiling OpenBSD). To rephrase that a bit: OpenBSD is designed to be a system where any user on any platform can contribute to OpenBSD using the tools included in OpenBSD's default install. Deviations from that will almost certainly receive a cold reception at best.