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

Programming language ray tracing benchmarks project

github.com

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Programming language ray tracing benchmarks project

#51

Post by oconnor663 »

remcob wrote: post #46
oconnor663 wrote: post #36

Earlier quoted context omitted.

Different languages' benchmarks might not be equally well-written / optimized. In particular, I'd expect C and Rust to be very close to each other, and a 20% gap between them is a red flag. Rules like "code should be simple, as in, easy to read and understand" are also hard to judge, especially near the top of the list where there's a lot of pressure to optimize. Is SIMD easy to understand? What if it's in a library?…

Not necessarily. Because C allows the pointer manipulation, the compiler can in general not make assumptions about pointer aliasing. This prevents some optimizations. In Rust, the compiler has more information/control over memory layout/lifetime and can therefore make stronger optimizations. Automatic vectorization is an area where this helps a lot, and raytracing can benefit a lot here. 20% sounds reasonable to me.

That's a good point, I didn't think about the effect on autovectorization. Do you think that's what's happening here? My impression was that getting good vector code out of the compiler usually requires manually tuning things.

Re: Programming language ray tracing benchmarks project

#52

Post by weberc2 »

jerf wrote: post #48
weberc2 wrote: post #24

Earlier quoted context omitted.

That's a big jump between OCaml and Go. I'm not familiar with ray tracing, but skimming the source code it mostly looks like it's doing floating point math; it doesn't look like it's using the runtime (no allocations, no virtual function calls, no scheduling, etc), so I'm surprised that Go is performing relatively poorly. I wonder if the performance gap is attributable to some overhead in Go's function calls? I know…

There's a variety of possibilities. Lerc mentions GC as one possibility, which could definitely be the case. Another one that would be high on my "first guess" list is that everything above it has much better optimizers, and raytracing code is one of the places this is really going to show. Go does basically very little optimization, because it prioritizes fast compilation. (Where Go "wants" to play is that same benc…

Like I responded to Lerc, I don't see any allocs in the hot path here.

Also, as I edited, I updated the Go version to pass by reference and that put it on par with C (and also per my update, I may have mistranslated somehow).

Re: Programming language ray tracing benchmarks project

#53

Post by niofis »

hackerpacker wrote: post #35
z92 wrote: post #33

Earlier quoted context omitted.

Julia was astonishing. It's a high level language that's performing almost like C. Last time I checked, many years back, the spec was changing and the run time did crash. Guess it has gone a long way since. The other one is Lua. My assumption was that it's one of the lightest and fastest language around. Looks like "fastest" isn't true in some cases.

shouldn't rust being faster than C be something of a red flag that they aren't quite the same algorithm? Or that the algorithm is sub-optimal?

It got me thinking as well, so I ventured and did some experiments on this, and found that the main difference is the algorithm used for the RNG; C's std lib uses a slower one (which also is thread safe, and butchered OpenMP performance). You can take a look at a more apples to apples comparison in the latest update for crb.c which uses a xor128 rng; rust is still a little faster (especially when going multithreaded), but not quite the difference in the README file, still need to get some time to update it.

Re: Programming language ray tracing benchmarks project

#54

Post by lossolo »

weberc2 wrote: post #24
kenhwang wrote: post #14

Ordered by realtime, fastest to slowest for those like me who got annoyed by the scrolling up and down trying to compare: Rust (1.13.0-nightly) 1m32.392s Nim (0.14.2) 1m53.320s C 1m59.116s Julia (0.4.6) 2m01.166s Crystal (0.18.7) 2m01.735s C Double Precision 2m26.546s Java (1.7.0_111) 2m36.949s Nim Double Precision (0.14.2) 3m19.547s OCaml 3m59.597s Go 1.6 6m44.151s node.js (6.2.1) 7m59.041s node.js (5.7.1) 8m49.170s…

That's a big jump between OCaml and Go. I'm not familiar with ray tracing, but skimming the source code it mostly looks like it's doing floating point math; it doesn't look like it's using the runtime (no allocations, no virtual function calls, no scheduling, etc), so I'm surprised that Go is performing relatively poorly. I wonder if the performance gap is attributable to some overhead in Go's function calls? I know…

Probably because Go version is different, compare C vector operations with Go vector operations. C version is operating on pointer without allocating new vector, Go version is allocation new vector on every op.

EDIT: Look at C code assembly, it's generating mostly SIMD instructions and using xmm registers. That's why it's faster. Golang compiler still do not have autovectorization implemented that's why it's so much slower in this case.

EDIT2: It seems Go version also uses SSE here, which is nice. So probably unnecessary allocation from my original post was the reason.

