Version française
Home     About     Download     Resources     Contact us    
Browse thread
about OcamIL
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: forum@x...
Subject: RE: [Caml-list] about OcamIL
Jon Harrop <jonathandeanharrop@googlemail.com> a écrit :

(...)

> I don't think this is heated at all. We were talking about "high
> performance" languages and you cited a bunch of languages that get whipped
> by Python on this benchmark:
>
>
> http://flyingfrogblog.blogspot.com/2009/04/f-vs-ocaml-vs-haskell-hash-table.
> html

Acknowledged.
"Whipped" is here 2 times slower on that particular benchmark,
while Python is rarely within an order of magnitude of OCaml code
(cf. the language shootout).
Moreover, hashtables are ubiquitous in Python (and hence probably
particularly optimized), while they are not so common in Haskell
or Caml.


>> And I still wait for a clear statement of your level for "high
>> performance",
>
> Within 2x of ANSI C compiled with gcc on all practically-relevant benchmarks
> without dropping to low-level code, e.g. GHC's FFI in Haskell.
>
>> and references to benchmarks that back up your claims in this thread.
>
>   http://fsharpnews.blogspot.com/2010/05/java-vs-f.html

Point taken.
Just notice that the 17x factor is observed on the micro-benchmark,
while on the larger one the two platforms seem on par.

Here is a question about the micro-benchmark: do you know if F# do
monomorphize the collection in this example ?
If it turns out to be done, one may probably argue that the problem
is more related to the language than to the platform (just recycling
an objection made on the page you pointed out).


>> As you seem to come from an academic background, I expect facts
>> and references, and not ad hominem attacks and fuzzy unbacked claims.
>
> An ad-hominem attack is an attack against a person. I attacked your
> examples, not you.

I do not understand how "name droping is more than silly" could be seen
as targeted at the sentence rather than at the one pronouncing it.
But, anyway, let's move to the point.


>> Unless you show that neither Bigloo nor Scala meet your (to be defined)
>> criteria for "high performance", my counterexamples still stand.
>
> Are you talking about Bigloo.NET and Scala.NET or have you gone back to the
> original discussion about JVM-based languages?
>
> Scala on the JVM is 7x slower than C++ on this benchmark:
>
>
> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scala&lan
> g2=gpp

Agreed, but it seems that if you aggregate the results of the different
benchmarks, Scala is on average only 1.5x from C++ (but far away in terms
of memory consumption). The 7x factor is observed the worst result,
the median being 2x.


(...)

>> It may just end up that we have different perceptions of "high
>> performance", and of the trade-offs we are going to make in our
>> language / platform choices.
>
> Probably. What languages do not you not consider to be high performance?

I am not sure it is that easy to compare languages, but measuring compiler
performances: any compiler that produces code that runs within -let's say- 5x
of the fastest one around, on a bunch of wide-spectrum benchmarks (e. g.
numerical code *plus* string matching *plus* tree walking, etc).
Maybe it should also be mentioned that I am more versed into symbolic  
computations.

Regarding trade-offs, I am also inclined to favor Open Source solutions and
higher-level languages (the trade-off being here execution time vs
programming/debugging time).


Xavier Clerc

PS: as an aside, I used the word "references" for academic publications that
went through a reviewing process, not blog entries.