Ray Tracing in Nim

https://nim-lang.org/blog/2020/06/30/ray-tracing-in-nim.html

by beagle3 • 6 years ago

147 66 6 years ago

treeform• 6 years ago

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

mhh__2• 6 years ago

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

beagle33• 6 years ago

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

mratsim5• 6 years ago

It depends. On current CPUs the bottlenecks are in order:

- IO processing

- Memory

- CPU

In particular, any language that doesn't have any escape hatch to do manual memory management will have troubles to optimize memory bound workloads.

In scientific computing, machine learning, deep learning and in image processing, in particular stencil code, 90% of the workloads are memory bound (the CPU-bound being those involving convolutions and matrix multiplications once you get the data at its proper place, and things involving exponentiation or trigonometric functions).

bjourne3• 6 years ago

Does nim support SIMD intrinsics? Without those you aren't getting "C performance."

lasagnaphil• 6 years ago

Absolutely yes, you just need to let the Nim compiler read the C headers for <immintrin.h> or something like that. Here’s a nice SIMD wrapper for Nim: https://github.com/numforge/laser/blob/master/laser/simd.nim

memexy3• 6 years ago

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_parody3• 6 years ago

https://github.com/mratsim/Arraymancer probably has a lot of examples in it's implementation

memexy3• 6 years ago

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

nautilus122• 6 years ago

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

qeternity2• 6 years ago

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

nkozyra• 6 years ago

Yeah, I like nim but it isn't going to offer and advantage over python in this regard.

ca_parody3• 6 years ago

The main reasons I see for nim in scientific computing over python are:

(a) you need performance for applications outside of numpy / pandas & you want to avoid writing a C extension to do so (nim is also actually a good choice for python extensions via nimpy - if you are still using python as the main language of your project/system)

(a2) you want good concurrency (some would say python's async/await is good - but it feels too little too late to me) & you at least want the option of parallelism (like this article takes advantage of)

(b) you want / need the powerful macro system for dsls / custom (compile-type-checkable) language extensions.

There is a good future for nim in scientific computing (frankly, there is a good present) - but for it to be better, people need to be willing to forgo some of the ecosystem (when possible) and to help build that future.

https://github.com/nim-lang/needed-libraries/issues/77

logicchains2• 6 years ago

The OP said Scala-like. A big advantage of Scala/Spark over Python is more compile-time checking: the code is much less likely to fail at runtime. Particulary helpful for production code (e.g. pipelines). For people coming from an engineering background (as opposed to data science), Python's lack of any static type checking for data processing code can be a big productivity killer. In that sense, Nim might be able to offer similar advantages to Scala.

nimmer• 6 years ago

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

https://narimiran.github.io/2018/05/10/python-numpy-nim.html

https://github.com/mratsim/Arraymancer

zamalek• 6 years ago

Apart from Python, you could look at Julia.

untog• 6 years ago

I can't speak to data centric but I was looking at both Rust and Nim for a project recently. I love the syntax of Nim and it feels incredibly easy to write in. The power of the macro system is amazing.

But the Rust community is so much bigger, pretty much every question I had was answered after a quick Google search.

steve_adams_86• 6 years ago

I agree. I really struggled to get help with certain problems with Nim, but with Rust it has been fairly trivial to find help. The community is very active and helpful.

Nim does have a syntax I prefer more, but overall I find I’m quite a bit more productive with Rust.

ca_parody3• 6 years ago

its been a couple years - but mratsim (the same person who authored this ray tracing post) wrote this (which is at least tangential to your question) https://medium.com/@MARatsimbazafy/why-rust-fails-hard-at-sc....

Some of the rust problems mentioned (like clone for arrays) have been fixed. Others, like static generics, have not been (AFAIK).

totalperspectiv• 6 years ago

That depends on why you use Scala?

Do you use Scala as a better Java? If so, Nim may be what you want.

Do you use Scala for its incredible type system? Rust may be what you want.

Do you use Scala for its functional tendencies? Rust may be what you want.

As an aside, I've found that once you get over the Rust learning curve, writing 'correct' programs is easier in Rust than any other language I've used. And for data centric applications, being 'correct' is extra important.

nautilus122• 6 years ago

What about scalable data? Like spark applications? I am familiar with weld but seems like more mature distributed computing is still on the horizon

jswny• 6 years ago

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

entha_saava4• 6 years ago

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.

cercatrova2• 6 years ago

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.

remix2000• 6 years ago

Zig supports zero-effort C binding by reusing existing C headers instead of wrapping them^. The only other language known to me having such feature while not actually being a superset of C is Terra†. I feel like we are still several light years away from the Holy Grail of programming languages, which would retain full compatibility while also being extremely productive. Walter Bright (the creator of DLang) once stated that the least age to develop a feasible programming language is 40-ish+, so hopefully generation raised in the world of modern computing will manage to find the ultimate syntactic solution.

^) https://ziglang.org/#Integration-with-C-libraries-without-FF...

