Comment by aidenn0 | Hacker News Reader

Comment by aidenn0 | Hacker News Reader

Parent Full thread

> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. Having worked with languages that target C, machine code and C, I will make a few predictions:

Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C.

> Basically he likes Nim compiled to C better than just Rust. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones.

Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do.

I'm also wary of the mentioned productivity gains; I simply do not feel as confident in the correctness of Nim code I write as I do Rust code I write. This actually isn't solely due to the enforced move semantics of Rust, but due to a lot of the comments about Nim in the article linked in the issue; Nim and Rust surprise me about the same amount, but with Rust the surprise would yield (sometimes inscrutable) errors from the compiler; Nim was more likely to yield surprising runtime behavior.

The two languages I use most often are C and Common Lisp.

C has some surprising runtime corners, but the language (at least pre C11, which I haven't used much yet, so can't comment on) is small enough that I can keep it all in my own head.

Common Lisp also has some surprising behaviors, and it's a big language, but this is mitigated by 2 things:

1) Common Lisp allows very concise code; this very often lets me keep all of the portion of the software I'm working on in my head (versus C, where I keep all the language in my head)

2) Superior tooling; SLIME lets you very quickly drill down and look at what's happening. Combined with #1 it is very fast to find where the model of the code in my head diverges from reality, so most bugs are short lived.

> Compiling to C shouldn't hurt reliability anymore than compiling to LLVM.

How does Nim deal with the fact that null pointer dereferences, signed integer overflow, and shifts by more than the width of a type are undefined behavior in C, and therefore the optimizer can cause memory safety problems if they occur?

Edit: I just tested myself:

- Nim emits checks for signed overflow, but they don't seem to optimize to `jo`. Nim should be emitting these intrinsics where possible: http://clang.llvm.org/docs/LanguageExtensions.html#checked-a...

- Nim does not emit checks for shifts by more than the width of a type. Therefore you can get undefined behavior.

- Nim blindly dereferences null pointers, which is undefined behavior. In fact, I managed to get clang to optimize out the null pointer check here:

    echo("Counting to ten: ")
    for i in countup(1, 10):
        var k: ref int = nil
        var l = k[]
        echo($l)

In debug mode, this program throws an exception; in release mode, this program prints zero over and over for me, because clang optimized out the null pointer dereference per C semantics. I could probably make this program write arbitrary memory without using any of Nim's unsafe features.

I'm not sure if all three of these are Nim bugs, but they seem like it. Compiling to C is tricky.

Shrug, you left out:

- Conservative GC marking of the stack.

- No stack overflow check in release mode.

Compiling to C is not tricky, it is horrible and we don't do it for the fun of it! That said, clang has lots of options to tame C's undefined behaviour. Guess what, you can enable these too for C code generated by Nim.

> That said, clang has lots of options to tame C's undefined behaviour. Guess what, you can enable these too for C code generated by Nim.

They aren't really designed for performance though. For example, `-fsanitize-undefined-trap-on-error -fsanitize=null` emits explicit comparisons against null for every pointer load instead of catching SEGV like (for example) Java or Go do.

From what you're saying it sounds like maximum performance plus memory safety isn't a design goal for Nim. That's totally reasonable. It does mean that Nim and Rust have very different aims, however, and comparisons between the two need to take this into account.

> - No stack overflow check in release mode.

-fstack-check in GCC guarantees that the guard page will be hit (as long as there is one), assuming no undefined behaviour like buffer overflows. It has a negligible cost and should really be enabled by default. It only has to add a one byte write per uninitialized page on the stack, and a less efficient dynamic alloca due to probes.

Okay, that's just bad[1]. It's not hard to avoid the undefined behaviors in C with machine generated code; it's not that there are a lot of undefined behaviors, just that they are often non-intuitive. A computer doesn't care if they are intuitive or not, so avoiding them in code-gen isn't that hard.

It sounds like Nim passes the lack of safety of C up to the user a bit (e.g. in the null pointer dereferences) in exchange for improved performance.

1: And by "bad" I mean "not a tradeoff I would make." I actually can see good reasons for doing so, it just doesn't fit my priorities.

> Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do.

Rust can cross-compile, at least for a limited set of targets (see https://github.com/npryce/rusty-pi/blob/master/doc/compile-t... for an example)

The main pain point for the moment is that you need to build the cross-compiler yourself (which takes a while), and since the language changes every week, you have to recompile the cross-compiler every time.

You can also use the 'flexible target spec' to cross-compile for anything LLVM can.

It's still not super easy: you need a standard library that's been cross-compiled, IIRC. There's some small things like that, but it's mostly a polish issue.

LLVM's optimization passes are pretty awesome, but so are GCC's. My guess is that both methods can get you good performance, and that what performance you do get depends on how good the LLVM bitcode or C you generate is. I've tried using Rust and Nim for very small programs (Project Euler problems and some text munging), and currently it seems to me that (1) Nim's executables are always a little faster than Rust's (but not much), and (2) Nim compiles way faster than Rust.

One reason you may find text munging to be faster in Nim is that we have an different algorithm than they do that's better in the worst case but slower in many small cases. Plus, Rust's are UTF-8 aware by default, and Nim's are not.

(This doesn't mean that it's still not the same from a user's perspective, just explaining a bit about why, and that this might change in the future.)

Those are good points about string processing (and I wasn't aware of them, thanks!), but when I said Nim programs typically run a little faster I didn't mean only text munging, also my Project Euler type code: lots of loops, arrays randomly accessed and integer arithmetic. For those numeric programs the difference is pretty small, so maybe it's just the same slight edge that GCC sometimes has on Clang. (I guess I could try installing Clang, recompiling the Nim programs with Clang instead and checking if that brings their performance closer to the Rust ones.)

> Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C.

I would say "performant C" is the target, it being rather readable is nice too, though. I have a list of some benchmarks down here: https://github.com/def-/nim-benchmarksgame#nim-implementatio...

Reply on news.ycombinator.com