|
|
Subscribe / Log in / New account

Are those languages really more suitable for fast prototyping?

Are those languages really more suitable for fast prototyping?

Posted Oct 29, 2024 10:09 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Are those languages really more suitable for fast prototyping? by taladar
Parent article: The performance of the Rust compiler

It matches my experience of working in Rust and Python; I prefer to write in Rust, because I'm rarely genuinely writing a prototype, but rather writing "version 0" of a program, and I will not normally be given time to rewrite in another language later. But if I was genuinely allowed to prototype things most of the time, I'd be writing the prototype to throw away in Python, and writing "version 0" in Rust.

Yesterday, I wrote a short Rust program (10 lines of my code, plus dependencies) to create a PNG representing squared paper. It took about 15 minutes computer time (and about 30 minutes elapsed time), of which about 5 was spent waiting on the compiler to compile my code as the person I was doing this for changed their mind about what the PNG should look like (colour/greyscale, line thickness, square size).

Today, after reading your comment, I redid the same work in Python, including making the same changes; it took under 10 minutes, because changes to my code were near-instant.

Neither program did a significant amount of compute (after all, when prototyping, you don't work on large data sets if you can avoid it), both came up with the same result. The Rust program uses significantly less CPU time when compiled in the debug profile, but neither of them used enough CPU time to make a difference to me as the person running the code. And the Rust program is more robust against errors if I come back round to it - e.g. instead of using a naming convention, as in Python, Rust's type system will prevent me from modifying constants, or assigning to the wrong thing - but I'm very unlikely to ever run this code ever again.

I still used Rust first, because I'm habituated to working in environments where "never run this code again" is a dangerous statement, but if Rust could build faster, it'd also have been the faster language to use. Recompiling my code, there are two things that would speed it up considerably:

  1. Python used precompiled dependencies for PyPNG, and thus didn't cost me 20 seconds just building dependencies.
  2. Python's runtime was about 1 second for each experiment; Rust in dev profile took about 250 ms to determine that no building needed to take place, and about 1 second (according to cargo build) to build and link my program after a change to a constant. On the other hand, Rust takes about 800 ms to run in dev profile, where Python took 1 second - and just for fun, I rebuilt in release profile, which ran in 11 ms, but increased the "change to a constant" time to about 2 seconds.

If Rust could get the wall-clock time for a small change down below 200 ms, it'd be faster than Python for prototyping here on this laptop. And that's not impossible with parallelism; for most of the build time, I have only one CPU thread of the 16 on this laptop saturated; if Rust in dev profile could saturate 5 CPU threads on average, then Rust in dev profile (1 CPU-second) would have a faster edit/compile/run loop than Python does.

And note that I'm mostly ignoring the time it takes to build dependencies here; at least in theory, Rust could eliminate that 20 seconds of highly parallel work by downloading pre-compiled artefacts instead of building from scratch.


to post comments

Are those languages really more suitable for fast prototyping?

Posted Oct 30, 2024 9:19 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Okay, a batch program like that where you run it and it immediately does what you want is about the optimal case for Python though since it minimizes runtime for testing.

If you have some sort of GUI or web app where you need to navigate to your functionality to test each time those few seconds of compilation time are quickly dwarfed by that repetitive walltime-overhead during the test run.

Are those languages really more suitable for fast prototyping?

Posted Oct 30, 2024 13:41 UTC (Wed) by farnz (subscriber, #17727) [Link]

But by the time I'm putting together a GUI that needs testing, and navigation to functionality, Python is still faster because I run the prototype inside pdb or similar, and tweak it "live", instead of having to recompile and navigate again. Once I've finished prototyping, I might have to restart and re-navigate a few times, but that's when I'm going from the prototype to version 0.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds