RE: [Caml-list] about OcamIL
Jon Harrop jonathandeanhar...@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=alllang=scalalan 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. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] recursive module and types
Hello, I needed to define a (large) recursive type using sets basically as in the example below. What I do not like is that I need to repeat the definition of the type twice (in my real code the type is 100 lines long) ... Does anyone see a way to avoid it, apart from using parametric types, which is also done below Cheers, Christophe (* data type of finitely branching trees with sets for leafs ... *) module rec T : sig type t = Node of S.t | Leaf val compare : t - t - int end = struct type t = Node of S.t | Leaf let compare u v = match u, v with Leaf, Leaf - 0 | Node u', Node v' - S.compare u' v' | Leaf, Node _ - -1 | Node _, Leaf - 1 end and S : Set.S with type elt = T.t = Set.Make(T) (* a solution with parametric types pb: the parametric type is not very readable by itself especially when it will be longer *) type 'a pre_t = Node of 'a | Leaf module rec T' : sig type t = S'.t pre_t val compare : t - t - int end = struct type t = S'.t pre_t let compare u v = match u, v with Leaf, Leaf - 0 | Node u', Node v' - S'.compare u' v' | Leaf, Node _ - -1 | Node _, Leaf - 1 end and S' : Set.S with type elt = T'.t = Set.Make(T') (* The same as a functor to allow storing data in the tree *) module DT (D:Set.OrderedType) = struct module rec T : sig type t = Node of D.t * S.t | Leaf val compare : t - t - int end = struct type t = Node of D.t * S.t | Leaf let compare u v = match u, v with Leaf, Leaf - 0 | Node (du,u'), Node (dv,v') - (match D.compare du dv with 0 - S.compare u' v' | c - c) | Leaf, Node _ - -1 | Node _, Leaf - 1 end and S : Set.S with type elt = T.t = Set.Make(T) end -- Christophe Raffalli Universite de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedex tel: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: christophe.raffa...@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI - IMPORTANT: this mail is signed using PGP/MIME At least Enigmail/Mozilla, mutt or evolution can check this signature. The public key is stored on www.keyserver.net - ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] OCaml defunctorization and other optimizations
Hi, I've seen in several places recommendations to use 'ocamldefun' to speed up OCaml programs that use functors heavily [*]. I was able to find the sources via the wayback machine. Unsurprisingly it doesn't build with OCaml 3.11.2 (it wants OCaml 3.06). Is there a more up to date variant of ocamldefun? Would it be possible to port it to 3.11.2? Is it possible to implement ocamldefun-like functionality via Camlp4's AST filters? Also is it possible to implement function specialization (monomorphization?) using an AST filter? The example from the OCaml tutorial is not optimized by http://www.ocaml-tutorial.org/performance_and_profiling. Or is it possible to get access to the OCaml compiler's IL representation and make optimizations on that? [*] For example when extracting ML programs from Coq using OCaml's native 'int' type I get code like this (which is not inlined/optimized at all by OCaml): module Z_as_Int = struct let _2 = 2 let mult = ( * ) ... end module F = functor (I:Int) - struct (** val mul2 : I.int - I.int **) let mul2 n = I.mult I._2 n end module F2 = F(Z_as_Int) Best regards, --Edwin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: about OcamIL
On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand mich...@elehack.net wrote: Yes, Python's hash tables are particularly optimized due to their wide pervasive usage. When you're testing Python hash tables, you're really testing a carefully-written, thoroughly-tuned C implementation of hash tables. The most amusing benchmarks are those with Java bytecode working on integer/float arrays. That is one place where Java has some admissible performance (comparable to ocaml bytecode?), but when you go to an algorithm that is more expensive than O(n) in time and makes more than O(n) dynamic memory allocations you will see how miserably Java fails. I unfortunately haven''t prepared any benchmarks for those, the info-retrieval, data mining and 3d-engine codes I had written in Java, well it would have been 10x-20x better if I had written them in C++ and a benchmark would be possible, but if anyone is interested I can surely post one of those codes, a clustering algorithm for Weka for instance. I suspect that the performance hit is a feature of JVM design, in addition to the Java language design. On the other hand, Jon's notion of high performance is valid I think. You want to be as close to the metal as possible. Otherwise there is no point in, say, writing a parallel version of the code. In the past we thought that was only possible with C and Fortran. Nowadays we think of C++ when we say that but I gladly find that ocaml is on par with any of those for real world tasks, without requiring tedious and cumbersome optimizations just to get it running (like in Java). That being said, I think getting anything to run on JVM is a remarkable achievement! It would have been so cool to be able to run ocaml code inside a web browser. :) There are unfortunately few alternatives for running code inside a browser. Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] Re: about OcamIL
Eray Ozkural wrote: On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand mich...@elehack.net wrote: Yes, Python's hash tables are particularly optimized due to their wide pervasive usage. When you're testing Python hash tables, you're really testing a carefully-written, thoroughly-tuned C implementation of hash tables. snip That being said, I think getting anything to run on JVM is a remarkable achievement! It would have been so cool to be able to run ocaml code inside a web browser. :) There are unfortunately few alternatives for running code inside a browser. There are two pretty viable alternatives for running OCaml code in a web browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2] which is a JavaScript implementation of the OCaml bytecode interpreter (or VM, as it's been called in this thread). David [1] http://code.google.com/p/ocamljs [2] http://www.pps.jussieu.fr/~canou/obrowser/tutorial ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: about OcamIL
On Wed, May 19, 2010 at 6:35 AM, David Allsopp dra-n...@metastack.comwrote: There are two pretty viable alternatives for running OCaml code in a web browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2] which is a JavaScript implementation of the OCaml bytecode interpreter (or VM, as it's been called in this thread). There's also nacl-ocaml [1] that uses google's native client to directly execute native ocaml. [1]: http://code.google.com/p/nacl-ocaml ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: about OcamIL
Eray Ozkural examach...@gmail.com writes: On the other hand, Jon's notion of high performance is valid I think. You want to be as close to the metal as possible. Otherwise there is no point in, say, writing a parallel version of the code. In the past we thought that was only possible with C and Fortran. Nowadays we think of C++ when we say that but I gladly find that ocaml is on par with any of those for real world tasks, without requiring tedious and cumbersome optimizations just to get it running (like in Java). The thing about ocaml is that it does not optimize. You get what you tell it to do. You put garbage in you get garbage out. You improve your algorithm you get a huge speedup. You don't get sudden and unexpected side effects that magically double your speed when you add a useless line of code somewhere because suddenly the compiler sees an optimization. Ocaml also finds a lot more bugs due to its stronger types and has much nicer lookfeel for many problems imho. So you get your code written faster, looking better, working right and still have fun. If I finished writing a program (in basically any language) and find it runs too slow I have two avenues to optimize it: 1) Think of some algortihm that is more clever. That can easily improve performance by magnitudes. 2) Locate the part that sucks up all the time for no work being done and write some C/asm stubs that are specifically optimized. Except for extrem cases this tends to give little improvement. But that might be just me. MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: about OcamIL
David Allsopp dra-n...@metastack.com writes: Eray Ozkural wrote: On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand mich...@elehack.net wrote: Yes, Python's hash tables are particularly optimized due to their wide pervasive usage. When you're testing Python hash tables, you're really testing a carefully-written, thoroughly-tuned C implementation of hash tables. snip That being said, I think getting anything to run on JVM is a remarkable achievement! It would have been so cool to be able to run ocaml code inside a web browser. :) There are unfortunately few alternatives for running code inside a browser. There are two pretty viable alternatives for running OCaml code in a web browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2] which is a JavaScript implementation of the OCaml bytecode interpreter (or VM, as it's been called in this thread). David [1] http://code.google.com/p/ocamljs [2] http://www.pps.jussieu.fr/~canou/obrowser/tutorial Or NaCl I think it wascalled. Someone mentioned that some time ago here. MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] recursive module and types
On 05/19/2010 02:24 PM, Christophe Raffalli wrote: Does anyone see a way to avoid it I propose: module rec T : sig type t = U.t val compare : t - t - int end = struct include U let compare u v = match u, v with Leaf, Leaf - 0 | Node u', Node v' - S.compare u' v' | Leaf, Node _ - -1 | Node _, Leaf - 1 end and S : Set.S with type elt = T.t = Set.Make(T) and U : sig type t = Node of S.t | Leaf end = U The type definition is given only once. -- Alain ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] about OcamIL
Xavier Clerc wrote: Jon Harrop jonathandeanhar...@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. I greatly value efficient generic collections. 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. Sure but those two benchmarks are testing completely different things. The shootout's knucleotide is a larger benchmark that still uses hash tables and Java is still 4x slower because the JVM cannot express a generic hash table efficiently. There are many such problems where the lack of value types on the JVM is a serious impediment to performance. 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). I'm not sure what you mean here. Both of the programs are just using the generic hash table implementation native to their platform. Neither language does anything of relevance to optimize the code. .NET is a lot faster and uses a lot less memory than the JVM because it stores keys and values unboxed in the spine of the hash table because they are value types whereas the JVM boxes them, and because the insertion function is monomorphized at JIT time. Scala on the JVM is 7x slower than C++ on this benchmark: http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=scal alan 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. Sure. This seems to be a difference in our interpretation of high performance. If a language or platform can be 17x slower than others then I would not call it high performance even if it is competitively performant elsewhere. Indeed, I would completely disregard averages on benchmark suites and focus on outliers because they convey more useful information. Granted that was a microbenchmark but the effect is severe enough to afflict many real programs. 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. Then you're probably more interested in OCaml's GC vs parallelism when performance is important. 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). I agree in general, of course, but I'm not sure higher-level languages means much in this context. Is C# higher level than Java? Maybe, but I'm interested in the value types and approach to generics here. Monomorphization and unboxed tuples get you a long way towards decent performance without a top-notch GC tuned for functional languages. That makes it feasible to implement with a naïve multicore-capable GC, which is precisely the current direction of HLVM. PS: as an aside, I used the word references for academic publications that went through a reviewing process, not blog entries. I see. I value reproducible results far higher than peer reviewed academic papers, particularly in this context. Cheers, Jon. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Problem with recursive class and non-class types
Hi,
I want to define the two types below:
type foo = { bar : bar; }
class bar = object val mutable foo : foo list = [] end
Is there another way of doing this other than:
# type 'a foo = { bar : 'a; }
class bar = object val mutable foo : #bar foo list = [] end;;
type 'a foo = { bar : 'a; }
class bar : object val mutable foo : #bar foo list end
I don't want any 'a foo other than 'a = #bar. It is too easy to create a
baz foo and then much later get a type error when trying to use it as
bar foo. I want the error where the foo gets created.
MfG
Goswin
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
