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

C++ vs. OCaml: Ray tracer comparison (2005)

ffconsultancy.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#41

Post by sanderjd »

vvanders wrote: post #39
altern wrote: post #38

Earlier quoted context omitted.

I did a qucik and dirty test with levels = 14. # program time change ./ray-ml: 21.46 # Original ocaml ./ray-cpp: 17.63 # Original c++ ./ray-cpp-no-dtor: 13.86 # Removed all cleanup, ocaml doesn't do it ./ray-cpp-2: 8.90 # Changed list to vector ./ray-cpp-3: 7.89 # Removed virtual functions ./ray-cpp-4: 5.64 # Preallocated large array for all Groups

Solid stuff, glad to see someone testing my assumptions :). If there's one thing I could teach new CS-grads it's how much your memory access patterns(and cache) really-effing-matter. Everything else is almost noise in comparison.

I'm pretty curious about this: have memory access patterns and cache awareness become more of a big deal in the past decade or so, or has it only recently reached my awareness? I studied CS in the early 2000s and while I was aware of various trade-offs between contiguous and linked data structures, it's only in the last few years that the importance of cache (and non-"system" languages' widespread flouting of its importance) has really bubbled up in my consciousness.

It's certainly likely that I just didn't take the right kinds of classes, or that I did but just missed or failed to really internalize this, but I'm curious if something else is going on. Has the bottleneck increasingly become memory rather than CPU? Have we more thoroughly exhausted other areas of optimization?

I was thinking about this while watching a talk[0] given by someone from Google about data structures in the STL, which decried that the standardized specification for `std::unordered_map` more or less forces an implementation to use buckets instead of the more cache-friendly technique of probing. I'm sure that the people who standardized it were very competent, which makes me think that, at least at the time, buckets were thought to be the better implementation.

[0]: https://www.youtube.com/watch?v=fHNmRkzxHWs

Edit: Added video link.

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#42

Post by agumonkey »

xorblurb wrote: post #36
vardump wrote: post #24

From article: > With two cross-overs, there is little difference between the performance of the OCaml and C++ implementations. Note that the C++ was compiled with CPU-specific optimizations whereas the OCaml binary will run on any 486 compatible. Ok, so the author is suggesting numerical C++ compiler generated SSE2+ code is comparable to OCaml 486, and thus with only very slow stack based x87 FPU available? SSE beats…

The author seems to not know enough about what he is talking about. For ex. he claims that the performance of passing a struct Vec { double x, y, z; } by value would be very poor, which is trivially not true, and he uselessly wrote some constructors for this and similar POD structs, even explicitly claiming they are needed in C++ (and not in OCaml, implying superiority of the latter on the conciseness criteria)

The compiler would have inferred the same constructor code ?

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#43

Post by blt »

sanderjd wrote: post #41
vvanders wrote: post #39

Earlier quoted context omitted.

Solid stuff, glad to see someone testing my assumptions :). If there's one thing I could teach new CS-grads it's how much your memory access patterns(and cache) really-effing-matter. Everything else is almost noise in comparison.

I'm pretty curious about this: have memory access patterns and cache awareness become more of a big deal in the past decade or so, or has it only recently reached my awareness? I studied CS in the early 2000s and while I was aware of various trade-offs between contiguous and linked data structures, it's only in the last few years that the importance of cache (and non-"system" languages' widespread flouting of its imp…

> Has the bottleneck increasingly become memory rather than CPU?

Yes.

Besides the basic memory latency vs. CPU clock speed issue, there's also:

- CPU caches have gotten bigger, so the payoff of making an program cache-friendly is larger

- CPUs have gained SIMD vector ALUs and increased superscalar behavior, so the CPU is capable of processing more data in per clock cycle

- A cultural shift happened after the freewheeling Moore's Law era ended in the mid-2000s, and people started examining performance more closely

http://gec.di.uminho.pt/discip/minf/ac0102/1000gap_proc-mem_...

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#44

Post by unhammer »

joe_the_user wrote: post #17

Amazingly, there is no easy way to define a type in C++ which can be "one of these or one of these", e.g. a sphere or a group in this case. The author may have assumptions I'm missing here but the standard way to have a "one of these or one of these" thing is to have two classes inherent from a given abstract base class and use a pointer to the base class. If one wants the device specifically as a type, one could wra…

https://programmers.stackexchange.com/questions/231092/is-pa... points out some differences.

Some of the things that make me miss OCaml variants/sum types when I have to use C++ subclassing/dynamic dispatch instead: * very lightweight syntax both for creating them and matching on them (and lightweight representation; variants without arguments are just ints under the hood) * compile-time checks on exhaustiveness in pattern matches (so no unexpected NULL's!)

Note that OCaml also allows open/polymorphic variants for the cases where you want to allow expanding the list of options – here the compiler will only check that e.g. a function that matches on only `A|`B won't be sent a `C, although it can be sent a member of a type that contains only `A's. This is typically used for public interfaces where you want to let your implementation expand later (e.g. your current function accepts `UTF8|`UTF16 but you might later decide to accept `WTF8 as well).

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#45

Post by progman »

thelucky41 wrote: post #7

The benefit of this comparison is not that the languages have nearly identical performance, but that OCaml can be briefer while accomplishing the same task, with 47% less lines of code. Saying nothing about comparing LOC in an imperative/OO language to a functional one, does the brevity actually help a reader's understanding of the code at all? It seems to me that a lot of the comparisons call out descriptions of exp…

Most people just consider the raw execution time to measure performance. In long-term applications that really matters.

In usual applications however most people don't realize that the development time should also be considered. In that sense a program written in a few lines of Python could actually outperform a super optimized C++ program because it usually requires more time and effort to code the same thing in C++.

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#46

Post by mercurial »

kxyvr wrote: post #32
mercurial wrote: post #13

Earlier quoted context omitted.

Scheme and OCaml don't have that much in common really (unless you mean derivatives like typed racket, but even then). OWebl, in spite of its shiny website, is not what I would call "popular". You want to look at opium[1] or ocsigen/eliom [2]. Don't know what you have against OPAM, it's the best language-specific dependency manager I know. 1: https://github.com/rgrinberg/opium 2: http://ocsigen.org/eliom/

My problem with OPAM is that there's no Windows port, which makes developing OCaml programs on Windows difficult at best. In theory, we can compile all of the dependencies by hand, but in practice, the Oasis build scripts refuse to work on Windows for most packages that I've tried. Personally, I would love to use OCaml for my company's projects, but the lack of true cross platform tooling makes it impossible at the m…

That's a fair criticism. I think there is also an ongoing effort to make OPAM work on Windows, so this may get better in the future.

Re: C++ vs. OCaml: Ray tracer comparison (2005)

#47

Post by sanderjd »

blt wrote: post #43
sanderjd wrote: post #41

Earlier quoted context omitted.

I'm pretty curious about this: have memory access patterns and cache awareness become more of a big deal in the past decade or so, or has it only recently reached my awareness? I studied CS in the early 2000s and while I was aware of various trade-offs between contiguous and linked data structures, it's only in the last few years that the importance of cache (and non-"system" languages' widespread flouting of its imp…

> Has the bottleneck increasingly become memory rather than CPU? Yes. Besides the basic memory latency vs. CPU clock speed issue, there's also: - CPU caches have gotten bigger, so the payoff of making an program cache-friendly is larger - CPUs have gained SIMD vector ALUs and increased superscalar behavior, so the CPU is capable of processing more data in per clock cycle - A cultural shift happened after the freewhee…

Thanks, this is what I had suspected, but it seems to be left unstated in everything I've read.
Post reply on HN