3 ms·

I know this is about Swift, but: Rust compiled in about a minute and the runtime was 2 secs That seems really slow as well! Since reading the same thing in JS

I know this is about Swift, but: Rust compiled in about a minute and the runtime was 2 secs That seems really slow as well! Since reading the same thing in JSON only takes a fraction of a second. I think it would be well worthwhile speeding up this kind of thing. Obviously a million-element static array isn’t common usage, but if you can find and fix the bottlenecks there, it will help make everyday usage faster too in lots of small ways.

tialaramex 3y ago
In Rust you can include_bytes! a file if the situation is that you just want a whole bunch of data, as is often the case with practical systems, (the result of the include_bytes! macro is a &'static [u8; N] ie an immutable reference to an array of N unsigned bytes which lives forever). So for example you can write code which cares how long firmware.bin is, without needing to ensure the code is updated appropriately, and yet doesn't bake firmware.bin inside your finished binary, by writing something like const fw_length = include_bytes!("firmware.bin").len(); and the compiler can see we don't actually want the array at runtime, just its length, so the data evaporates from the output software. Parsing a programming language is just always going to be slower than just reading a file into memory, which is why Rust had include_bytes! from the outset and it's silly that C didn't do likewise even in 1989, let alone C++ in 1998. This particular exercise wants a machine-word size integer, so in Rust that's isize, but you could isize::from_le_bytes() or whatever with chunked conversions, which will happen at runtime but ought to go very much faster than parsing text.
- iainmerrick 3y ago
  Okay, but the question I’m asking is, why does the basic version take 60 seconds to compile? Why not 6 seconds, or 60 milliseconds? If there’s a good and insurmountable reason why it must be a minute and no less, okay. But I’d be amazed if there aren’t some easy wins to be made that could speed it up by a decent amount. That’s not worth doing just because of the silly million-element array case, of course; but if you can make that silly case faster, lots of more important use cases will get faster too.
  - tialaramex 3y ago
    I mean, if you feel it's worth figuring this out you totally can, Rust's source code really does successfully download and just build so you can tinker with it, I patched it some weeks back to improve the diagnostics you get for type errors where e.g. you wrote 'X' (a 21-bit integer representing the Unicode Latin capital X) but you ought to have written b'X' (an 8-bit unsigned byte representing the ASCII code for X) - yes numerically those values are identical but Rust correctly does not consider that to mean they're the same type - and it was like an hour's work to build Rust and first figure out where to attempt my changes. You can submit a PR and after a robot puts it in a pile to be looked at, actual humans will ask you about your proposed change, they can ask other robots to check whether it works OK on the huge piles of real world Rust out there, and so on.

tialaramex 3y ago

In Rust you can include_bytes! a file if the situation is that you just want a whole bunch of data, as is often the case with practical systems, (the result of the include_bytes! macro is a &'static [u8; N] ie an immutable reference to an array of N unsigned bytes which lives forever). So for example you can write code which cares how long firmware.bin is, without needing to ensure the code is updated appropriately, and yet doesn't bake firmware.bin inside your finished binary, by writing something like const fw_length = include_bytes!("firmware.bin").len(); and the compiler can see we don't actually want the array at runtime, just its length, so the data evaporates from the output software. Parsing a programming language is just always going to be slower than just reading a file into memory, which is why Rust had include_bytes! from the outset and it's silly that C didn't do likewise even in 1989, let alone C++ in 1998. This particular exercise wants a machine-word size integer, so in Rust that's isize, but you could isize::from_le_bytes() or whatever with chunked conversions, which will happen at runtime but ought to go very much faster than parsing text.

iainmerrick 3y ago
Okay, but the question I’m asking is, why does the basic version take 60 seconds to compile? Why not 6 seconds, or 60 milliseconds? If there’s a good and insurmountable reason why it must be a minute and no less, okay. But I’d be amazed if there aren’t some easy wins to be made that could speed it up by a decent amount. That’s not worth doing just because of the silly million-element array case, of course; but if you can make that silly case faster, lots of more important use cases will get faster too.
- tialaramex 3y ago
  I mean, if you feel it's worth figuring this out you totally can, Rust's source code really does successfully download and just build so you can tinker with it, I patched it some weeks back to improve the diagnostics you get for type errors where e.g. you wrote 'X' (a 21-bit integer representing the Unicode Latin capital X) but you ought to have written b'X' (an 8-bit unsigned byte representing the ASCII code for X) - yes numerically those values are identical but Rust correctly does not consider that to mean they're the same type - and it was like an hour's work to build Rust and first figure out where to attempt my changes. You can submit a PR and after a robot puts it in a pile to be looked at, actual humans will ask you about your proposed change, they can ask other robots to check whether it works OK on the huge piles of real world Rust out there, and so on.