Re: [Caml-list] Re: Why OCaml rocks
On Friday 09 May 2008 21:40:45 Gerd Stolpmann wrote: > Am Freitag, den 09.05.2008, 19:10 +0100 schrieb Jon Harrop: > > If OCaml is good for concurrency on distributed systems that is great but > > it is completely different to CPU-bound parallelism on multicores. > > You sound like somebody who tries to sell hardware :-) :-) > Well, our algorithms are quite easy to parallelize. I don't see a > difference in whether they are CPU-bound or disk-bound - we also have > lots of CPU-bound stuff, and the parallelization strategies are the > same. > > The important thing is whether the algorithm can be formulated in a way > so that state mutations are rare, or can at least be done in a > "cache-friendly" way. Such algorithms exist for a lot of problems. I > don't know which problems you want to solve, but it sounds like as if it > were special problems. Like for most industries, most of our problems > are simply "do the same for N objects" where N is very large, and > sometimes "sort data", also for large N. Right. Those are embarassingly parallel problems, which is why you are not suffering from a lack of fine-grained parallelism as we are. Some problems require fine-grained parallelism but, on a more general note, we are trying to push parallelism as deep into our libraries as possible so that users can benefit from their multicore machines whatever they are doing. The ability to spawn parallel computions efficiently is of the utmost importance here. Without it, multicore holds no advantages (e.g. for that matrix multiply benchmark with n<100). > > Parallelism is easy in F#. > > Wonders must have happened I'm not aware of. How does F# prevent > deadlocks? Parallel programming is typically extremely well suited to data parallel constructs (parallel for and so forth) so deadlocks are not a problem. However, F# is also unusually good for improving robustness even in the presence of low-level threading constructs because, just like OCaml, mutation is contained and typically reversed for performance-critical sections of code. So the number of locks in a large parallel F# applications is tiny compared to Java/C# and it is perfectly feasible to manage their potential interactions (i.e. to avoid deadlocks) by hand. > > > This is a quite theoretical statement. We will rather see that most > > > application programmers will not learn parallelism at all, and that > > > consumers will start question the sense of multicores, and the chip > > > industry will search for alternatives. > > > > On the contrary, that is not a theoretical statement at all: it already > > happened. F# already makes it much easier to write high performance > > parallel algorithms and its concurrent GC is the crux of that capability. > > Don't misunderstand me, I'm not anti-F#. This will all apply to OCaml when it gets a parallel GC this summer. :-) > I only have no interests right > now in taking advantage of multicores by concurrent GC's. I rather want > to have an ultra-fast single-core execution. I can do the > parallelization myself. Right. Our customers are loving parallelism right now and want to make the most of their multicore machines today. This is pushing us to make everything as multicore friendly as possible. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ 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: Why OCaml rocks
On Tuesday 13 May 2008 03:03:10 Gerd Stolpmann wrote: > Am Dienstag, den 13.05.2008, 02:19 +0100 schrieb Jon Harrop: > > On Tuesday 13 May 2008 01:42:42 Gerd Stolpmann wrote: > > > In this (very unoptimized) multiplier message passing accounts for ~25% > > > of the runtime. Even for 2 cores there is already a speedup. 10 cores > > > (over a network) are about 4 times faster than a single core without > > > message passing. > > > > For what values of "n"? > > It's in the article. n=1000, 2000, 3000. The "4 times faster" statement > is for n=3000. Can you find a more accurate estimate of the threshold value of "n" above which there is a speedup on 2 cores? I think that would be very useful. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ 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: Why OCaml rocks
Am Dienstag, den 13.05.2008, 02:19 +0100 schrieb Jon Harrop: > On Tuesday 13 May 2008 01:42:42 Gerd Stolpmann wrote: > > Am Montag, den 12.05.2008, 14:22 +0100 schrieb Richard Jones: > > > This is just barely faster than Jon's OCaml version using message > > > passing (12% faster on my test machine[0]). Which just seems to show > > > that the overhead of message passing _isn't_ the problem here[1]. > > > > I've just written my own distributed version. You find my comments and > > timings here: > > > > http://blog.camlcity.org/blog/parallelmm.html > > > > The code is here: > > > > https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/examples/rpc/mat > >rixmult/ > > > > In this (very unoptimized) multiplier message passing accounts for ~25% > > of the runtime. Even for 2 cores there is already a speedup. 10 cores > > (over a network) are about 4 times faster than a single core without > > message passing. > > For what values of "n"? It's in the article. n=1000, 2000, 3000. The "4 times faster" statement is for n=3000. Gerd -- Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany [EMAIL PROTECTED] 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] Re: Why OCaml rocks
On Tuesday 13 May 2008 01:42:42 Gerd Stolpmann wrote: > Am Montag, den 12.05.2008, 14:22 +0100 schrieb Richard Jones: > > This is just barely faster than Jon's OCaml version using message > > passing (12% faster on my test machine[0]). Which just seems to show > > that the overhead of message passing _isn't_ the problem here[1]. > > I've just written my own distributed version. You find my comments and > timings here: > > http://blog.camlcity.org/blog/parallelmm.html > > The code is here: > > https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/examples/rpc/mat >rixmult/ > > In this (very unoptimized) multiplier message passing accounts for ~25% > of the runtime. Even for 2 cores there is already a speedup. 10 cores > (over a network) are about 4 times faster than a single core without > message passing. For what values of "n"? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ 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: Why OCaml rocks
Am Montag, den 12.05.2008, 14:22 +0100 schrieb Richard Jones: > This is just barely faster than Jon's OCaml version using message > passing (12% faster on my test machine[0]). Which just seems to show > that the overhead of message passing _isn't_ the problem here[1]. I've just written my own distributed version. You find my comments and timings here: http://blog.camlcity.org/blog/parallelmm.html The code is here: https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/examples/rpc/matrixmult/ In this (very unoptimized) multiplier message passing accounts for ~25% of the runtime. Even for 2 cores there is already a speedup. 10 cores (over a network) are about 4 times faster than a single core without message passing. Gerd > Perhaps it's the bounds checking in the assignment back to the matrix? > > Anyhow, in real life situations we'd all be using a super-optimized > hand-coded-in-assembly matrix multiplication library (LAPACK?), so > this is all very academic. > > Rich. > > [0] Quad core Intel hardware: > model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz > > [1] Creation of the result matrix and copying it to shared memory is > almost instantaneous in my tests. > -- Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany [EMAIL PROTECTED] 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] uint64lib release (again), plus help request
Dear Ocaml-ers, The good news is that I have my little library for machine-native 64-bit unsigned integers hosted at OCaml Forge now! http://forge.ocamlcore.org/frs/?group_id=23 The bad news is that despite my best attempts I am unable to get it to link with programs compiled with ocamlopt. If anyone would like to help please let me know and I can give you SVN access. Sincerely, Jeff ___ 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] polymorphic recursion clarification
maybe I should state why I need polymorphic recursion consider the function traverse which takes a function and an element of what I want to traverse and returns a list of results. let rec traverse f n= let ret = f n in let rest = match n#get_right_sibling_specific with None -> [] | Some y -> traverse f y in let rest2 = match n#get_child_specific with None -> [] | Some y -> traverse f y in match ret with None -> rest @ rest2 | Some y -> y :: rest @ rest2 with type val traverse : ((< get_child_specific : 'a option; get_right_sibling_specific : 'a option; .. > as 'a) -> 'b option) -> 'a -> 'b list the problem is that get_child_specific may not return an 'a option, but it will always return a subtype of 'a option. is there any way to do this? ie, give it a type ((< get_child_specific : #'a option; get_right_sibling_specific : #'a option; .. > as 'a) -> 'b option) -> 'a -> 'b list ? (I believe this can be done with polymorphic recursion) --Jacques ___ 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] polymorphic recursion
On Mon, 12 May 2008 17:55:40 -0400, Jacques Le Normand wrote: > > does ocaml support polymorphic recursion and, if so, what's the syntax? Yes. There are a couple of ways to make it work, using polymorphic records or recursive modules. You should check the archives of this list for examples: http://groups.google.com/groups/dir?q=fa.caml Cheers, ChriS ___ 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] polymorphic recursion
Hello list, I'm having trouble finding information on this; does ocaml support polymorphic recursion and, if so, what's the syntax? --Jacques ___ 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: Why OCaml rocks
The concrurent GC that we are writing? You must know more things than I do. Note to myself: raise this in the next meeting. I think you are referring to the Ocaml summer project which is to be done by Emmanuel Chailloux's student. Till 2008/5/12 Arthur Chan <[EMAIL PROTECTED]>: > >> >> >>let c = Array2.zero_create am bn >>Parallel.For(0, n, fun i -> >> for j = 0 to n - 1 do >>let mutable r = 0.0 >>for k = 0 to n - 1 do >> r <- r + a.[i,k] * b.[k,j] >>c.[i,j] <- r) >> > > That is indeed a very pretty piece of code. I was wondering. The > concurrent GC that the Jane St. folks are writing, will it be useable with > the default stdlib that ships with ocaml, or will we have to use theirs? > > ___ > 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 > > -- http://till-varoquaux.blogspot.com/ ___ 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: Why OCaml rocks
> > >let c = Array2.zero_create am bn >Parallel.For(0, n, fun i -> > for j = 0 to n - 1 do >let mutable r = 0.0 >for k = 0 to n - 1 do > r <- r + a.[i,k] * b.[k,j] >c.[i,j] <- r) > > That is indeed a very pretty piece of code. I was wondering. The concurrent GC that the Jane St. folks are writing, will it be useable with the default stdlib that ships with ocaml, or will we have to use theirs? ___ 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: Why OCaml rocks
> > > The fact is, this is hugely important to the vast majority of the software > industry and companies are investing massive amounts of time and effort > into > parallelizing their software. Developers are flocking to .NET because it > makes parallelism easy and OCaml has the potential to provide these > benefits > if the parallel GC project flies. > > Maybe... while I agree with your earlier points, I have not seen *any* .NET uptake in the bay area, particularly with startups. People are using Hadoop, or some in-house version of it, or toying with Erlang, to get parallel efficiency. ___ 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: Why OCaml sucks
Arthur Chan wrote: Yet, if you look at things in the light of "optimization is depessimization", you'd much rather have easier to read code, than code which is ugly because you preoptimized it by hand. This is why, for me, Ocaml has a long way to go to make it useful for run-of-the-mill production code. My pet peev is performance penalty paid for writing in functional style where it actually makes sense -- say passing an arithmetic operator to a map-style function. What do you mean by this? What language would not incur this kind of performance hit? Is F# able to optimize this out or were you referring to something else? For Ocaml: "when inlining higher-order functions with known function arguments, those known function arguments are not themselves inlined." http://camltest.inria.fr/pub/old_caml_site/caml-list/1048.html (This is an old post, if things have changed I would love to be corrected.) sml can inline such functions, making passing + to a map style function potentially as efficient as writing a procedural loop. ___ 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: Why OCaml sucks
> I can't comment about the original lack of parallelism issue, but the > platform-bashing comment is just gibberish to me. I'm all for cool, > inspiring > platforms, and I use OS X and Linux exclusively at home/school, but > Windows > has made some headway in recent years and for me XP is quite reasonable as > long as you don't deal with driver writing. The latter is still better > than > in WIN95 DDK days, but the toolset (apart from the F#-based tools) is > obscenely out-of-date, just as it was in 1995. Then there are some > regressed > pieces of Linux which are quite a reality check given the whole "we > support > old hardware" propaganda (steer clear of SCSI tape drives), so for me > personally I have equally many bash-Windows arguments as I have bash-Linux > ones. > > Cheers, Kuba > Lets not start a platform war on this thread. I have *plenty* of gripes with Linux as well. I was merely digressing, and was sniping at the high cost of platform specific development. If you want to discuss Windows programming gripes, Joel Spolsky's forum has plenty, even with regard to the idea that things have been better lately. ocaml+qt does not count. If you're using ocaml+qt, then you've basically sidestepped the issues with writing code for Windows. ___ 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: Why OCaml sucks
> Yet, if you look at things in the light of "optimization is
> depessimization",
> you'd much rather have easier to read code, than code which is ugly
> because
> you preoptimized it by hand. This is why, for me, Ocaml has a long way to
> go
> to make it useful for run-of-the-mill production code. My pet peev is
> performance penalty paid for writing in functional style where it actually
> makes sense -- say passing an arithmetic operator to a map-style function.
>
What do you mean by this? What language would not incur this kind of
performance hit? Is F# able to optimize this out or were you referring to
something else?
>
> Cheers, Kuba
>
> ___
> 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
>
--
---
(\__/)
(='.'=)This is Bunny. Copy and paste Bunny into your
(")_(")signature to help him gain world domination.
___
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] Issue #4265 (Printexc)
2008/5/10 Berke Durak <[EMAIL PROTECTED]>: > On Sat, May 10, 2008 at 10:36 AM, Christophe TROESTLER < > [EMAIL PROTECTED]<[EMAIL PROTECTED]>> > wrote: > > > > > Is it what you want: http://caml.inria.fr/mantis/view.php?id=4265 ? > > > That's a very nice thing to have. Please, Xavier, could you expose the > loc_info type > and the get_exception_backtrace in the Printexc interface? That would > allow, > for instance, to intelligently log the exceptions raised by the subthreads > in a > long-running web server without having to re-parse the string > representation. > There is also a patch available (against 3.10.x) here http://skydeck.com/blog/programming/more-stack-traces-in-ocaml/ It exposes only the string representation, but it handles dynamically loaded code (so e.g. can give stack traces in the toplevel), at the cost of keeping debugging info in memory all the time. Jake ___ 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: Why OCaml sucks
On Monday 12 May 2008 14:31:04 Kuba Ober wrote: > I'm no F# fanboy; I use Ocaml exclusively for most of my numerical work > (some FEM, all numerical methods courses I take), but as a language for > packaged application development (bread-and-butter stuff that sells in > boxes or via downloads) it's simply not there yet for me. F# would be more > like it, if I weren't wary of .net platform lock-in. Give Mono a few more > years and it won't be an issue anymore... This raises the question of whether or not the Mono backend for OCaml might pay off? My impression is that Mono is going nowhere but I have been known to be overly skeptical in the past. ;-) Speaking of which, it would also be interesting to compare the performance of OCaml with F#/Mono on that matrix-matrix multiply benchmark... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ 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] From ancient to a third Generation
The following idea traversed my mind reading the previous thread about ancient. May be I am missing something, So I hope the expert could tell me if they think this is possible/good idea/bad idea We could add to OCaml a third generation with the following properties: - Objects are moved to this third generation either manually (or created there) or automatically after surviving k major GC (k may be ajustable at runtime ? k = 0 means never ?) - Objects in the third generation can be shared between processes (like in Ancient) - There is a global greyval table, protected by a mutex, and an object must be added in the table of greyval when mutated if it is a pointer pointing to the major or minor heap of a specific process. Then, the object stops to be accessible for reading by other processes (Here there is room to change the design ...). - Objects in the third generation are collected by a reference counter + a specific GC: the counter counts the number of processes holding at least one pointer to this object from their own stack, major or minor heap. This counter is only increased/decreased by the GC of each process (a mutex is neeeded here). There is also a specific GC process (mark and sweep ?). To take care of pointers from the third generation to the third generation and make sure that object with a zero counter can be removed. - This third generation could be dealf with be a daemon and accessible by processes written using different languages ... What do you think ? -- 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: [EMAIL PROTECTED] 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 - begin:vcard fn:Christophe Raffalli n:Raffalli;Christophe org:LAMA (UMR 5127) email;internet:[EMAIL PROTECTED] title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences tel;work:+33 4 79 75 81 03 note:http://www.lama.univ-savoie.fr/~raffalli x-mozilla-html:TRUE version:2.1 end:vcard signature.asc Description: OpenPGP digital signature ___ 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: Why OCaml rocks
On Monday 12 May 2008 14:22:24 Richard Jones wrote: > This is just barely faster than Jon's OCaml version using message > passing (12% faster on my test machine[0]). On this machine, the Ancient-based implementation is 30-40% faster than the message passing OCaml. The important question is: how many operations must we be doing for parallelism to be worthwhile? The answer is of fundamental importance. Plotting the graphs, we find that parallelism is faster in F# for n>32 and in OCaml for n>150 for this O(n^3) task. Therefore, OCaml is two orders of magnitude slower than F# at spawning parallel computations. Moreover, to get this performance from OCaml you had to sacrifice safety. > Which just seems to show that the overhead of message passing _isn't_ the > problem here[1]. Well, OCaml currently offers several different approaches to parallelism that are all extremely inefficient. The parallel GC implementation being funded by Jane St. will completely remove this performance problem with OCaml in this context but it will not scale as well as Microsoft's concurrent GC and will suffer from the same stalling. This is why I believe that project is of incredible importance. > Perhaps it's the bounds checking in the assignment back to the matrix? Actually it was the polymorphic array maps and copies rather than the bounds checking within them. So I hand rolled optimized float array array copying code into both of the new parallel OCaml implementations to get the best possible performance out of OCaml for the above comparison. > Anyhow, in real life situations we'd all be using a super-optimized > hand-coded-in-assembly matrix multiplication library (LAPACK?), so > this is all very academic. If you ignore the impedance mismatch between the data structures, the performance overhead of invoking external functions and all applications that require different functionality that has not already been written, optimized and packaged by someone else, yes. The fact is, this is hugely important to the vast majority of the software industry and companies are investing massive amounts of time and effort into parallelizing their software. Developers are flocking to .NET because it makes parallelism easy and OCaml has the potential to provide these benefits if the parallel GC project flies. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ 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: Why OCaml sucks
On Monday 12 May 2008 13:54:45 Kuba Ober wrote: > > 5. Strings: pushing unicode throughout a general purpose language is a > > mistake, IMHO. This is why languages like Java and C# are so slow. > > Unicode by itself, when wider-than-byte encodings are used, adds "zero" > runtime overhead; the only overhead is storage (2 or 4 bytes per > character). You cannot degrade memory consumption without also degrading performance. Moreover, there are hidden costs such as the added complexity in a lexer which potentially has 256x larger dispatch tables or an extra indirection for every byte read. > Given that storage is cheap, I'd much rather have Unicode support than lack > of it. Sure. I don't mind unicode being available. I just don't want to have to use it myself because it is of no benefit to me (or many other people) but is a significant cost. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ 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] ocamlc freezes
From: Richard Jones <[EMAIL PROTECTED]>
> On Sun, May 11, 2008 at 09:19:26PM -0400, Jacques Le Normand wrote:
> > hello caml-list
> > when I try to compile
> >
> > class type node =
> > object
> > method get_right_sibling : node option
> > end
> > class type ['top_parent_type,'left_sibling_type,'right_sibling_type] typ =
> > object
> > inherit node
> > method get_left_sibling : 'left_sibling_type option
> > method get_right_sibling : 'right_sibling_type option
> > end
> > type 'p foo_typ = ('p,'p foo_typ,'p foo_typ) typ
> >
> > with
> >
> > ocamlc test.ml
> >
> > ocamlc just freezes; I'm using ocaml 3.09.2 on ubuntu. What should I do?
>
> Possibly upgrade. With 3.10.0 this gives an error:
>
> File "test.ml", line 11, characters 4-48:
> This type constructor expands to type
> 'a foo_typ =
> < get_left_sibling : 'a foo_typ option; get_right_sibling : node option >
> but is here used with type node = < get_right_sibling : node option >
> Type node = < get_right_sibling : node option > is not compatible with type
> < get_right_sibling : node option >
> Type
> 'a foo_typ =
> < get_left_sibling : 'a foo_typ option; get_right_sibling : node option >
> is not compatible with type
> < get_left_sibling : 'a foo_typ option; get_right_sibling : node option >
> Types for method get_left_sibling are incompatible
This probably requires a bit of explanation, as the error message
seems to tell that identical types are not so... maybe a bug in the
reporting code.
Anyway, this is the first line that matters.
You cannot change a method's type with method override.
So get_right_sibling in typ has still type [node option], which means
that in foo_typ, ['p foo_typ] should be a [node option], hence the
contradiction.
There was a type-checker bug in 3.09.2, but it is now fixed.
Cheers,
Jacques Garrigue
___
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: Why OCaml sucks
On Friday 09 May 2008, Ulf Wiger (TN/EAB) wrote: > Jon Harrop skrev: > > On Friday 09 May 2008 14:00:52 you wrote: > >> Jon Harrop skrev: > >>> . Parallelism is for performance and performance > >>> > >> > requires mutable data structures. > >> > >> I disagree. SMP Erlang has no mutable data structures, > >> but achieves very good scalability anyway. > > > > Scalability != performance. For CPU intensive tasks, > > > > Erlang is uniformly slow. > > I don't see how you can say that. If you introduce the > restriction that there can be only one CPU, then this > might be true. Some applications are very difficult to > scale to multiple CPUs, but others are inherently > scalable. For some problems, mutable data structures > make all the difference, and in others, they just make > a mess of things. > > If you say "parallelism is for performance", you imply > that the program is scalable, and that it actually makes > a difference to add more CPUs. In this case, mutable > the presence of data structures will make scaling more > difficult. Most problems involved in utilizing multicore > boil down to the widespread use of mutable data structures. > > If the problem isn't scalable, then other tricks are needed > to achieve performance, and mutable data structures may > be indispensable. I think people forget Jon's background/interests: numerical methods. Think of working with large amounts of numbers, where the cost of some operations is on par with copying a few words of memory, and good non-algorithmic (!) optimizations can increase performance 10-fold (see Mersenne project, for example). Moreover, a lot of numerical methods are applied in real-time applications, and there a 50% loss in performance simply means that the game becomes unplayable, or that the phone connection sounds like excrement dropping into the hole. For web applications (generally speaking), a 50% loss of performance means you pay 2x more money for servers and power. Up to a certain point, this is small compared to the costs of maintaining the software. Where numerical methods are widely applied, a 50% performance loss may mean you're out of the market. I'm no F# fanboy; I use Ocaml exclusively for most of my numerical work (some FEM, all numerical methods courses I take), but as a language for packaged application development (bread-and-butter stuff that sells in boxes or via downloads) it's simply not there yet for me. F# would be more like it, if I weren't wary of .net platform lock-in. Give Mono a few more years and it won't be an issue anymore... For server-side use Ocaml is probably fine, but so is a number of languages that for me pack way more punch (Lisp, for one). In any event, these days I see little reason to develop web-facing stuff on non-google platforms (at least if you're a startup), so I'm in Python lock-in in that area anyway now. Cheers, Kuba ___ 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: Why OCaml rocks
FWIW this is an implementation using Ancient: -- let n = 1024 let a = Array.make_matrix n n 6.7 let b = Array.make_matrix n n 8.9 (* Result array, stored in shared memory. *) let c = let c = Array.make_matrix n n 0. in let fd = Unix.openfile "/tmp/zero" [Unix.O_RDWR;Unix.O_TRUNC;Unix.O_CREAT] 0o644 in let md = Ancient.attach fd 0x4400n in Ancient.follow (Ancient.share md 0 c) let parmul_aux i0 i1 n a b = for i = i0 to i1 - 1 do let ai = a.(i) in for j = 0 to n - 1 do let r = ref 0.0 in for k = 0 to n - 1 do r := !r +. Array.unsafe_get ai k *. Array.unsafe_get (Array.unsafe_get b k) j done; c.(i).(j) <- !r done; done let parmul n a b = (match Unix.fork () with 0 -> parmul_aux 0 (n/2) n a b; exit 0 | _ -> ()); parmul_aux (n/2) n n a b; ignore (Unix.wait ()) ;; parmul n a b -- This is just barely faster than Jon's OCaml version using message passing (12% faster on my test machine[0]). Which just seems to show that the overhead of message passing _isn't_ the problem here[1]. Perhaps it's the bounds checking in the assignment back to the matrix? Anyhow, in real life situations we'd all be using a super-optimized hand-coded-in-assembly matrix multiplication library (LAPACK?), so this is all very academic. Rich. [0] Quad core Intel hardware: model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz [1] Creation of the result matrix and copying it to shared memory is almost instantaneous in my tests. -- Richard Jones Red Hat ___ 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: Why OCaml sucks
> > 1. Lack of Parallelism: Yes, this is already a complete show stopper. > > Exploiting multicores requires a scalable concurrent GC and message > > passing (like JoCaml) is not a substitute. Unfortunately, this is now > > true of all functional languages available for Linux, which is why we > > have now migrated entirely to Windows and F#. I find it particularly > > ironic that the Haskell community keep hyping the multicore capabilities > > of pure code when the rudimentary GC in Haskell's only usable > > implementation already stopped scaling. > > Fork? For something like a raytracer, I do not see how threads would be > any more useful than fork. For the UI, the native threads suffice. For > windows... well f*ck windows. When was the last time you heard of a cool > new windows app anyway? MSFT has killed their own platform with bad > engineering decisions. I wouldn't generalize like that. Where I work we use Qt (a C++ framework) and can relatively trivially deploy on three major platforms (Linux, Windows and OS X). It's been a long time since I dealt directly with any Windows deficiencies per se. Trolls had to deal with them for sure, but they did the job so that I wouldn't have to. Most cool applications are multi-platform... I can't comment about the original lack of parallelism issue, but the platform-bashing comment is just gibberish to me. I'm all for cool, inspiring platforms, and I use OS X and Linux exclusively at home/school, but Windows has made some headway in recent years and for me XP is quite reasonable as long as you don't deal with driver writing. The latter is still better than in WIN95 DDK days, but the toolset (apart from the F#-based tools) is obscenely out-of-date, just as it was in 1995. Then there are some regressed pieces of Linux which are quite a reality check given the whole "we support old hardware" propaganda (steer clear of SCSI tape drives), so for me personally I have equally many bash-Windows arguments as I have bash-Linux ones. Cheers, Kuba ___ 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: Why OCaml sucks
> 9. Deforestation: Brian says "Haskell has introduced a very interesting and > (to my knowledge) unique layer of optimization, called deforrestation". > True, of course, but useless theoretical piffle because we know that > Haskell is slow in practice and prohibitively difficult to optimize > to-boot. Deforesting is really easy to do by hand. Yet, if you look at things in the light of "optimization is depessimization", you'd much rather have easier to read code, than code which is ugly because you preoptimized it by hand. This is why, for me, Ocaml has a long way to go to make it useful for run-of-the-mill production code. My pet peev is performance penalty paid for writing in functional style where it actually makes sense -- say passing an arithmetic operator to a map-style function. Cheers, Kuba ___ 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: Why OCaml sucks
> 5. Strings: pushing unicode throughout a general purpose language is a > mistake, IMHO. This is why languages like Java and C# are so slow. Unicode by itself, when wider-than-byte encodings are used, adds "zero" runtime overhead; the only overhead is storage (2 or 4 bytes per character). Given that storage is cheap, I'd much rather have Unicode support than lack of it. How exactly unicode support makes Java and C# slow?! Jon, I'd have thought that you know better than that :( Oh well, we all have bad days. Cheers, Kuba ___ 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] Hashtbl.remove legal within Hashtbl.iter for the same hash table?
Hello Till, "Till Varoquaux" <[EMAIL PROTECTED]> writes: > Indeed. The answer you got was, however, based on the actual > implementation not on the documentation. This means that, at some > point, this might evolve and not be valid anymore. If you want to be > on the safe side you should do a fold instead of an iter and collect > all of the items to remove and then remove them in a second pass. I'll do that. Thanks, d. -- GPG/PGP key: A3AD7A2A David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A ___ 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] ocamlc freezes
On Sun, May 11, 2008 at 09:19:26PM -0400, Jacques Le Normand wrote:
> hello caml-list
> when I try to compile
>
> class type node =
> object
> method get_right_sibling : node option
> end
> class type ['top_parent_type,'left_sibling_type,'right_sibling_type] typ =
> object
> inherit node
> method get_left_sibling : 'left_sibling_type option
> method get_right_sibling : 'right_sibling_type option
> end
> type 'p foo_typ = ('p,'p foo_typ,'p foo_typ) typ
>
> with
>
> ocamlc test.ml
>
> ocamlc just freezes; I'm using ocaml 3.09.2 on ubuntu. What should I do?
Possibly upgrade. With 3.10.0 this gives an error:
File "test.ml", line 11, characters 4-48:
This type constructor expands to type
'a foo_typ =
< get_left_sibling : 'a foo_typ option; get_right_sibling : node option >
but is here used with type node = < get_right_sibling : node option >
Type node = < get_right_sibling : node option > is not compatible with type
< get_right_sibling : node option >
Type
'a foo_typ =
< get_left_sibling : 'a foo_typ option; get_right_sibling : node option >
is not compatible with type
< get_left_sibling : 'a foo_typ option; get_right_sibling : node option >
Types for method get_left_sibling are incompatible
Rich.
--
Richard Jones
Red Hat
___
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
