22 2019
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
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
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
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 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
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
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.
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
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?
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 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
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
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
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
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
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
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
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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Simon Kwong |
last post by:
Hi,
I am learning c++ and would like to write a simple C++ compiler. How should
I start?
Please help.
Simon
|
by: Sharad Kala |
last post by:
Hi,
I want to know the behavior of modern C++ compilers for this short program.
Basically this tells us the rate by which vector grows.
#include <vector>
#include <iostream>
using namespace...
|
by: kieran |
last post by:
Hi, does anyone know of any C++ compilers for embedded systems. All
I've found so far is Visual eMbedded C++ that only works on Windows CE
(which I don't want to develop on anyway).
Help much...
|
by: V e X y N |
last post by:
OK, here's the deal, if anyone could help me with a link or two, I'd
be delighted.
I'm just learning C (I learned over the summer, so a few months), and
I was wondering what (*free*) compilers are...
|
by: David M. Wilson |
last post by:
I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to...
|
by: Derek |
last post by:
As I understand it there is a good amount of link compatibility
among C compilers. For example, I can compile main.c with GCC
and func.c with Sun One and link the objects using either linker
(GNU...
|
by: Confused User |
last post by:
I am working on device that utilizes a Motorola 68HC16 microcontroller. I am
using an old unsupported piece of crap Whitesmith's / Intermetrics / Tasking
compiler. The embedded compiler business...
|
by: pseudomagazine |
last post by:
Little problem:
Using the document.write() function and an enormous string, I have managed to create self-generated pages with functions calling code located in external scripts. The code that...
|
by: =?Utf-8?B?RGFtZW9u?= |
last post by:
Hi -
I am attempting to write lines to a file at high volume, multiple threads.
Here is my scenario:
(initial "WriteToFile" object created via a parent multithreaded process,
which receives...
|
by: Hongyu |
last post by:
Dear all:
I am trying to write to a file with full directory name and file name
specified (./outdir/mytestout.txt where . is the current directory)
in
C programming language and under Unix, but...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
| |