Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig self hosted compiler is now capable of building itself

github.com

Post reply on HN
Print view View original

261–270 of 285 posts

Re: Zig self hosted compiler is now capable of building itself

#261

Post by elcritch »

dralley wrote: post #259
elcritch wrote: post #234

Earlier quoted context omitted.

To clarify I meant comparing how int8/int16's are packed in structs vs struct bitfields. Can't recall about the stack rules. Here's more discussion: http://www.catb.org/esr/structure-packing/ https://github.com/Twon/Alignment/blob/master/docs/alignment... Also ARM for example doesn't have 8/16 bit registers so int8 or int16 will use a 32bit register: https://stackoverflow.com/a/23716920 Curiosity got to me, perhaps Z…

Are the two using the exact same algorithm?

Yes, as far as I can tell [1]. It's a simple Tape algorithm. Neither had any crazy SIMD, threads, no custom containers, etc. They use almost the same function names (and look the same as the Go version too). I used `time -l` https://stackoverflow.com/a/30124747 for memory usage.

Note I ran the benchmarks locally (MacBook Air M1) because the reported benchmark uses the older (default) Nim GC while I only use Nim+ARC. I also had to fix the Zig code and it took a few tries to get the signed/unsigned int conversions working. I tried tweaking flags for both a bit as well to see how stable they were. Zig's memory usage was pretty constant. Nim had a small speed vs memory tradeoff that could be tweak-able, but the defaults used the least memory.

Overall I'd expect exact memory usage by language(s) to vary some by benchmark and one random benchmark isn't conclusive. Still I didn't find anything to indicate Zig is clearly better than other new generation languages. Manual memory management might actually be worse than letting a compiler manage it in some cases.

1: https://github.com/kostya/benchmarks/tree/master/brainfuck

Re: Zig self hosted compiler is now capable of building itself

#262

Post by elcritch »

blippage wrote: post #247
elcritch wrote: post #179

Earlier quoted context omitted.

Sort of left it to the readers and hopefully encourage people to investigate for themselves. It's far too easy to get into "this benchmark vs this benchmark", etc. Memory usage is overall a complicated topic, which I think Andrew's comment doesn't do justice to. Granted the Zig team has done some impressive work, much of the memory usage & bloat in the C++ world comes from real world programs and libraries and the in…

Odin doesn't work on 32-bit ARM, which was a disappointment to me.

Bummer, looks like an intriguing language.

Re: Zig self hosted compiler is now capable of building itself

#264

Post by kaba0 »

Tozen wrote: post #257
kaba0 wrote: post #255

Earlier quoted context omitted.

It doesn’t help that plenty of claims on the V website was simply ridiculous, like transpiling C to V and making it memory safe (or some insane compile speed claim transpiling Doom, if I remember well?). Also, memory safe without a runtime and without a rust-like borrow-checker.. these are simply impossible lies. Not sure about its current state, hopefully these are all removed and the sane claims are in progress.

It is better to actually use the language, particularly as it is presently, versus refer to old disputable controversies from years ago. There are no false claims on their website (in my opinion), though of course there will be things people can dispute and argue about, as there is with all developing programming languages. If a person does their research, then they would have clarity on the subjects. This is partly…

Then could you please tell me the actual memory model of the language? Because that is the numero uno thing I want to know about a language, yet I constantly read contradicting thing on vlang’s model. (Is it boehm gc?)

Re: Zig self hosted compiler is now capable of building itself

#265

Post by sitkack »

exikyut wrote: post #105
sitkack wrote: post #58

Earlier quoted context omitted.

You can also target C through Wasm. https://github.com/WebAssembly/wabt/tree/main/wasm2c

My genuine question is what sort of code-size and/or performance impact the translation imposes. The simple example in the README.md seems straightforward enough, but I wonder if there are any pathological explosions in practice.

That would be an interesting undergraduate paper. Perf, Size, by primary language, by toolchain, linker, post processor (dead code elimination, etc).

For a pathological explosion, you mean something like a Zip Bomb? Wasm and C are pretty close together in their semantics, Wasm hides the stack and prevents jumping into the middle of a function (CFI, Control Flow Integrity). I think the code bloat should be on the order of some multiple of the smallest interpreter.

I just did a quick scan of Wasm interpreters (3 in Rust, 1 in C)

    yblein/rust-wasm ~4kloc
    rhysd/wain ~16kloc
    paritytech/wasmi ~25kloc
    wasm3/wasm3 ~22kloc (C)