†) http://terralang.org/

EDIT: replaced nasty star parsed as markup with a caret. Sorry.

doteka• 6 years ago

Not sure the age of the original author is very relevant. GvR was 35 when he started work on Python. Chris Lattner was 31 with Swift, Brendan Eich was 33 with JS. These are some of the most used languages today. I’d say it’s more a matter of being in the right place at the right time to serve a particular use case.

tastyminerals9• 6 years ago

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• 6 years ago

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.

hippyhippo3• 6 years ago

Because D is effectively dead/has lost its momentum completely?

If you look at the development surrounding D, the stdlib got its allocator module around 5 years back IIRC in experimental. It is still not stable. Same for many other modules. Due to lack of resources not much work is being poured into the stdlib. Same for developer tooling, some people have created ide tools and stuff, however they are not AST based and so most of the things that should work don't work. Yet, instead of pouring resources into these issues, the resources are poured into developing 3 compilers dmd, gcc based d, and llvm based d.

Also, the readability issue posted by the op are subjective. To me, and many others, Nim is much much more readable and elegant than C/D/C++/Rust.

Also regarding OP's >Many advertised features have been present in D for a long time.

Nim has macros and many features are based on or around macros, whereas D will never get macros. IIRC D uses reflection based stuff?

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

Well, you are wrong (Unless you like reflection more than macros). Nim, haxe, etc. languages have very powerful AST based macros.

throwaway_se099• 6 years ago

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.

tastyminerals9• 6 years ago

Depends on where do you read ;) But tbo D community concentrates around D forum and in majority consists of former C/C++ veterans. Being a younger language Nim lures younger and active members who probably never heard of D anyway.

Historically D never advertised itself enough imho and that is a shame. I blame the lack of proper leadership and management at the start. Its early development progress has been a rocky ride many languages would not survive at all but it did and for me personally it's a testament to its maturity and resilience newer languages still have to prove.

cercatrova2• 6 years ago

Here's a good overview: https://news.ycombinator.com/item?id=23494490

Basically, D was too little, too late, with a lack of build tools, while Rust, Nim etc are designed from the beginning to have certain features and have easy to use build tools like cargo.

m4r35n3572• 6 years ago

D has a native IDE and working REPL OOTB. They are all jealous!

logicchains2• 6 years ago

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

D's macros work through string interpolation. There are certainly people who find the Nim approach of generating a typed AST to be preferable.

pietroppeter• 6 years ago

* For a full comparison of features D vs Nim see [0], or a more succint selection of items by Nim's creator [1]; these also contains some remarks about metaprogramming and C/C++ interoperability.

* syntax-wise you could also argue that is a step forward: it embraces Python syntax and it would be easy to read and understand for all Python devs.

* Nim does have a "faster NumPy" by the same author of the article: [2]

[0] https://github.com/timotheecour/D_vs_nim [1]: https://forum.nim-lang.org/t/1779#11098 [2]: https://mratsim.github.io/Arraymancer/index.html

dmix• 6 years ago

it embraces Python syntax

Nim looks most like Pascal syntax to me, with a bit of Python

entha_saava4• 6 years ago

[0] is a great comparison, are there other comparisons of this kind?

tastyminerals9• 6 years ago

Thanks. So here are the points for D according to the table. Very few breaking changes because language is pretty mature. Not sure if Nim is as stable but just this one fact is enough for me personally.

D has slices, ranges and lazy evaluation which is a joy when you do data number crunching. Nim does not have them.

Also no mention of dpp in a table is surprising tbo.

D PRs take time mostly because they go through a rigorous community review. And by that I mean your PR does need to hit the quality bar. Which is only good and does not make a language a sandbox of community features like C++. See the PR for macros in D and why it didn't happen. Another reason is the lack of people of course.

tastyminerals9• 6 years ago

I read through Arraymancer readme and the rationale and got very mixed feelings about the project and its purpose. It's everything and nothing at the same time. NumPy like syntax and functionality, sklearn algorithms and look, deep learning too, here is and example and some screens which we borrowed from Scipy. Seriously? Sorry if that might be too judgemental but it sounds and looks amateurish. And I thought of benchmarking it against D mir... Also, the name... And this is what I feel about Nim in general, rushed and undercooked.

mratsim5• 6 years ago

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.

On the other hand, people coming from Python, Ruby, Pascal, Ada will appreciate the minimal amount of sigils.

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

Can you write an Embedded DSL + compiler running at compile-time in D

- https://github.com/numforge/laser/tree/master/laser/lux_comp...

Can you write a cryptographic library with hex conversion to big integer and modular arithmetic running at compile-time in D?

- https://github.com/mratsim/constantine/blob/master/constanti...

Can you generate a state machine that lowers down to optimized computed gotos with no dynamic allocation suitable for multithreading runtimes and embedded devices and able to display the actual graph at compiletime?

