[HN Gopher] Comparison of space and time required to build each ...
___________________________________________________________________
Comparison of space and time required to build each compiler for
system language
Author : teleforce
Score : 34 points
Date : 2023-05-05 09:45 UTC (13 hours ago)
(HTM) web link (forum.devtalk.com)
(TXT) w3m dump (forum.devtalk.com)
| teleforce wrote:
| Somehow V conveniently left out its closet competitor D language
| where DMD, D's reference compiler can compile itself and the
| entire standard library in less than 5 seconds with parallelism
| turned off [1].
|
| [1] Ask HN: Why do you use Rust, when D is available?
|
| https://news.ycombinator.com/item?id=23494490
| zellyn wrote:
| It seems disingenuous not to include Zig in this kind of
| comparison. Possibly Jai too.
| grumpyprole wrote:
| Don't forget Ada/Spark and ATS.
| michaelsbradley wrote:
| and Nim
| internetter wrote:
| This is clearly just more V nonsense. It's cool that V compiles
| fast and all, but https://news.ycombinator.com/item?id=31793554
| elcritch wrote:
| Even if it's compiling the entire compiler in 0.7 seconds it's
| certainly not generating good code. Even then it's dubious and
| likely skipping semantic checks, etc.
| internetter wrote:
| It's also worth noting that way back when, V could compile
| itself in almost 0.1s[0]. Now it's 7x slower. Of course, 0.1s
| -> 0.7s is very different than 10s -> 70s, but I think it is
| just another example of how programs start lightweight, but
| end up weighed down very, very quickly. What will V look like
| when all the promised features actually work?
|
| [0] https://fast.vlang.io/2020.html
| kibwen wrote:
| The Rust compiler only takes 45 minutes to build if you're also
| including the time to build LLVM from scratch. Given that the
| page mentions V's "Clang backend" and later asserts that Clang
| takes one hour to build, that means that it's fair to say that
| the V compiler builds itself in one hour and one second.
| djoldman wrote:
| hrm... wget http://download.savannah.gnu.org/rele
| ases/tinycc/tcc-0.9.27.tar.bz2 tar -xzf tcc-0.9.27.tar.bz2
| cd tcc-0.9.27 ./configure time make
|
| generates: ... make 5.01s user 0.43s
| system 95% cpu 5.720 total
|
| so I guess there are some fast c compilers too...
| marosgrego wrote:
| Also git clone https://git.sr.ht/~mcf/cproc
| cd cproc git submodule init --update time make qbe
| time make
|
| generates: make qbe 0.81s user 0.07s system
| 97% cpu 0.901 total make 0.83s user 0.07s system 99% cpu
| 0.902 total
| danbruc wrote:
| _Most objects (~90-100%) are freed by V's autofree engine: the
| compiler inserts necessary free calls automatically during
| compilation. Remaining small percentage of objects is freed via
| reference counting.
|
| The developer doesn't need to change anything in their code. "It
| just works", like in Python, Go, or Java, except there's no heavy
| GC tracing everything or expensive RC for each object._
|
| How are cycles handled, especially if the code does not require
| any special handling? The documentations only says that this is
| still work in progress and currently a garbage collector is used
| by default.
|
| _For developers willing to have more low level control, autofree
| can be disabled with -manualfree, or by adding a [manualfree] on
| each function that wants manage its memory manually. (See
| attributes).
|
| Note Autofree is still WIP. Until it stabilises and becomes the
| default, please avoid using it. Right now allocations are handled
| by a minimal and well performing GC until V's autofree engine is
| production ready._
___________________________________________________________________
(page generated 2023-05-05 23:02 UTC)