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

Ray Tracing in Nim

nim-lang.org

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Ray Tracing in Nim

#51

Post by entha_saava »

pietroppeter wrote: post #28
tastyminerals wrote: post #19

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 Ni…

* 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…

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

Re: Ray Tracing in Nim

#52

Post by remix2000 »

jswny wrote: post #8

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

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.

Re: Ray Tracing in Nim

#53

Post by tastyminerals »

pietroppeter wrote: post #28
tastyminerals wrote: post #19

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 Ni…

* 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…

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.

Re: Ray Tracing in Nim

#54

Post by tastyminerals »

pietroppeter wrote: post #28
tastyminerals wrote: post #19

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 Ni…

* 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…

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.

Re: Ray Tracing in Nim

#55

Post by matthiaswh »

tastyminerals wrote: post #53
pietroppeter wrote: post #28

Earlier quoted context omitted.

* 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…

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…

The table is out of date. Nim is post 1.0[1] now and stable, and has few breaking changes.

[1] https://nim-lang.org/blog/2019/09/23/version-100-released.ht...

Re: Ray Tracing in Nim

#56

Post by 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.

Re: Ray Tracing in Nim

#57

Post by bjourne »

treeform wrote: post #2

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

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

Re: Ray Tracing in Nim

#58

Post by lasagnaphil »

bjourne wrote: post #57
treeform wrote: post #2

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

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

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

Re: Ray Tracing in Nim

#59

Post by mhh__ »

beagle3 wrote: post #23
mhh__ wrote: post #16

Earlier quoted context omitted.

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

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…

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

Re: Ray Tracing in Nim

#60

Post by memexy »

mratsim wrote: post #34
memexy wrote: post #14

Earlier quoted context omitted.

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

The CUDA kernels are stored here: - https://github.com/mratsim/Arraymancer/blob/master/src/tenso... With the higher order function: - https://github.com/mratsim/Arraymancer/blob/master/src/tenso... And their code generation: - 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#L... but I wi…

Thanks.
Post reply on HN