
Ray Tracing in Nim - beagle3
https://nim-lang.org/blog/2020/06/30/ray-tracing-in-nim.html
======
treeform
What I like about Nim is that you can always get C performance if you just
spend a little time. You can always use a profiler you like (I use vTune) to
get to the hot loops and fix them.

See my post here: [https://forum.nim-lang.org/t/5363#33576](https://forum.nim-
lang.org/t/5363#33576)

~~~
mhh__
Is that not true of almost any other systems language (depends if you count Go
as a systems language)?

~~~
beagle3
Nim still Mostly retains its pythonic nature (fun and readable) even when you
do whatever’s needed for C/C++ level performance.

I think it’s exceptional in that it feels lightweight while delivering great
performance, and it has no “glass ceiling” of any sort.

Rust and D have no ceiling either; but D feels like a better C++ and Rust
feels like a court filing.

D is definitely under-appreciated if you prefer C feel to Python feel

~~~
mhh__
I've been paid to work on D so no need to preach to the converted. I'll have a
look at Nim too.

------
tastyminerals
With all due respect, Nim is a great language performance wise however I fail
to see how is it different from D. Many advertised features have been present
in D for a long time.

Syntax wise Nim it is a step back. It's hard to read and understand while any
C/C++ dev will have next to no effort reading through D code. And of course
while D is C ABI compliant it interoperates with C++ well too.

I seriously doubt that Nim or any other language in this regard has better
metaprogramming than D.

Nim might have a speed overhead in certain tasks but that depends on a
benchmark. Besides, does Nim have anything similar to NumPy which is actually
faster? D does.

~~~
hellofunk
I agree that it is strange that, in all of the discussions surrounding
relatively modern languages, and new technologies, while nim and rust and many
others frequently get mentioned, so rarely it seems that anyone talks about D.
Wonder why that is? I’m genuinely curious.

~~~
throwaway_se099
There is a perception that D has shot its bolt, having been around for quite
some time without making a noticeable impact, either by itself or by
influencing the mainstream.

~~~
tastyminerals
It was a developed by too few ppl from the start and by the time it became
usable it was way too late

------
memexy
This is pretty good. I was wondering about CUDA and it looks like Nim has
support for writing CUDA kernels. Is there a repository of kernel
implementations I can take a look at?

~~~
ca_parody
[https://github.com/mratsim/Arraymancer](https://github.com/mratsim/Arraymancer)
probably has a lot of examples in it's implementation

~~~
memexy
Yup. That's what popped up when I searched. Thanks for the reference though.

~~~
mratsim
The CUDA kernels are stored here:

\-
[https://github.com/mratsim/Arraymancer/blob/master/src/tenso...](https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_kernels_cuda.nim)

With the higher order function:

\-
[https://github.com/mratsim/Arraymancer/blob/master/src/tenso...](https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_higher_order_cuda.nim)

And their code generation:

\-
[https://github.com/mratsim/Arraymancer/blob/master/src/tenso...](https://github.com/mratsim/Arraymancer/blob/master/src/tensor/operators_blas_l1_cuda.nim#L37)

It's possible to avoid inlining C++ like they do here:

\-
[https://github.com/jcosborn/cudanim/blob/338be782/cuda.nim#L...](https://github.com/jcosborn/cudanim/blob/338be782/cuda.nim#L219-L222)

but I will explore that later.

~~~
memexy
Thanks.

------
jswny
I keep seeing Nim and it looks really productive and very interesting! Does
anyone know how it compares to Zig?

~~~
entha_saava
Zig is mainly focused on low level programming - every function that allocates
takes an allocator argument, there are lot of builtin functions to do low
level bit twiddling, doesn't hide any control flow, etc..

Nim is mainly a productivity language. You have GC by default, extensive
stdlib, lot of syntax sugar and metaprogramming features. You can create
untraced pointers and do manual memory management.

Thus, among the new crop of compiled programming languages

Productivity languages with GC: Crystal, Nim, Go, Swift (automatic
refcounting, not GC)

Manually memory managed, low level: Zig, Rust, Odin. Nim can do manual memory
management as well but doesn't seem to be primary use case.

~~~
cercatrova
Even though Rust has manual memory management, I'd say it can be pretty high
level due to its functional programming features that are nearly equivalent to
Haskell or OCaml.

~~~
entha_saava
True. But rust's aim (at least as its original author envisioned) is for low
level systems programming where having automatic memory management is not
desired. The aim of safety in low level programming is nice, but that comes
with tradeoffs. Eg: not allowing certain patterns and thinking about memory /
ownership even when not required.

Some vocal minority of rust fanboys herald it like these are not a problem and
rust is right tradeoff for every programming task, as if when crab god doesn't
like the way you structured your program there is fundamental mistakes in your
programming and you should have fixed them anyway. That kind of dishonest,
blanket statements are what leads to Rust Evangelism Strike Force memes.

------
bjourne
Has anyone had any luck reproducing the benchmark figures given for the
smallpt program? When I try, gcc handily beats nim in the multi-threaded
scenario and they are neck and neck in the single-threaded one. For 10 samples
per pixel:

    
    
        g++ multi-threaded : 33.52
        nim multi-threaded : 36.90
        g++ single-threaded: 75.78
        nim single-threaded: 75.95
    

nim 1.2.0, g++ 10.1.0. I used the flags -O3 -march=native -mtune=native -Wall
-Werror for gcc and the default flags for nim.

~~~
bjourne
Here is the code if anyone is interested:
[https://github.com/bjourne/c-examples/blob/master/programs/s...](https://github.com/bjourne/c-examples/blob/master/programs/smallpt.cpp)
With a few tweaks, g++ beats nim both in the multi-threaded and single-
threaded setups.

------
blackrock
Since Nim transpiles itself down to C code, and then compiles it to assembly,
and machine code. Then, how does Nim avoid the occasional security issues,
buffer overflows, and other undefined behavior problems that always arises
from C written programs?

Is this not a concern? Or is Nim fully vetted, that it doesn’t use defective C
libraries?

------
nautilus12
Anyone have thoughts on nim vs rust for data centric (Scala like) applications

~~~
qeternity
If they’re data centric, would you not be better off with vanilla python? If
you have numpy do the heavy lifting, it’ll be as fast plus all the
syntactic/ecosystem benefits

~~~
nimmer
Numpy is nice but pure-Nim applications appear to outperform it easily:

[https://narimiran.github.io/2018/05/10/python-numpy-
nim.html](https://narimiran.github.io/2018/05/10/python-numpy-nim.html)

[https://github.com/mratsim/Arraymancer](https://github.com/mratsim/Arraymancer)

~~~
qeternity
Interesting but given the low total execution time, the majority of time in
the numpy implementation is going to be spent initializing CPython.

I think if this were on the order of minutes/hours you would see numpy
outperform.

