8 ms·

Ray Tracing in Nim

147 points by beagle3 6y ago

treeform 6y 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 https://forum.nim-lang.org/t/5363#33576
- mhh__ 6y ago
  Is that not true of almost any other systems language (depends if you count Go as a systems language)?
  - beagle3 6y 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
    - entha_saava 6y ago
      > Rust feels like a court filing. But HackerNews and Reddit told me that rust is very ergonomic after two weeks and if you do something in other languages that you can't do in rust, you are doing it wrong and it needs to be fixed.
    - mhh__ 6y ago
      I've been paid to work on D so no need to preach to the converted. I'll have a look at Nim too.
  - mratsim 6y 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).
- bjourne 6y ago
  Does nim support SIMD intrinsics? Without those you aren't getting "C performance."
  - lasagnaphil 6y 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 https://github.com/numforge/laser/blob/master/laser/simd.nim
memexy 6y 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_parody 6y ago
  https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer probably has a lot of examples in it's implementation
  - memexy 6y ago
    Yup. That's what popped up when I searched. Thanks for the reference though.
    - mratsim 6y ago
      The CUDA kernels are stored here: - https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_kernels_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso... With the higher order function: - https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_higher_order_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso... And their code generation: - https://github.com/mratsim/Arraymancer/blob/master/src/tensor/operators_blas_l1_cuda.nim#L37 https://github.com/mratsim/Arraymancer/blob/master/src/tenso... It's possible to avoid inlining C++ like they do here: - https://github.com/jcosborn/cudanim/blob/338be782/cuda.nim#L219-L222 https://github.com/jcosborn/cudanim/blob/338be782/cuda.nim#L... but I will explore that later.
      - memexy 6y ago
        Thanks.
nautilus12 6y ago
Anyone have thoughts on nim vs rust for data centric (Scala like) applications
- qeternity 6y 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 6y ago
    Yeah, I like nim but it isn't going to offer and advantage over python in this regard.
  - ca_parody 6y 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 https://github.com/nim-lang/needed-libraries/issues/77
  - logicchains 6y 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.
jswny 6y ago
I keep seeing Nim and it looks really productive and very interesting! Does anyone know how it compares to Zig?
- entha_saava 6y 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.
  - cercatrova 6y 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.
    - entha_saava 6y ago
      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.
- remix2000 6y 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-FFIbindings https://ziglang.org/#Integration-with-C-libraries-without-FF... †) http://terralang.org/ http://terralang.org/ EDIT: replaced nasty star parsed as markup with a caret. Sorry.
tastyminerals 6y 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 6y 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.
  - hippyhippo 6y 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.
bjourne 6y 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.
- bjourne 6y ago
  Here is the code if anyone is interested: https://github.com/bjourne/c-examples/blob/master/programs/smallpt.cpp 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 6y 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?

147 points by beagle3 6y 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 https://forum.nim-lang.org/t/5363#33576

mhh__ 6y ago
Is that not true of almost any other systems language (depends if you count Go as a systems language)?
- beagle3 6y 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
  - entha_saava 6y ago
    > Rust feels like a court filing. But HackerNews and Reddit told me that rust is very ergonomic after two weeks and if you do something in other languages that you can't do in rust, you are doing it wrong and it needs to be fixed.
  - mhh__ 6y ago
    I've been paid to work on D so no need to preach to the converted. I'll have a look at Nim too.
- mratsim 6y 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).
bjourne 6y ago
Does nim support SIMD intrinsics? Without those you aren't getting "C performance."
- lasagnaphil 6y 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 https://github.com/numforge/laser/blob/master/laser/simd.nim

memexy 6y 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_parody 6y ago
https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer probably has a lot of examples in it's implementation
- memexy 6y ago
  Yup. That's what popped up when I searched. Thanks for the reference though.
  - mratsim 6y ago
    The CUDA kernels are stored here: - https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_kernels_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso... With the higher order function: - https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/incl_higher_order_cuda.nim https://github.com/mratsim/Arraymancer/blob/master/src/tenso... And their code generation: - https://github.com/mratsim/Arraymancer/blob/master/src/tensor/operators_blas_l1_cuda.nim#L37 https://github.com/mratsim/Arraymancer/blob/master/src/tenso... It's possible to avoid inlining C++ like they do here: - https://github.com/jcosborn/cudanim/blob/338be782/cuda.nim#L219-L222 https://github.com/jcosborn/cudanim/blob/338be782/cuda.nim#L... but I will explore that later.
    - memexy 6y ago
      Thanks.

nautilus12 6y ago

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

qeternity 6y 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 6y ago
  Yeah, I like nim but it isn't going to offer and advantage over python in this regard.
- ca_parody 6y 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 https://github.com/nim-lang/needed-libraries/issues/77
- logicchains 6y 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.

jswny 6y ago

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

entha_saava 6y 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.
- cercatrova 6y 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.
  - entha_saava 6y ago
    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.
remix2000 6y 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-FFIbindings https://ziglang.org/#Integration-with-C-libraries-without-FF... †) http://terralang.org/ http://terralang.org/ EDIT: replaced nasty star parsed as markup with a caret. Sorry.

tastyminerals 6y 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 6y 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.
- hippyhippo 6y 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.

bjourne 6y 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.

bjourne 6y ago
Here is the code if anyone is interested: https://github.com/bjourne/c-examples/blob/master/programs/smallpt.cpp 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 6y 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?