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

Discussion in 'C++' started by Jon Harrop, Jun 21, 2007.

  1. Jon Harrop

    Jon Harrop Guest

    Jon Harrop, Jun 21, 2007
    #1
    1. Advertising

  2. Jon Harrop

    Zeppe Guest

    Re: Write your C++ compilers in a modern high-performance functionallanguage

    Jon Harrop wrote:
    > 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
    Zeppe, Jun 21, 2007
    #2
    1. Advertising

  3. Re: Write your C++ compilers in a modern high-performance functionallanguage

    Zeppe wrote:
    > Jon Harrop wrote:
    >> 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


    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
    John Harrison, Jun 21, 2007
    #3
  4. Jon Harrop

    Jon Harrop Guest

    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/products/ocaml_journal/?usenet
    Jon Harrop, Jun 21, 2007
    #4
  5. Re: Write your C++ compilers in a modern high-performancefunctional language

    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
    Markus Schoder, Jun 22, 2007
    #5
  6. Jon Harrop

    Jon Harrop Guest

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

    --
    Dr Jon D Harrop, Flying Frog Consultancy
    The OCaml Journal
    http://www.ffconsultancy.com/products/ocaml_journal/?usenet
    Jon Harrop, Jun 22, 2007
    #6
  7. On Jun 21, 8:26 pm, Jon Harrop <> wrote:
    > 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
    Diego Martins, Jun 25, 2007
    #7
  8. Jon Harrop

    Jerry Coffin Guest

    In article <>,
    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.
    Jerry Coffin, Jun 25, 2007
    #8
  9. Jon Harrop

    Jon Harrop Guest

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

    --
    Dr Jon D Harrop, Flying Frog Consultancy
    The OCaml Journal
    http://www.ffconsultancy.com/products/ocaml_journal/?usenet
    Jon Harrop, Jun 26, 2007
    #9
  10. 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?
    Victor Bazarov, Jun 26, 2007
    #10
  11. Jon Harrop

    Jon Harrop Guest

    Jon Harrop, Jun 26, 2007
    #11
  12. Jon Harrop

    Kai-Uwe Bux Guest

    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
    Kai-Uwe Bux, Jun 26, 2007
    #12
  13. Jon Harrop

    Jon Harrop Guest

    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/products/ocaml_journal/?usenet
    Jon Harrop, Jun 26, 2007
    #13
  14. On Jun 21, 6:26 pm, Jon Harrop <> wrote:
    > 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.
    Zachary Turner, Jun 26, 2007
    #14
  15. Jon Harrop

    Kai-Uwe Bux Guest

    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
    Kai-Uwe Bux, Jun 26, 2007
    #15
  16. Re: Write your C++ compilers in a modern high-performance functionallanguage

    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
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Jun 26, 2007
    #16
  17. Jon Harrop

    Jon Harrop Guest

    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/products/ocaml_journal/?usenet
    Jon Harrop, Jun 27, 2007
    #17
  18. Jon Harrop

    Jon Harrop Guest

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

    --
    Dr Jon D Harrop, Flying Frog Consultancy
    The OCaml Journal
    http://www.ffconsultancy.com/products/ocaml_journal/?usenet
    Jon Harrop, Jun 27, 2007
    #18
  19. Jon Harrop

    Jon Harrop Guest

    Zachary Turner wrote:
    > On Jun 21, 6:26 pm, Jon Harrop <> wrote:
    >> 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.


    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.

    --
    Dr Jon D Harrop, Flying Frog Consultancy
    The OCaml Journal
    http://www.ffconsultancy.com/products/ocaml_journal/?usenet
    Jon Harrop, Jun 27, 2007
    #19
  20. Re: Write your C++ compilers in a modern high-performance functionallanguage

    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
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Jun 27, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David M. Wilson
    Replies:
    8
    Views:
    479
    Ben Pfaff
    Jan 7, 2004
  2. Casey Hawthorne
    Replies:
    4
    Views:
    984
    Jarek Zgoda
    Aug 4, 2006
  3. geletine

    commercial c compilers vs free c compilers

    geletine, Jul 2, 2006, in forum: C Programming
    Replies:
    33
    Views:
    1,299
  4. Jon Harrop
    Replies:
    1
    Views:
    311
    Richard Heathfield
    Jun 21, 2007
  5. Jay Loden
    Replies:
    2
    Views:
    309
    Josiah Carlson
    Jun 24, 2007
Loading...

Share This Page