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

[Jon Harrop]

Flying Frog just launched the OCaml Journal:

http://www.ffconsultancy.com/products/ocaml_journal/free/introduction.html?clcpp

The free first article covers the basics of the OCaml programming language,
which is ideally suited to the writing of C++ compilers. ;-)

 

[Zeppe]

Flying Frog just launched the OCaml Journal:

http://www.ffconsultancy.com/products/ocaml_journal/free/introduction.html?clcpp

The free first article covers the basics of the OCaml programming language,
which is ideally suited to the writing of C++ compilers. ;-)

Do you *really* think that this argument is enough for your post to be
in-topic in this group?

Maybe you didn't have this insight yet, so let me give you a suggestion.
Nobody gives a clue about this so-called OCaml here. Fly elsewhere.

Regards,

Zeppe

 

[John Harrison]

Do you *really* think that this argument is enough for your post to be
in-topic in this group?

Maybe you didn't have this insight yet, so let me give you a suggestion.
Nobody gives a clue about this so-called OCaml here. Fly elsewhere.

Regards,

Zeppe

It annoys me that this guy doesn't even have the decency to post his
spam anonymously. He's an obsessive I think, unaware of how he's percieved.

john

 

[Jon Harrop]

Do you *really* think that this argument is enough for your post to be
in-topic in this group?

Absolutely! Programmers currently using C++ stand more to benefit from OCaml
that almost any other. Anyone interested in OOP design patterns and/or
templates can learn a lot from this.

Nobody gives a clue about this so-called OCaml here.

Then they need an introductory article on OCaml.

 

[Markus Schoder]

Absolutely! Programmers currently using C++ stand more to benefit from
OCaml that almost any other.

I beg to differ. OCaml and most other modern functional programming
languages have piss poor handling of processor native data types.

OCaml for instance only uses 31 bits to represent an integer value the
remaining bit is used for internal purposes. I assume for floating point
where there are no spare bits the situation is even worse since probably
additional data needs to be passed around all the time.

In other words for computationally intensive tasks which is a
particularly strong point of C++ functional programming languages suck
(yes I did some real world benchmarking/profiling).

Add to that the unbearably ugly operator syntax (I think you need to use
+. and *. or something similar for floating point values) and you have
one sitting duck of a language.

Then they need an introductory article on OCaml.

Been there done that. I quite like some functional languages (e.g.
Haskell is much nicer than OCaml but has even more performance problems)
but at the end of the day there are only some specific domains where they
are of value but not as general purpose tools.

I hope you stop your proselytising now that you know that people have a
clue about this stuff and just decided that C++ still has its value.

 

[Jon Harrop]

In other words for computationally intensive tasks which is a
particularly strong point of C++ functional programming languages suck
(yes I did some real world benchmarking/profiling).

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/

and is algorithmically faster than the C++ standard library for many common
operations, e.g. 10,000x faster for set_union:

http://groups.google.com/group/comp.lang.functional/msg/cdae678b2d6e7ae6?hl=en

On real performance-intensive programs, OCaml is typically much faster than
C++ given the same development time.

at the end of the day there are only some specific domains where they
are of value but not as general purpose tools.

On the contrary, any language that lacks reliable garbage collection is
domain specific.

 

[Diego Martins]

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/

9% is too slow for any decent realtime application

go sell your fish elsewhere

 

[Jerry Coffin]

[ ... ]

9% is too slow for any decent realtime application

For roughly the ten bazillionth time, "real time" has relatively little
to do with "fast" and everything to do with "predictable" --
specifically that the speed is predictable.

9% slower (or even 50% slower) is not necessarily a deal-breaker where
real-time is concerned. What's a deal-breaker is when you don't know how
slow something can be. Benchmarks can tell a lot about average cases,
but generally show far less about the worst case -- but for real-time
work, the worst case matters a LOT.

OTOH, anybody who starts out with the premise that "language X is only
Y% slower than language Z" is either an idiot or badly in need of
psychiatric help. There is no way to compare one language to another in
terms of speed -- you can really only compare one particular body of
code written in one language and compiled with one set of compilers to
another body of code written in another language and compiled with
another set of compilers.

To have any hope of meaning anything, those bodies of code both need to
bear a strong similarity to the application(s) you care about developing
and are written in a style similar to how you'd (probably) develop those
applications. Otherwise, you may have proven nothing at all, or you may
have proven something that doesn't matter -- but there's no reasonable
way to prove anything about the languages as a whole.

 

[Jon Harrop]

To have any hope of meaning anything, those bodies of code both need to
bear a strong similarity to the application(s) you care about developing
and are written in a style similar to how you'd (probably) develop those
applications. Otherwise, you may have proven nothing at all, or you may
have proven something that doesn't matter -- but there's no reasonable
way to prove anything about the languages as a whole.

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

 

[Victor Bazarov]

To have any hope of meaning anything, those bodies of code both need
to bear a strong similarity to the application(s) you care about
developing and are written in a style similar to how you'd
(probably) develop those applications. Otherwise, you may have
proven nothing at all, or you may have proven something that doesn't
matter -- but there's no reasonable way to prove anything about the
languages as a whole.

Indeed. We benchmarked our [..]