Re: Programming language ray tracing benchmarks project

#55

Post by Lerc »

weberc2 wrote: post #45
Lerc wrote: post #34

Earlier quoted context omitted.

I'm not familiar with go but I seem to recall it is garbage collected. If so it may be something to do with the creation of new vectors on the heap instead of the stack. The compiler would have to determine the full lifetime of the vector value to be able to bump it to the stack. That's an optimization, and sometimes it's just not possible (but probably is here). In the C instance no such optimization is necessary. T…

Is it creating vectors in the hot path? I'm not seeing it. Go does some escape analysis (the optimization you're referring to), but it's pretty conservative.

All of the vector operations return new vectors instead of mutating.

    func v3_add (a, b v3) v3 {
     return v3{x: a.x + b.x, y: a.y + b.y, z: a.z + b.z}
    }
A sensible approach for maintainable code but without knowing if a and b are used elsewhere the compiler can't reuse the space they occupy. If C can't figure it out, it can just stick a new one on the stack which doesn't cost too much.

This is, of course, Rust's bread and butter which is probably why it takes the top spot.

Re: Programming language ray tracing benchmarks project

#56

Post by weberc2 »

lossolo wrote: post #54
weberc2 wrote: post #24

Earlier quoted context omitted.

That's a big jump between OCaml and Go. I'm not familiar with ray tracing, but skimming the source code it mostly looks like it's doing floating point math; it doesn't look like it's using the runtime (no allocations, no virtual function calls, no scheduling, etc), so I'm surprised that Go is performing relatively poorly. I wonder if the performance gap is attributable to some overhead in Go's function calls? I know…

Probably because Go version is different, compare C vector operations with Go vector operations. C version is operating on pointer without allocating new vector, Go version is allocation new vector on every op. EDIT: Look at C code assembly, it's generating mostly SIMD instructions and using xmm registers. That's why it's faster. Golang compiler still do not have autovectorization implemented that's why it's so much…

I modified the Go version to pass references (see my second edit) and that made up the difference (or I mistranslated).

Re: Programming language ray tracing benchmarks project

#57

Post by weberc2 »

Lerc wrote: post #55
weberc2 wrote: post #45

Earlier quoted context omitted.

Is it creating vectors in the hot path? I'm not seeing it. Go does some escape analysis (the optimization you're referring to), but it's pretty conservative.

All of the vector operations return new vectors instead of mutating. func v3_add (a, b v3) v3 { return v3{x: a.x + b.x, y: a.y + b.y, z: a.z + b.z} } A sensible approach for maintainable code but without knowing if a and b are used elsewhere the compiler can't reuse the space they occupy. If C can't figure it out, it can just stick a new one on the stack which doesn't cost too much. This is, of course, Rust's bread a…

Those are copied on the stack, not heap allocated, so the GC wouldn't come into play.

Re: Programming language ray tracing benchmarks project

#58

Post by niofis »

piinbinary wrote: post #44

The haskell version can be made >= 3x faster by making the computations non-lazy, e.g. -data Vector3 = Vector3 {vx::Float, vy::Float, vz::Float} deriving (Show) +data Vector3 = Vector3 {vx :: !Float, vy :: !Float, vz :: !Float} deriving (Show)

This seems like a nice improvement, could you send a PR for it?

Re: Programming language ray tracing benchmarks project

#59

Post by ygra »

alkonaut wrote: post #8
kyberias wrote: post #4

I don't think the C# time is representative. I suspect Mono is really slow here. I just ran it with VS 2015 in 1 min 24 sec.

The C# implementation looks flawed (uses reference types for vectors etc). Using value types and .NET Core should give a much better result than that. Will try to remember doing a PR.

I've just tried out a bit with .NET Core 2.2.

Baseline of the non-multithreaded variant on my machine: 1m56s

Making Vector3 a struct: 1m3s

Making Vector3 a readonly struct: 1m1s

Making Hit and Ray a struct: 1m26s

Will test more tomorrow, I guess, but the most obvious change already yields a 2× speedup. This was also without any profiling, so I don't even know what I did there.

Re: Programming language ray tracing benchmarks project

#60

Post by niofis »

azhenley wrote: post #3

This is awesome! More good press for Nim. There is a big variation in performance, some of which I find surprising. Do you know what exactly causes some languages to be so slow (e.g., small objects being created and garbage collected frequently)?

Did some testing and found that it boils down to three things: RNG algorithm used in the standard library, forced use of double precision floating point numbers (the case for OCaml and javascript), and like you mentioned, memory management.

EDIT: forgot to mention the obvious things: compiler/interpreter maturity and inherent overhead.

Post reply on HN