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

31–40 of 47 posts

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

#31

Post by loop2 »

vvanders wrote: post #29
kentonv wrote: post #25

> Type inference removes the need to specify types explicitly over and over. These days with C++11's auto, this is improved a lot. It's not full type inference, but eliminates most of the boilerplate, and arguably what's left you really want to keep for documentation purposes. > The object-oriented representation of a trivial sum type as an inheritance hierarchy of classes is needlessly inefficient. This use case str…

I've been really happy with C++ lambda's lately. Would be nice to see Rust's Option and Result ported over to C++ since I find that error handling extremely elegant compared to most C++ approaches.

Option has been around for a while as boost::optional or now std::experimental::optional. Result is coming and has a reference implementation as boost::expected. There's also a type-erased option type, "any".

They're quite nice, especially with a few trivial additions for ergonomics.

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

#32

Post by kxyvr »

mercurial wrote: post #13
tacos wrote: post #3

And now's a perfect time to reflect on how the two languages evolved during the past decade. C++ obviously moved forward quite a bit -- cleaning up the loop constructs in particular. OCaml? Uh... there's F# for realists, Scheme for optimists, and Haskell for pedants. If you're actually writing OCaml web apps in OWebl I'd sure love to know why. Amazon released a native C++ SDK for AWS if you're into pain. If you're us…

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

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

#33

Post by vvanders »

loop2 wrote: post #31
vvanders wrote: post #29

Earlier quoted context omitted.

I've been really happy with C++ lambda's lately. Would be nice to see Rust's Option and Result ported over to C++ since I find that error handling extremely elegant compared to most C++ approaches.

Option has been around for a while as boost::optional or now std::experimental::optional. Result is coming and has a reference implementation as boost::expected. There's also a type-erased option type, "any". They're quite nice, especially with a few trivial additions for ergonomics.

Yup, except you lost me as soon as you said "boost". I enjoy my fast compile speeds very much. :)

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

#34

Post by lholden »

vvanders wrote: post #29
kentonv wrote: post #25

> Type inference removes the need to specify types explicitly over and over. These days with C++11's auto, this is improved a lot. It's not full type inference, but eliminates most of the boilerplate, and arguably what's left you really want to keep for documentation purposes. > The object-oriented representation of a trivial sum type as an inheritance hierarchy of classes is needlessly inefficient. This use case str…

I've been really happy with C++ lambda's lately. Would be nice to see Rust's Option and Result ported over to C++ since I find that error handling extremely elegant compared to most C++ approaches.

Already done (kinda). There is no match exhaustion, but C++ is getting an option type. (Part of the library fundamentals TS). http://en.cppreference.com/w/cpp/experimental/optional

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

#35

Post by lholden »

mempko wrote: post #8

I would love to see this updated using C++14.

Totally. I've been mulling over the idea of porting it. Would be interesting to see how the performance compares vs the older style.

Between C++14 and some template usage, I'd imagine the LOC could be reduced a lot.

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

#36

Post by xorblurb »

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)

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

#37

Post by zem »

rwmj wrote: post #27
tacos wrote: post #14

Earlier quoted context omitted.

Looks like solid work all around. But if we could weigh it relative to the advancements in C++ the last decade, it wouldn't even show up on the scale. Red Hat could pay someone to do exactly what you're doing in many other languages with the exact same results. The only difference would be that the language in question would show up on the StackOverflow list of "most loved" or "most wanted" languages. Rust shows up i…

Did you read my reply? To quote: "easy linking to C libraries, and builds a native binary with no extra dependencies, speed ... safety, robustness, compact source code size" There are certainly many more popular languages, but few with that combination of advantages. The project started in 2009, so you should discount any languages which were not mature before that date. There are a few people at Red Hat and outside…

even in 2015 i can only think of D, go and haskell that would work as viable alternatives.

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

#38

Post by altern »

vvanders wrote: post #28
mden wrote: post #22

Earlier quoted context omitted.

I was curious about whether using a vector over list would have any effect even though the size is so small and the answer seems no (I guess as it could be expected). It seems like the listed OCaml program has a default level of 9 where as the C++ one uses 6? Times using original listing (minus print stmts): $ time ./ray-cpp real 0m3.369s user 0m3.347s sys 0m0.010s $ time ./ray-ml real 0m4.710s user 0m4.703s sys 0m0.…

List is just one part that makes the C++ impl sub-optimal. All the scenes are allocated on the heap so you're actually bouncing around memory twice(once for the next link list entry, second for the actual heap allocation). Lastly the virtual call again has the chance to cache miss(although probably only once seeing as we've just got a few impls). In a small example like this there's a good chance that most of the hea…

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

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

#39

Post by vvanders »

altern wrote: post #38
vvanders wrote: post #28

Earlier quoted context omitted.

List is just one part that makes the C++ impl sub-optimal. All the scenes are allocated on the heap so you're actually bouncing around memory twice(once for the next link list entry, second for the actual heap allocation). Lastly the virtual call again has the chance to cache miss(although probably only once seeing as we've just got a few impls). In a small example like this there's a good chance that most of the hea…

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.

Post reply on HN