My hunch is that the expanded code would be approximately (2x-5x interpreter + bin.wasm). I just did a spot check with doom.wasm, I am wrong. The resulting expanded C code when compiled to Arm is 2x the wasm binary size.

    4.1M wasidoom.o
    1.8M wasidoom.wasm
https://en.wikipedia.org/wiki/Zip_bomb

Re: Zig self hosted compiler is now capable of building itself

#266

Post by geophertz »

pcwalton wrote: post #153
geophertz wrote: post #30

Earlier quoted context omitted.

> written in Zig instead of C++, uses significantly less memory, and represents a modest performance improvement That's particularly interesting considering the rust compiler in rust has never been as fast as the original OCaml one

Huh? That's not true at all. It took over 30 minutes to compile the self-hosted Rust compiler with the OCaml compiler, when rustc was far smaller than it is today. rustboot was agonizingly slow, and one of the main reasons why I was so anxious to switch to rustc back in those days was compilation speed. I was there and had to suffer through this more than virtually anyone else :)

My source: https://pingcap.com/blog/rust-compilation-model-calamity#boo...

> 7 femto-bunnies - rustboot building Rust prior to being retired

> 49 kilo-hamsters - rustc building Rust immediately after rustboot's retirement

> 188 giga-sloths - rustc building Rust in 2020

Re: Zig self hosted compiler is now capable of building itself

#267

Post by randyrand »

pjmlp wrote: post #98
randyrand wrote: post #83

Earlier quoted context omitted.

Because hand written assembly is readable!

It might be, but have you also validated the microcode executing it? Or the Verilog/VHDL for the logic gates used by the CPU, for that matter?

Security is multifaceted.

Ideally, yes. But you still will be more secure than having multiple security holes.

Re: Zig self hosted compiler is now capable of building itself

#268

Post by super_flanker »

Tozen wrote: post #257
kaba0 wrote: post #255

Earlier quoted context omitted.

It doesn’t help that plenty of claims on the V website was simply ridiculous, like transpiling C to V and making it memory safe (or some insane compile speed claim transpiling Doom, if I remember well?). Also, memory safe without a runtime and without a rust-like borrow-checker.. these are simply impossible lies. Not sure about its current state, hopefully these are all removed and the sane claims are in progress.

It is better to actually use the language, particularly as it is presently, versus refer to old disputable controversies from years ago. There are no false claims on their website (in my opinion), though of course there will be things people can dispute and argue about, as there is with all developing programming languages. If a person does their research, then they would have clarity on the subjects. This is partly…

> There are no false claims on their website

Are you sure about this? Let's look at their first feature, "No null". Ironically every vlang project including compiler itself is full of `isnil`[0] check.

This is just trailer for their lies; once start digging you'd find misrepresentation in every major features they advertise.

0: https://github.com/vlang/v/search?q=isnil

Re: Zig self hosted compiler is now capable of building itself

#269

Post by Tozen »

kaba0 wrote: post #264
Tozen wrote: post #257

Earlier quoted context omitted.

It is better to actually use the language, particularly as it is presently, versus refer to old disputable controversies from years ago. There are no false claims on their website (in my opinion), though of course there will be things people can dispute and argue about, as there is with all developing programming languages. If a person does their research, then they would have clarity on the subjects. This is partly…

Then could you please tell me the actual memory model of the language? Because that is the numero uno thing I want to know about a language, yet I constantly read contradicting thing on vlang’s model. (Is it boehm gc?)

Vlang has multiple methods of optional memory management. This should not be so hard to grasp, as this is the case for other languages too. Take Nim, for example. It has several: gc:refc, gc:markAndSweep, gc:boehm, gc:go, gc:arc, etc...

Vlang has both the options of Autofree and GC, or you can do it manually. As the language is still developing (like other languages such as Crystal, Odin, and Zig), users should know these memory management options are experimental and still being refined.

Re: Zig self hosted compiler is now capable of building itself

#270

Post by Siira »

cercatrova wrote: post #226
Siira wrote: post #220

Earlier quoted context omitted.

I haven’t tried Zig yet, but I liked Common Lisp better than Go and Rust for fast CLI apps/scripts. You need to dump an image with all your deps already loaded, and then you can run small scripts with instant compilation very fast. It’s an ergonomic language with good IDE support in emacs. There are some rough edges around (inconsistent API design, the package manager not using HTTPS, …), but tolerable.

Common Lisp doesn't offer features like sum types right? I am under the impression that it is a dynamically typed language like most Lisps, but I could be wrong.

It has optional typing, but as it’s fast without it, I haven’t dug into them. I don’t know about a union type though.
Post reply on HN