By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,745 Members | 1,957 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,745 IT Pros & Developers. It's quick & easy.

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

P: n/a

Flying Frog just launched the OCaml Journal:

http://www.ffconsultancy.com/product...ion.html?clcpp

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

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 21 '07 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Jon Harrop wrote:
Flying Frog just launched the OCaml Journal:

http://www.ffconsultancy.com/product...ion.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
Jun 21 '07 #2

P: n/a
Zeppe wrote:
Jon Harrop wrote:
>Flying Frog just launched the OCaml Journal:

http://www.ffconsultancy.com/product...ion.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
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
Jun 21 '07 #3

P: n/a
Zeppe wrote:
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. :-)

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 21 '07 #4

P: n/a
On Thu, 21 Jun 2007 22:56:41 +0100, Jon Harrop wrote:
Zeppe wrote:
>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.
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.
>Nobody gives a clue about this so-called OCaml here.

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.

--
Markus Schoder
Jun 21 '07 #5

P: n/a
Markus Schoder wrote:
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....2d6e7ae6?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.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 21 '07 #6

P: n/a
On Jun 21, 8:26 pm, Jon Harrop <j...@ffconsultancy.comwrote:
Markus Schoder wrote:
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/
9% is too slow for any decent realtime application

go sell your fish elsewhere

Jun 25 '07 #7

P: n/a
In article <11**********************@w5g2000hsg.googlegroups. com>,
jo********@gmail.com says...

[ ... ]
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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jun 25 '07 #8

P: n/a
Jerry Coffin wrote:
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/product...ctor_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++.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 26 '07 #9

P: n/a
Jon Harrop wrote:
Jerry Coffin wrote:
>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?
Jun 26 '07 #10

P: n/a
Victor Bazarov wrote:
Who cares?
Anyone wanting good performance.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 26 '07 #11

P: n/a
Jon Harrop wrote:
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
Jun 26 '07 #12

P: n/a
Kai-Uwe Bux wrote:
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.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 26 '07 #13

P: n/a
Jon Harrop wrote:
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.

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

Best

Kai-Uwe Bux
Jun 26 '07 #14

P: n/a
On 2007-06-26 17:43, Jon Harrop wrote:
Kai-Uwe Bux wrote:
>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.
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.

--
Erik Wikström
Jun 26 '07 #15

P: n/a
Kai-Uwe Bux wrote:
Jon Harrop wrote:
>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.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 27 '07 #16

P: n/a
Erik Wikström wrote:
On 2007-06-26 17:43, Jon Harrop wrote:
>Kai-Uwe Bux wrote:
>>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.

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/product...ctor_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.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 27 '07 #17

P: n/a
Jon Harrop a écrit :
Jerry Coffin wrote:
>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/product...ctor_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/languag...omparison.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
Jun 27 '07 #18

P: n/a
Erik Wikström wrote:
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.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 27 '07 #19

P: n/a
Kai-Uwe Bux wrote:
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).

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 27 '07 #20

P: n/a
Michael DOUBEZ wrote:
Does this mean that the following page is obsolete:
http://www.ffconsultancy.com/languag...omparison.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.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal
http://www.ffconsultancy.com/product...ournal/?usenet
Jun 27 '07 #21

P: n/a
Jon Harrop wrote:
Erik Wikström wrote:
>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.
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
Jun 27 '07 #22

P: n/a
On 2007-06-27 05:33, Jon Harrop wrote:
Kai-Uwe Bux wrote:
>Jon Harrop wrote:
>>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.

--
Erik Wikström
Jun 27 '07 #23

This discussion thread is closed

Replies have been disabled for this discussion.