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

41–50 of 68 posts

Re: Ray Tracing in Nim

#41

Post by [deleted] »

cercatrova wrote: post #31
hellofunk wrote: post #20

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Ray Tracing in Nim

#42

Post by m4r35n357 »

throwaway_se099 wrote: post #22
hellofunk wrote: post #20

Earlier quoted context omitted.

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.

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.

Or, alternatively: Once something _works_ it is no longer interesting . . . ?

Re: Ray Tracing in Nim

#43

Post by mratsim »

mhh__ wrote: post #16
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

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

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).

Re: Ray Tracing in Nim

#44

Post by entha_saava »

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…

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

Re: Ray Tracing in Nim

#45

Post by Sir_Substance »

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…

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".

Re: Ray Tracing in Nim

#46

Post by beagle3 »

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…

> 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

Re: Ray Tracing in Nim

#47

Post by tokai »

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…

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

Re: Ray Tracing in Nim

#48

Post by tastyminerals »

beagle3 wrote: post #46
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…

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

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

Re: Ray Tracing in Nim

#49

Post by nimmer »

qeternity wrote: post #5
nautilus12 wrote: post #4

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

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

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

Re: Ray Tracing in Nim

#50

Post by tastyminerals »

mratsim wrote: post #38
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…

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

Also, all good points. Appreciate that.
Post reply on HN