Write your C++ compilers in a modern high-performance functional language

[Jon Harrop]

Besides, just because one implementation/algorithm is asymptotic worse
than another does not mean that it'll *not* perform better for all
practical sets of inputs, quicksort for one is O(n^2) which is worse
than mergesort, but often performs better.

Ok, maybe there is a platform and implementation and benchmark out there
where this is faster using the C++ approach but we haven't encountered in
in cartography or scientific visualization on any of 32- or 64-bit Intel,
AMD, PPC and Linux, Mac OS X or Windows.

I think this is an asymptotic complexity that you hit very early on. I have
not benchmarked our code rendering a single trivial object, when C++ might
be faster. In fact, when you're rendering a trivial scene, this code will
not be the bottleneck so the performance will at least be almost identical.

 

[Michael DOUBEZ]

Jon Harrop a écrit :

Indeed. We benchmarked our (soft) real-time vector graphics renderer written
in C++ and OCaml:

http://www.ffconsultancy.com/products/smoke_vector_graphics/

The OCaml was 5x faster in the all-important worst case. The incremental
garbage collector makes it much easier to optimize worst-case performance
in OCaml compared to C++.

Does this mean that the following page is obsolete:
http://www.ffconsultancy.com/languages/ray_tracer/comparison.html

It doesn't show the perfs you mentionned.

Now I can believe that an OCaml raytracer implementation you've worked
on for years can be faster than a C++ one you didn't.

And yet again, I don't see what real time has to do here. A ray tracer
has no stimuli to answer to and a raytracer is useless for this field of
application.

Michael

 

[Kai-Uwe Bux]

Ok, maybe there is a platform and implementation and benchmark out there
where this is faster using the C++ approach but we haven't encountered in
in cartography or scientific visualization on any of 32- or 64-bit Intel,
AMD, PPC and Linux, Mac OS X or Windows.

I think this is an asymptotic complexity that you hit very early on. I
have not benchmarked our code rendering a single trivial object, when C++
might be faster. In fact, when you're rendering a trivial scene, this code
will not be the bottleneck so the performance will at least be almost
identical.

Again: none of this is topical in this group; please read the FAQ on what
goes here and what belongs elsewhere; and please have the courtesy to post
accordingly.


Thanks

Kai-Uwe Bux

 

[Jon Harrop]

Does this mean that the following page is obsolete:
http://www.ffconsultancy.com/languages/ray_tracer/comparison.html

And yet again, I don't see what real time has to do here. A ray tracer
has no stimuli to answer to and a raytracer is useless for this field of
application.

Absolutely. Ray tracing is not relevant.

 

[Jon Harrop]

Again: none of this is topical in this group; please read the FAQ on what
goes here and what belongs elsewhere; and please have the courtesy to post
accordingly.

Feel free to post workarounds in C++ if you have any. I certainly failed to
come up with any (short of writing a GC).

 

[kwikius]

That hasn't been true for over a decade. For example, OCaml is only 9%
slower than optimized C++ on this ray tracer benchmark:

http://www.ffconsultancy.com/languages/ray_tracer/

What's the rationale for the empty dtors ?

C++ version looks a good candidate for converting to my physical
quuantities library... todo

regards
Andy Little