Who cares?

 

[Jon Harrop]

Who cares?

Anyone wanting good performance.

 

[Kai-Uwe Bux]

Victor Bazarov wrote: [about OCaml benchmarks]

Who cares?

Anyone wanting good performance.

I am pretty sure that anybody caring about the performance of OCaml programs
will be thrilled to read about those benchmarks _in a forum where they are
on-topic_. However, since performance is platform and implementation
specific, even the C++ part of your benchmarks is hardly topical here.
Please refer to the FAQ of this news group.


Best

Kai-Uwe Bux

 

[Jon Harrop]

However, since performance is platform and implementation specific,

The results are neither platform nor implementation specific. This is a
general problem of destructors that incremental garbage collections solves.

 

[Zachary Turner]

and is algorithmically faster than the C++ standard library for many common
operations, e.g. 10,000x faster for set_union:

I like how the C++ code uses an inserter in order to achieve the worst
possible performance.

 

[Kai-Uwe Bux]

Kai-Uwe Bux wrote:

[in an argument about topicality of OCaml / C++ comparison benchmarks]

The results are neither platform nor implementation specific.

Are you implying that you have not compiled the C++ program with a
particular compiler (aka implementation) and run it on a particular machine
(aka platform), yet still you have measured its speed?

Note: I am not trying to make fun of you. It just so happens that those are
the meanings of "implementation" and "platform" that define topicality in
this group.

This is a general problem of destructors that incremental garbage
collections solves.

Best

Kai-Uwe Bux

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

The results are neither platform nor implementation specific. This is a
general problem of destructors that incremental garbage collections solves.

Of course they are, at the very least they are not independent from the
specific implementation of the raytracer (in both C++ and OCaml). A
better programmer might implement the same raytracer in a more efficient
way (in both languages). You can never compare the efficiency of two
languages like that, only the efficiencies of implementations of a
problem in different languages.

 

[Jon Harrop]

Kai-Uwe Bux wrote:

[in an argument about topicality of OCaml / C++ comparison benchmarks]

The results are neither platform nor implementation specific.

Are you implying that you have not compiled the C++ program with a
particular compiler (aka implementation) and run it on a particular
machine (aka platform), yet still you have measured its speed?

Note: I am not trying to make fun of you. It just so happens that those
are the meanings of "implementation" and "platform" that define topicality
in this group.

Aymptotic complexity is not platform and implementation dependent.

 

[Jon Harrop]

Of course they are, at the very least they are not independent from the
specific implementation of the raytracer (in both C++ and OCaml). A
better programmer might implement the same raytracer in a more efficient
way (in both languages). You can never compare the efficiency of two
languages like that, only the efficiencies of implementations of a
problem in different languages.

Absolutely. I wasn't talking about the ray tracer though, but two different
implementations of Smoke:

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

The two implementations have different worst-case complexities, which is
quite common for C++ vs OCaml comparisons because C++ tends to use arrays
and avalanche deallocation from destructors whereas OCaml often uses trees
(much more incremental friendly) and has an incremental garbage collector
that distributes deallocations evenly over time.

You can get some of the bad worst case performance (but typically better
average case performance) in OCaml by using hash tables instead of trees.
Doing the converse in C++ (which is required for soft real-time
applications) is very hard though. You basically need to rewrite all of the
memory allocation and deallocation routines yourself, replace the STL
allocators, but even then you cannot perform heap compaction because C++
exposes pointers to the programmer, so your heap becomes fragmented and
you've just moved to another problem.

We spent many years trying to improve the worst case performance of our C++
implementation and we basically failed. When we tried translating the
program into OCaml as a test, we were pleasantly surprised to find that the
worst case performance for typical use was 5x faster, simply as a
side-effect of using a language with a good garbage collector. This is the
result of the OCaml garbage collector (the result of 10+ years of research)
using better algorithms than anything we had managed to implement.

 

[Jon Harrop]

I like how the C++ code uses an inserter in order to achieve the worst
possible performance.

Exactly, yes. C++ must copy all of the data because the data is mutable. If
the data structure was immutable (as the OCaml Set is) then you can refer
back to parts of the original set (because it is referentially
transparent).

You can write efficiently in C++, of course, by performing the algorithmic
optimizations yourself by hand. I did this with my example program and
managed to get the C++ to be as fast as the OCaml, but it was then
unreadable and many times longer.

Another possibility is to implement immutable data structures (a replacement
for the STL set) but this requires garbage collection, so you would also
have to implement a garbage collector by which time you've basically
invented another language.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Kai-Uwe Bux wrote:

[in an argument about topicality of OCaml / C++ comparison benchmarks]

However, since performance is platform and implementation specific,

The results are neither platform nor implementation specific.

Are you implying that you have not compiled the C++ program with a
particular compiler (aka implementation) and run it on a particular
machine (aka platform), yet still you have measured its speed?

Note: I am not trying to make fun of you. It just so happens that those
are the meanings of "implementation" and "platform" that define topicality
in this group.

Aymptotic complexity is not platform and implementation dependent.

True, but we are not talking about asymptotic complexity, we are talking
about the benchmark you were talking about, which must be at least
implementation dependant.

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.