[Caml-list] OCaml + mingw-w64
Hi, atm we compile out large ocaml application (Astree, http://www.astree.ens.fr/) with ocaml + MSVC64. I would like to go away from MSVC to mingw, to e.g. have gdb available and more unix like environment. Atm it seems only the normal mingw (32bit) is supported. I found some problem with using the 64bit version with flexlinker, which I reported to Alain Frisch to get that sorted out. Aside from that, I think a problem might be, that there is no matching assembler for amd64 + mingw (windows calling convention). Is that correct and could somebody help me out with this? I think, given that gcc on unices with 64bit work fine here, it shouldn't be too much effort to get mingw-w64 working too, enabling to have a nice (and fast for the bytecode interpreter) variant of ocaml for win64 using mostly open source components ;) Other feedback (which is valid for MSVC64, too): In ocaml 3.12, in byterun/major_gc.h, there is: intnat caml_major_collection_slice (long howmuch) whereas in the .c file that is: intnat caml_major_collection_slice (intnat howmuch) As intnat is with mingw-w64 long long, this doesn't match. Should not the header use intnat, too? Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ 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] Is OCaml fast?
I apologize beforehand if this is not the forum to ask. I am on the fence about whether to learn OCaml or not, and while reading an article called Why OCaml (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw that OCaml was praised for the speed of the executables it generates - and was referred to, speed-wise, as second to none, except C and C++. However, when I actually went to the Language Shootout page suggested in the article, I found out that OCaml is not 2nd, it is 13th, behind languages like Haskell and C#... (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php) Is it just hype, then? Or am I missing something? -- What I gave, I have; what I spent, I had; what I kept, I lost. (Old Epitaph) ___ 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] Is OCaml fast?
If you want speed then you should learn assembly or choose C as a second choice. It depends on the kind of apps you'd like to write. Even though O'Caml is fast, it's not the first criteria I have in mind which would be security : no segfault, no need to handle horrible stuff like in C, ... 2010/11/22 Thanassis Tsiodras ttsiod...@gmail.com I apologize beforehand if this is not the forum to ask. I am on the fence about whether to learn OCaml or not, and while reading an article called Why OCaml (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.htmlhttp://www.cs.ubc.ca/%7Emurphyk/Software/Ocaml/why_ocaml.html), I saw that OCaml was praised for the speed of the executables it generates - and was referred to, speed-wise, as second to none, except C and C++. However, when I actually went to the Language Shootout page suggested in the article, I found out that OCaml is not 2nd, it is 13th, behind languages like Haskell and C#... ( http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php ) Is it just hype, then? Or am I missing something? -- What I gave, I have; what I spent, I had; what I kept, I lost. (Old Epitaph) ___ 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 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] Is OCaml fast?
On Mon, Nov 22, 2010 at 2:35 PM, Gregory Bellier gregory.bell...@gmail.com wrote: If you want speed then you should learn assembly or choose C as a second choice. It depends on the kind of apps you'd like to write. Even though O'Caml is fast, it's not the first criteria I have in mind which would be security : no segfault, no need to handle horrible stuff like in C, ... No! You should use ATS, just as the shootout suggests. (Portable) assembly is not a language for humans ;-) ___ 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] Is OCaml fast?
Gregory Bellier wrote: If you want speed then you should learn assembly or choose C as a second choice. Certainly not assembly. Modern microprocessors just see assembly as a kind-of high level language which they interpret in a funny way, doing all sorts of re-schedulings, register renamings, delayed branching, speculative execution etc. Producing code that can take advantage of this is best left to the compiler - unless one has to deal with instruction set extensions for which there is no good compiler support yet. It depends on the kind of apps you'd like to write. Even though O'Caml is fast, it's not the first criteria I have in mind which would be security : no segfault, no need to handle horrible stuff like in C, ... I'd say the OCaml native compiler is reasonably fast for pretty much all applications that need the speed of compiled code. But I'd say the same for GHC and SBCL, say. There are some good reasons to take a closer look at OCaml, but these are related to other qualities of the language. In my view, its greatest benefit is that it makes working with closures simple while being fast and by far not as intimidating to (prospective) PhD students as Scheme/Lisp (but that only because most of them have been spoilt by imperative languages beforehand). -- best regards, Thomas Fischbacher t.fischbac...@soton.ac.uk ___ 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] Re: Is OCaml fast?
Hello, On 22-11-2010, Thanassis Tsiodras ttsiod...@gmail.com wrote: I apologize beforehand if this is not the forum to ask. I am on the fence about whether to learn OCaml or not, and while reading an article called Why OCaml (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw that OCaml was praised for the speed of the executables it generates - and was referred to, speed-wise, as second to none, except C and C++. However, when I actually went to the Language Shootout page suggested in the article, I found out that OCaml is not 2nd, it is 13th, behind languages like Haskell and C#... (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php) Shootout benchmarks doesn't always allow to set some variables that could greatly improve the speed of OCaml. Is it just hype, then? Or am I missing something? You could write very fast application with OCaml -- even beating C code in some case. But what OCaml is really helpful for, is that you can do algorithmic optimizations that improve the speed. It means that OCaml is terse enough to allow you to write complex algorithm without making too much bugs. All in all: development time + execution time is fast. But if you spend 10x development time on the same C code, you will obviously get something faster in C. Regards, Sylvain Le Gall ___ 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] Is OCaml fast?
Am Montag, den 22.11.2010, 15:21 +0200 schrieb Thanassis Tsiodras: I apologize beforehand if this is not the forum to ask. I am on the fence about whether to learn OCaml or not, and while reading an article called Why OCaml (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw that OCaml was praised for the speed of the executables it generates - and was referred to, speed-wise, as second to none, except C and C++. However, when I actually went to the Language Shootout page suggested in the article, I found out that OCaml is not 2nd, it is 13th, behind languages like Haskell and C#... (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php) Is it just hype, then? Or am I missing something? I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? Gerd -- Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany g...@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ___ 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] [was: Re: Is OCaml fast?] OCaml Shootout task force
On 22-11-2010, Gerd Stolpmann i...@gerd-stolpmann.de wrote: Am Montag, den 22.11.2010, 15:21 +0200 schrieb Thanassis Tsiodras: I apologize beforehand if this is not the forum to ask. I am on the fence about whether to learn OCaml or not, and while reading an article called Why OCaml (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw that OCaml was praised for the speed of the executables it generates - and was referred to, speed-wise, as second to none, except C and C++. However, when I actually went to the Language Shootout page suggested in the article, I found out that OCaml is not 2nd, it is 13th, behind languages like Haskell and C#... (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php) Is it just hype, then? Or am I missing something? I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? Maybe it is time to join forces and update the shootout for OCaml? If some people are interested here, I can setup a repository on the forge to update all this tests. If I get 2 people interested, I will setup a VCS repository + project on the forge, this afternoon. Drop me an email + preferred VCS (among svn, git, darcs) and your account login on http://forge.ocamlcore.org. I will take care, when ready, to made this code available in the shootout once finished. Regards, Sylvain Le Gall ___ 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] Is OCaml fast?
On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann i...@gerd-stolpmann.dewrote: I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? As Sylvain noticed, some (in not most) of the OCaml poor performances in the shootout are actually not due to bad OCaml programs, but to arbitrary restrictions in the shootout rules. For example, one of the bad-performing benchmark for OCaml is the binary-tree benchmark, where it is nearly four times slower than C, but on closer inspection you discover that this is due to the arbitrary choice to forbid any change of the GC parameters. With appropriate GC parameters, the very same OCaml program is exactly as fast as C. http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees « Note: these programs are being measured with *the default initial heap size* - the measurements may be very different with a larger initial heap size or GC tuning. » C version : 12.11 secs OCaml version : 47.22 secs OCaml version with GC parameters tuned (interesting alternative section) : 12.67 secs Therefore, there is nothing that can be changed to the OCaml submission for this benchmark to improve performances, except changing the default GC parameters; while this might be a good idea in general, changing it only for the sake of shootout-obsessed people is ridiculous. ___ 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] Is OCaml fast?
On Mon, 22 Nov 2010 15:36:30 +0100 bluestorm bluestorm.d...@gmail.com wrote: On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann i...@gerd-stolpmann.dewrote: I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? As Sylvain noticed, some (in not most) of the OCaml poor performances in the shootout are actually not due to bad OCaml programs, but to arbitrary restrictions in the shootout rules. For example, one of the bad-performing benchmark for OCaml is the binary-tree benchmark, where it is nearly four times slower than C, but on closer inspection you discover that this is due to the arbitrary choice to forbid any change of the GC parameters. With appropriate GC parameters, the very same OCaml program is exactly as fast as C. http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees « Note: these programs are being measured with *the default initial heap size* - the measurements may be very different with a larger initial heap size or GC tuning. » C version : 12.11 secs OCaml version : 47.22 secs OCaml version with GC parameters tuned (interesting alternative section) : 12.67 secs Therefore, there is nothing that can be changed to the OCaml submission for this benchmark to improve performances, except changing the default GC parameters; while this might be a good idea in general, changing it only for the sake of shootout-obsessed people is ridiculous. Isn't it possible for the GC to realise its doing too many collections and increase the minor heap size on its own? Or isn't it possible to determine at compile time an approximation for a good heap size, and use that? 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] Is OCaml fast?
Am Montag, den 22.11.2010, 15:36 +0100 schrieb bluestorm: On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann i...@gerd-stolpmann.de wrote: I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? As Sylvain noticed, some (in not most) of the OCaml poor performances in the shootout are actually not due to bad OCaml programs, but to arbitrary restrictions in the shootout rules. For example, one of the bad-performing benchmark for OCaml is the binary-tree benchmark, where it is nearly four times slower than C, but on closer inspection you discover that this is due to the arbitrary choice to forbid any change of the GC parameters. With appropriate GC parameters, the very same OCaml program is exactly as fast as C. http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees « Note: these programs are being measured with the default initial heap size - the measurements may be very different with a larger initial heap size or GC tuning. » C version : 12.11 secs OCaml version : 47.22 secs OCaml version with GC parameters tuned (interesting alternative section) : 12.67 secs Therefore, there is nothing that can be changed to the OCaml submission for this benchmark to improve performances, except changing the default GC parameters; while this might be a good idea in general, changing it only for the sake of shootout-obsessed people is ridiculous. It's in deed an unfair comparison: In C they use the Apache runtime which provides memory pools. This is something that does not extend to most real world programs. Because it's ridiculous anyway: Encode the tree in an array. Not really idiomatic, but in C they also do not use the idiomatic memory management (malloc/free). Gerd -- Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany g...@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ___ 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] Optimizing garbage collection
On 2010-11-21, at 20:26, Eray Ozkural wrote: I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think? Sounds like an interesting idea, but what heuristic would you use? When everything is smooth, the running time decreases something like exponentially with the minor heap size, so you'd always want to increase the size. How do you tell when to stop? And then, if the program is not behaving uniformly, when do you decide to reduce the size? -- Damien ___ 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] OCaml + mingw-w64
On 2010-11-22, at 13:04, Christoph Cullmann wrote: In ocaml 3.12, in byterun/major_gc.h, there is: intnat caml_major_collection_slice (long howmuch) whereas in the .c file that is: intnat caml_major_collection_slice (intnat howmuch) As intnat is with mingw-w64 long long, this doesn't match. Should not the header use intnat, too? You're right. This will be fixed in 3.12.1. -- Damien ___ 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] Is OCaml fast?
Török Edwin edwinto...@gmail.com writes: On Mon, 22 Nov 2010 15:36:30 +0100 bluestorm bluestorm.d...@gmail.com wrote: On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann i...@gerd-stolpmann.dewrote: I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? As Sylvain noticed, some (in not most) of the OCaml poor performances in the shootout are actually not due to bad OCaml programs, but to arbitrary restrictions in the shootout rules. For example, one of the bad-performing benchmark for OCaml is the binary-tree benchmark, where it is nearly four times slower than C, but on closer inspection you discover that this is due to the arbitrary choice to forbid any change of the GC parameters. With appropriate GC parameters, the very same OCaml program is exactly as fast as C. http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees « Note: these programs are being measured with *the default initial heap size* - the measurements may be very different with a larger initial heap size or GC tuning. » C version : 12.11 secs OCaml version : 47.22 secs OCaml version with GC parameters tuned (interesting alternative section) : 12.67 secs Therefore, there is nothing that can be changed to the OCaml submission for this benchmark to improve performances, except changing the default GC parameters; while this might be a good idea in general, changing it only for the sake of shootout-obsessed people is ridiculous. Isn't it possible for the GC to realise its doing too many collections and increase the minor heap size on its own? Maybe. The GC would have to see that with a larger minor heap it has sufficient space so that most values die before the collection. It could see that most values die after 1 major sweep and increasing the minor heap would likely keep them out of the major heap alltogether. Or isn't it possible to determine at compile time an approximation for a good heap size, and use that? Usualy that is dependent on the input. 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] Optimizing garbage collection
On Mon, Nov 22, 2010 at 04:10:49PM +0100, Damien Doligez wrote: On 2010-11-21, at 20:26, Eray Ozkural wrote: I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think? Sounds like an interesting idea, but what heuristic would you use? When everything is smooth, the running time decreases something like exponentially with the minor heap size, so you'd always want to increase the size. How do you tell when to stop? And then, if the program is not behaving uniformly, when do you decide to reduce the size? Just dropping an idea, not sure it's worth a dime... How about an exponential growth scheme with hysteresis? On each minor collection, multiply the size by a if the rate of promoted words exceeds r1, divide by b if the rate is below r2 (r1 r2); otherwise remain stable. In order to account for the effect of the cache hierarchy, r1 and r2 could also be a function of the current heap size (e.g., with r1 and r2 being higher when approaching magic numbers such as the size of the L2 cache on the left and right side respectively). It'd also be very nice to be able to estimate the amount of time spent on minor + major GC collection vs. the mutator. -- Mauricio Fernandez - http://eigenclass.org ___ 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] Is OCaml fast?
On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann i...@gerd-stolpmann.de wrote: So maybe a good opportunity to post better Ocaml solutions there? I spent some time improving OCaml solutions, and most of the time, my solutions were refused: the organizers don't let you unroll loops, fix GC parameters, etc. One strength of OCaml is that it runs fairly fast immediatly, but you can make it run even faster with some tuning, something that you cannot do with many other languages. Such tuning is not allowed there, so, it is not a good place for OCaml hackers. If the organizers had been consistent, they would have forbidden Haskell programmers from adding strictness in their programs, but then, there programs would have been 2x slower than OCaml programs. Well, actually, things might improve in the future, if we manage to improve the performance of the compiler itself, and have more official libraries. For example, most parallel solutions in OCaml currently use fork() and sockets for communication. Using an official shared-memory library, we could directly improve the performances of many OCaml solutions. --Fabrice ___ 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] Re: Optimizing garbage collection
On 22-11-2010, Damien Doligez damien.doli...@inria.fr wrote: On 2010-11-21, at 20:26, Eray Ozkural wrote: I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think? Sounds like an interesting idea, but what heuristic would you use? When everything is smooth, the running time decreases something like exponentially with the minor heap size, so you'd always want to increase the size. How do you tell when to stop? And then, if the program is not behaving uniformly, when do you decide to reduce the size? How do you tell when to stop? - Maybe you can stop when you reach (the size of the L2/L3 cache of the processor) / number of core. Both information are quite straight to read from /proc/cpuinfo. Regards, Sylvain Le Gall ___ 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] Is OCaml fast?
2010/11/22 Török Edwin edwinto...@gmail.com: Isn't it possible for the GC to realise its doing too many collections and increase the minor heap size on its own? Indeed, it could notice that a lot of data is being moved to the major heap, and double its size in consequence, until a maximum limit is reached. The problem is that it is the kind of things that are application dependent, and should be put in the program itself (the program would have a trigger on each minor heap collection, and, depending on the moved bytes, would increase the size of the minor heap). The problem is that the Shootout does not allow that, so the winner is the language whose runtime allocates the most memory at the beginnning... --Fabrice ___ 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] Is OCaml fast?
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de: [...] (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? [...] Yes I also remember that. I hope that the new OCaml compilers did not make OCaml lessperformance by enhancing other features. And I don't realy think so. But were the old code-snippets emoved, or what was going on, that OCaml degraded that much? From my experience - normally using ocamlc for most of my OCaml programs - it's even fast enough with this bytecode. If it will be not fast enough, I have an option as a joker: compiling to native code. :) Doing this is rather psychologically, as I like to have a potential for enhancement. :) If you really always need the best performance, of course compiling to native code will be best choice. But at lest for my work I have not found out really bottlenecks, and always was faster than doing things in Perl or Python or so. Learning OCaml IMHO does make sense in any case. :) But be aware one big disadvantage: if you have learned Ocaml, this may absolutely kill your motivation in learning other languages afterwards.So,if you need some other languages for your job, learn them first, and learn OCaml after this, for your pleasure. But you may never have fun at work then, until your boss allows you to use OCaml. And this is not a joke, I mean it as I wrote it! Ciao, Oliver ___ 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] Is OCaml fast?
I can confirm that old code-snippets were removed (and that both faster solutions and environment variable tweaks were rejected). On Nov 22, 2010, at 6:02 PM, Oliver Bandel wrote: Zitat von Gerd Stolpmann i...@gerd-stolpmann.de: [...] (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? [...] Yes I also remember that. I hope that the new OCaml compilers did not make OCaml lessperformance by enhancing other features. And I don't realy think so. But were the old code-snippets emoved, or what was going on, that OCaml degraded that much? ___ 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] Is OCaml fast?
answer to the original poster: ocaml is surprisingly fast for such a high level language, i like this insight/comparison: http://youinfinitesnake.blogspot.com/2010/09/programming-language-wars-movie.html (even if the benchmarks can be improved reading others posts of this thread) ___ 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] Is OCaml fast?
...hmhhh.. ...looks like they are biased... not that we are not ;) ...but... as the GC-stuff is available FROM WITHING the language, in the standard-lib, this is nothing added on later. And I think it should also be allowed to be used. To reject environment variables, I can see as acceptable in this case, but rejecting the GC-stuff does not make sense, because, as just mentioned, it is avalable by the programmer from within the code. What about compiling parameters? I mean: in C you can use -O for optimization. This should also be forbidden then Is it? There are so much possibilities to influence the results, that blocking Gc-module is idiotic, IMHO. Ciao, Oliver P.S.: I looked at one of the C-makefiles: usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -march=native -fopenmp -D_FILE_OFFSET_BITS=64 -I/usr/include/apr-1.0 -lapr-1 -lgomp binarytrees.gcc-7.c -o binarytrees.gcc-7.gcc_run rm binarytrees.gcc-7.c So, -O3 is allowed. AFAIK with O3 and higher, inline does work. __inline__ must be forbidden as well as -O3 Optimization should be switched off completely, if OCaml's optimizations are also not allowed. Zitat von David Rajchenbach-Teller david.tel...@univ-orleans.fr: I can confirm that old code-snippets were removed (and that both faster solutions and environment variable tweaks were rejected). On Nov 22, 2010, at 6:02 PM, Oliver Bandel wrote: Zitat von Gerd Stolpmann i...@gerd-stolpmann.de: [...] (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? [...] Yes I also remember that. I hope that the new OCaml compilers did not make OCaml lessperformance by enhancing other features. And I don't realy think so. But were the old code-snippets emoved, or what was going on, that OCaml degraded that much? ___ 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] Is OCaml fast?
Note: I'm not saying that they are biased. It's quite possible they did the same thing for other languages, too, I didn't take the time to check. On Nov 22, 2010, at 6:23 PM, Oliver Bandel wrote: ...hmhhh.. ...looks like they are biased... not that we are not ;) ___ 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: Optimizing garbage collection
On Mon, Nov 22, 2010 at 6:42 PM, Sylvain Le Gall sylv...@le-gall.netwrote: On 22-11-2010, Damien Doligez damien.doli...@inria.fr wrote: On 2010-11-21, at 20:26, Eray Ozkural wrote: I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think? Sounds like an interesting idea, but what heuristic would you use? When everything is smooth, the running time decreases something like exponentially with the minor heap size, so you'd always want to increase the size. How do you tell when to stop? And then, if the program is not behaving uniformly, when do you decide to reduce the size? How do you tell when to stop? - Maybe you can stop when you reach (the size of the L2/L3 cache of the processor) / number of core. Both information are quite straight to read from /proc/cpuinfo. Yeah that's what I had in mind, determine a kind of sensible upper bound to grow to. Cache size makes some sense, though I think as recently mentioned working set size is relevant. If the garbage collector could deduce that it could be used, the other suggestion is also sensible. You could also set it to something like 1/4 of physical RAM. That kind of logic is used in some out-of-core data mining algorithms. The objective here is to amortize the cost of copying until the working set size is reached, otherwise there will be disk thrashing anyway! 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] Is OCaml fast?
Hi, Zitat von Thanassis Tsiodras ttsiod...@gmail.com: I apologize beforehand if this is not the forum to ask. I am on the fence about whether to learn OCaml or not, and while reading an article called Why OCaml (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw that OCaml was praised for the speed of the executables it generates - and was referred to, speed-wise, as second to none, except C and C++. [...] I remember one argument on that topic, many years ago, maybe rom Xavier leoy or other core developers, and it goes like that: Benchmarks on such small problem solving is ONE comparision, what makes sense, but it must be added by comparisions of optimizations of the code in large applications. The lower the level of the öanguage the harder it is to keep track of possible optimizations on a very big program. But the higher the language level is, the easier it is to keep that in mind. So: when optmizing small snippets of code this helps optimizing performance in maybe critical sections, but to get an overview on all interdependencies is close to unmanagable with lower leveled languages. I have not seen a comparison of performance in this repect, but I also would think higher level languages might be a better choice here. Any comparisions on that scale of programming, which you know of? Then please throw in a link here. Thanks. Ciao, Oliver ___ 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] Is OCaml fast?
On Mon, 22 Nov 2010 17:46:49 +0100 Fabrice Le Fessant fabr...@lefessant.net wrote: 2010/11/22 Török Edwin edwinto...@gmail.com: Isn't it possible for the GC to realise its doing too many collections and increase the minor heap size on its own? Indeed, it could notice that a lot of data is being moved to the major heap, and double its size in consequence, until a maximum limit is reached. I did some benchmarks on 2 CPUs, and here are the wall clock times for GC minor heap size: minorheap, phenomII,,, core2,,,cycle diff % , time,, cycles,time,, cycles, 32, 17.76,17.74,56.8, 48.60,48.86,58.48,2.96 64, 16.81,16.80,53.78,44.79,44.79,53.75,-0.06 128, 15.41,15.38,49.26,41.38,40.76,49.28,0.04 256, 14.39,14.35,45.98,39.75,38.98,47.24,2.74 512, 12.97,13.15,41.79,35.75,35.59,42.8,2.42 1024, 12.89,12.94,41.33,33.57,33.13,40.02,-3.17 2048, 11.05,11.09,35.42,29.26,29.12,35.03,-1.1 4096, 9.79, 9.81,31.36,26.21,25.96,31.3,-0.19 8192, 8.71, 8.85,28.1, 23.36,23.34,28.02,-0.28 16384,7.89, 7.86,25.2, 21.41,21.54,25.77,2.26 32768,7.55, 7.55,24.16,20.74,20.88,24.97,3.35 (minorheap is in KWords, time is in seconds, cycles is divided by 10^9) Increasing minor heap beyond that yielded no improvement (number of minor heap collections stayed the same). phenomII has 64 Kb L1 data cache, 512Kb L2 cache, 6144Kb L3 cache (shared), runs at 3.2Ghz. That would be 516k words if only 1 core used. core2 has 32 Kb L1 data cache, 4MB L2 cache, runs at 1.2Ghz. That would be 840k words if only 1 core used. Both used exact same binaries on 64-bit Linux, ocaml 3.11.2. Despite the difference in CPUs and heap sizes the number of CPU cycles spent for a given size of the minor heap is about the same (within 3% difference). Not sure what the max should be for the minor heap increase, but based on this benchmark increasing size of minor heap never slows down the program. Even when size of minor heap exceeds what fits in the cache. I guess there is another microbenchmark that can show the opposite though. Is there some real world benchmark for OCaml's GC that can be used to get some better values for minor heap size based on CPU's L2/L3 size (as suggested in the 'Optimizing garbage collection' thread)? The problem is that it is the kind of things that are application dependent, Yes, maybe optimal size of minor heap doesn't depend on CPU's cache size but on the application, in which case a heuristic for increasing/decreasing the heap size may be better? and should be put in the program itself (the program would have a trigger on each minor heap collection, and, depending on the moved bytes, would increase the size of the minor heap). The problem is that the Shootout does not allow that, so the winner is the language whose runtime allocates the most memory at the beginnning... If tuning minor heap can double performance of the program, then the GC should have some heuristics to tune it automatically. Sure applications which are not happy with that tuning should tune it themselves. 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] Optimizing garbage collection
When everything is smooth, the running time decreases something like exponentially with the minor heap size, so you'd always want to increase the size. How do you tell when to stop? And then, if the program is not behaving uniformly, when do you decide to reduce the size? I don't understand smooth. Minor heap size should be based on the rate of garbage generation relative to allocation to balance cache misses with GC cost. The ratio may be small or large independent of whether it varies during the program. The default minor heap size is well tuned for traditional functional programming behavior: high rate of allocation, short lifetime. When memory access is smaller than a cache line the cache does not reward data reuse so much as address reuse. Collecting a small minor heap that is mostly garbage allows the allocator to start over at an address that is already in cache. Continuing to allocate instead of collecting leads to write-allocate misses. ___ 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: Optimizing garbage collection
What happens if you just increase the default size? ___ 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: Optimizing garbage collection
On Mon, Nov 22, 2010 at 11:14 PM, Jon Harrop jonathandeanhar...@googlemail.com wrote: What happens if you just increase the default size? Well we don't want to be a memory hog like Java do we? It's something that kind of depends on the app, what would you set it to? Cheers, -- 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
[Caml-list] Re: Is OCaml fast?
David Rajchenbach-Teller David.Teller at univ-orleans.fr writes: I can confirm that old code-snippets were removed (and that both faster solutions and environment variable tweaks were rejected). Even back in 2001, Doug Bagley had noted all the things that were wrong with the tasks on his The Great Computer Language Shootout. During autumn 2004, on Brent Fulgham's website, new tasks were added and old Doug Bagley tasks removed. By 2005 only 2 tasks remained from that old Doug Bagley website. By August 2008 none of those old Doug Bagley tasks were measured for the current benchmarks game. ___ 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] [Was: OCamlJit 2.0]
2010/11/20 Yoann Padioleau pada...@wanadoo.fr: Do we have example of big companies porting their whole codebase to another language ? Linspire? The distro ERS went to work, formely Lindows. They had everything in OCaml and then rewrote to Haskell. It seems to me that OCaml wasn't functional enough. It seems to me that they broke, too. ___ 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] Re: Is OCaml fast?
Gerd Stolpmann info at gerd-stolpmann.de writes: -snip- I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? Even back in 2001, on Doug Bagley's website called The Great Computer Language Shootout Ocaml was not #1- http://web.archive.org/web/20010602051335/www.bagley.org/~doug/shootout/craps.shtml Doug Bagley stopped updating his website in Fall 2001. Even back in 2004, when Brent Fulgham started his website using the same programs, OCaml was not #1 http://web.archive.org/web/20040717184911/shootout.alioth.debian.org/craps.php ___ 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