- https://github.com/mratsim/Synthesis

Can you describe x86 opcodes in a declarative way for a JIT assembler and do all the rex/modrm/sib computation at compile-time?

- https://github.com/mratsim/photon-jit/blob/master/photon_jit...

And the same thing for an emulator?

- https://github.com/mratsim/glyph/blob/master/glyph/snes/opco...

Can you implement async as a library?

Can you emulate classes with ADTs to solve the expression problem, avoid cache misses and multithreading problem due to OOP and the double indirection due to the visitor pattern?

- https://github.com/mratsim/trace-of-radiance/blob/master/tra...

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.

It does:

- https://github.com/mratsim/Arraymancer

With CPU, OpenCL and Cuda backends (in differing state of maturity)

and it's being used for data analysis for example ancestry prediction:

- http://home.chpc.utah.edu/~u6000771/somalier-ancestry.html

You can even run a neural network and see its training live:

- https://github.com/Vindaar/NeuralNetworkLiveDemo

AFAIK D doesn't have any plotting library while Nim has plot.ly integration and a ggplot2 port in pure Nim:

- https://github.com/brentp/nim-plotly

- https://github.com/Vindaar/ggplotnim

And lastly nim can easily call Python:

- https://github.com/yglukhov/nimpy

or be called from Python:

- https://github.com/Pebaz/nimporter

tastyminerals9• 6 years ago

Also, all good points. Appreciate that.

moonchild2• 6 years ago

I suspect d's metaprogramming is not as good as nim's (haven't used the latter), though it's better than metaprogramming of every language I've used without macros.

That said, it can do all of the metaprogramming-related tasks you mention.

Sir_Substance• 6 years ago

I gave quite a few statically-compilable language a try a few years back before settling on nim as my "fat binary" language of choice.

D was a contender, but ultimately the reason I dropped it was I was unable to compile a hello world on my laptop. Now, that machine is not fast, but it is actually pretty new, it's a very low end 2017 dell machine, and it turned out that bootstrapping a D environment requires a midspec machine or it literally cannot complete.

I donno man, D seems to have a "last 5%" problem. It looks good on the surface, but as you start looking into it you discover that the bootstrap tools are fat as hell, the core library has a weird split in GC styles, the doc is inconsistent. Everything you do in D is 5% harder than it needs to be, nothing is buttery smooth. Overall, all those 5% multiply together to make it a 20-30% worse experience overall, although I couldn't point at any one thing and say "that is what has killed D".

beagle33• 6 years ago

Many advertised features have been present in D for a long time.

They have also been in Nim for a very long time. The initial Nim version was released in 2008, and is comparable to D2 (started 2007) rather than D1 (started 2001). So they are effectively contemporary, and gained a lot of the features at comparable times (and with some cross pollination, I'm sure, although I wasn't there to witness it).

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.

There is no accounting for taste, but Nim syntax is Pythonic; Python is generally regarded as one of the easiest (if not THE easiest) real programming languages to pick up. Both D and Nim get hairy when you use advanced metaprogramming features, but at the surface level -- Nim is likely to be easier to pick up except if your audience is exclusively C/C++ programmers (and maybe even then).

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

You should learn some Lisp then, the mother of all metaprogramming systems :) and also, you should look at Nim, it's not quite Lisp but it goes as far as (and perhaps farther than) Lisp-without-reader-macros. This example[0] embeds a compile time type-checked syntax-checked SQL dialect into Nim.

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.

Yes, Nim has ArrayMancer (by mratsim, who wrote this raytracer as well) which is considerably faster than Numpy and also natively supports CUDA and OpenCL, IIRC, even though it's still younger so it's not as complete as Numpy. But Nim also has Nimpy which lets you mix Python and Nim with the least friction (and generates one executable that works, and works equally well and quickly, with whatever Python you happen to use at runtime - Py27, Py36, Py37, Py38 - not familiar with anything else that does). There was also NimBorg which provided similar mixing with Lua, but it seems to be abandoned now for lack of interest.

And of course while D is C ABI compliant it interoperates with C++ well too.

Nim is source level as well as ABI level compliant with C, C++ and Objective C (you can use C++ exceptions and objects natively, no need for an "extern C" wrapper; same with Objective C). And also natively compatible with Javascript (though obviously not in the same compilation unit ...) . D is under appreciated, for sure, but Nim is definitely not lesser, and it's about as old.

[0] https://juancarlospaco.github.io/nim-gatabase

tastyminerals9• 6 years ago

Thank you for the detailed answer. It clears things up.

tokai• 6 years ago

Syntax wise Nim it is a step back. It's hard to read and understand

This reads like satire to me. You shouldn't claim your feelings as objective truth.

bjourne3• 6 years ago

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.

bjourne3• 6 years ago

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

blackrock• 6 years ago

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?

Ray Tracing in Nim

Related Stories