Re: [Caml-list] Re: Why OCaml rocks
On Friday 09 May 2008, Richard Jones wrote: On Fri, May 09, 2008 at 07:09:57PM +0100, Jon Harrop wrote: F# has long since overtaken all other functional languages in terms of industrial uptake and I have not heard that complaint from anyone. Like OCaml, it follows simple rules and is predictable as a consequence. Figures to back up this extraordinary claim? (And I don't mean the unverifiable figures of a certain Cambridge-based consultancy). These commercial enterprises better hope they don't need to modify the F# compiler at all, and that MS keep releasing new versions and fixes forever, because the terms of the F# license would prevent them from fixing it themselves (unlike if they'd decided to go with an open source solution). Availability of source code enables that, but is not a guarantee that a fix will be forthcoming or economical. Gcc codebase is all for us to see, yet it would require either a genius or lots of time for the ordinary ones among us to get to speed to work with it in general. I've attempted it 2-3 times, and I gave up after a while (just wrapping your mind around gas's borkedness can be revolting), even though I have no problem understanding most of the concepts involved; I maintain a proprietary, half-assed, just-good-enough implementation of a nonconforming Lisp which produces MCU (eZ8 and 12 bit pic) assembly on par with what I can write myself, mostly. But it's written in Lisp too, and while I could probably port it to C, I could never develop it in C (it'd degenerate in a way which makes gcc code look stellar). So even if you do have knowledge in the field, but no first-hand exposure to braindamage involved with writing (and maintaining) a compiler of any sort in a low level lanugage like C, you might as well have no access to the source code -- it won't help much beyond simple recompilation or minor patches needed to have the code compile on a newer revision of the host platform (say newer Linux distro). 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 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
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
On Sat, May 10, 2008 at 9:52 AM, Richard Jones [EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 01:01:03AM +0200, Berke Durak wrote: But you are saying in the README that values in the ancient heap have some limitations, namely no ad-hoc polymorphic primitives. You misunderstand this limitation, but anyway ... The paragraph from your README then needs some clarification. (1) Ad-hoc polymorphic primitives (structural equality, marshalling and hashing) do not work on ancient data structures, meaning that you will need to provide your own comparison and hashing functions. For more details see Xavier Leroy's response here: As you cannot mutate anything that is ancient (since it might be concurrently accessed), you cannot mark or modify them in-place for ad-hoc marshalling or deep copying. Is that correct? Comparison does not mark (and thus does not work on cyclic structures). Does it work on values in the ancient heap (I'm not talking of handles here)? So it seems that adding a generic copy-out-of-the-ancient heap function (which marks in a private area) would be worthwhile. Should not be too difficult. -- Berke ___ 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 Sat, May 10, 2008 at 10:24:50AM +0200, Berke Durak wrote:
(1) Ad-hoc polymorphic primitives (structural equality, marshalling
and hashing) do not work on ancient data structures, meaning that you
will need to provide your own comparison and hashing functions. For
more details see Xavier Leroy's response here:
As you cannot mutate anything that is ancient (since it might be
concurrently
accessed),
There are various restrictions on mutating the ancient data, which are
explained in the README. It is not true that ancient data is
completely immutable, just that you really need to understand what
you're doing in order to do it correctly. There are additional
restrictions to mutating [any] data concurrently, but I didn't explain
those because they are obvious, and can be solved with standard
threading techniques (mutexes, etc.)..
you cannot mark or modify them in-place for ad-hoc marshalling or
deep copying. Is that correct?
I'm not sure what this means. I haven't tried to Marshal ancient
data, because ancient data can already be persisted, so marshaling it
doesn't make much sense.
'Deep copying' of ancient data can be done just like deep copying any
other OCaml value.
Comparison does not mark (and thus does not work on cyclic structures).
Does it work on values in the ancient heap (I'm not talking of handles
here)?
Your use of 'value', 'handle' etc. is confusing me. I suggest you
take a look at how OCaml values are stored (eg. caml/mlvalues.h is a
good place to start).
Anyhow, the polymorphic primitives (like %compare) don't work, just
because they make the assumption that anything outside the normal
OCaml heap is incomparable, but you can certainly write your own
comparison functions to replace those, eg. comparing
character-by-character for strings.
This has nothing to do with 'marking'.
So it seems that adding a generic copy-out-of-the-ancient heap function
(which marks in a private area) would be worthwhile. Should not be too
difficult.
As I said earlier, you can just copy values from the ancient heap as
you would any other value, eg. using { ... with ... } syntax or
Array.copy / String.copy etc.
Let's say this again. Values on the ancient heap look just like
values anywhere else in the program. You can pass them to functions,
print them out, add them up, do whatever else you would normally do,
with very few restrictions. The differences are:
- the polymorphic primitives don't work (so you can't compare or hash them)
- they don't get garbage collected
- you should be very careful about mutating them
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
Re: [Caml-list] Re: Why OCaml rocks
On Friday 09 May 2008 23:25:49 David Teller wrote: On Fri, 2008-05-09 at 19:10 +0100, Jon Harrop wrote: Parallelism is easy in F#. Now, that's a cliffhanger. Could you elaborate? Sure. Review the concerns cited regarding parallel programming in OCaml: 1. When do we fork? Earlier to amortize the overhead or later to enable sharing of data structures? 2. How do we avoid excessive copying? What if each parallel thread only requires part of a data structure, should we dissect the data structure to alleviate message passing? 3. How do we pass values like heap allocated custom blocks? 4. Do we use the Ancient module and manage our memory manually so that we can mutate shared data? These all make parallel programming much harder in OCaml than it needs to be. All of these concerns simply disappear when you have a concurrent GC. F# already does. Hopefully OCaml will soon. Addressing each point in turn: 1. Use the high-performance thread pool provided by the Task Parallel Library. 2. There is no copying. 3. You can pass any value to another thread because everything is uniformly represented. 4. Memory management is fully automated and shared mutable data is easy. Consider the embarassingly-parallel task of matrix-matrix multiplication. Note that this is absolutely best-case for OCaml because the overheads are as small as possible thanks to the complete absence of fine-grained parallelism. Most real applications require much more fine-grained parallelism and OCaml's performance is much worse as a consequence. In F#, this is really easy to write: 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) There are several things to notice about this: . The input matrices are immediately accessible from parallel threads without us having to do anything. There is no copying, so memory consumption is lower and there is no overhead to worry about. . The output matrix is filled directly using mutation. Again, there is no copying, no subsequent single-threaded collation of results and no overhead. . No manual memory management is required. There is no easy solution in OCaml but you might: . Fork a process for each CPU at the start of the multiply in order to avoid copying the input matrices, use message passing to return the result and collate it serially. . Prefork a process for each CPU and use message passing to queue work items, pass the input matrices using message passing, compute results, pass results back using message passing and collate them serially. So we might have an O(1) hit from forking, an O(n^2) hit from message passing and collation and an O(n^3) actual algorithm. Like Ulf said, message passing scales well. However, its raw performance is awful compared to leveraging shared memory. Here is an OCaml implementation of the above F#: let invoke (f : 'a - 'b) x : unit - 'b = let input, output = Unix.pipe() in match Unix.fork() with | -1 - (let v = f x in fun () - v) | 0 - Unix.close input; let output = Unix.out_channel_of_descr output in Marshal.to_channel output (try `Res(f x) with e - `Exn e) []; close_out output; exit 0 | pid - Unix.close output; let input = Unix.in_channel_of_descr input in fun () - let v = Marshal.from_channel input in ignore (Unix.waitpid [] pid); close_in input; match v with | `Res x - x | `Exn e - raise e let parmul_aux i0 i1 n a b = let c = Array.make_matrix (i1 - i0) n 0. in 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 - i0).(j) - !r done; done; c let parmul n a b = let c1 = invoke (fun () - parmul_aux 0 (n/2) n a b) () in let c2 = parmul_aux (n/2) n n a b in Array.concat [c1(); c2] Note that we must manually insert unsafe array accesses and hoist loop invariants in order to obtain comparable performance. This code is clearly much more complicated than the F# and that complexity is completely unnecessary. I think that the cost of copying data is totally overrated. We are doing this often, and even over the network, and hey, we are breaking every speed limit. You cannot afford to pay that price for parallel implementations of most numerical algorithms. Er... Not being a specialist, I may be wrong, but I seem to remember that you can afford that, as long as you're also doing something else during that copy. Here are some actual performance results for this task on my machine: nOCaml F# Serial Parallel Serial Parallel 16 0.5 0.00022
Re: [Caml-list] Re: Why OCaml rocks
Message passing is fine for concurrent applications that are not CPU bound or for distributed computing but it is not competitive on today's multicore machines and will not become competitive in the next decade. i don't understand any of this. 2. How do we avoid excessive copying? What if each parallel thread only requires part of a data structure, should we dissect the data structure to alleviate message passing? this seems to suggest that message passing implies serialising the data structure. perhaps i missed something, though. ___ 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 Freitag, den 09.05.2008, 06:09 +0100 schrieb Jon Harrop: On Friday 09 May 2008 05:45:53 you wrote: On Thu, May 8, 2008 at 5:39 PM, Jon Harrop [EMAIL PROTECTED] wrote: 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. I think the parallelism capabilities are already excellent. We have been able to implement the application backend of Wink's people search in O'Caml, and it is of course a highly parallel system of programs. This is not the same class raytracers or desktop parallelism fall into - this is highly professional supercomputing. I'm talking about a cluster of ~20 computers with something like 60 CPUs. Of course, we did not use multithreading very much. We are relying on multi-processing (both forked style and separately started programs), and multiplexing (i.e. application-driven micro-threading). I especially like the latter: Doing multiplexing in O'Caml is fun, and a substitute for most applications of multithreading. For example, you want to query multiple remote servers in parallel: Very easy with multiplexing, whereas the multithreaded counterpart would quickly run into scalability problems (threads are heavy-weight, and need a lot of resources). There are two problems with that: . You go back to manual memory management between parallel threads/processes. I guess you refer to explicit references between processes. This is a kind of problem, and best handled by avoiding it. We have some cases where we have to keep remote state. The solution was to have a timer, and delete it after some time of not accessing it. After all, most state is only temporary, and if it is lost, it can be created again (at some cost, of course). . Parallelism is for performance and performance requires mutable data structures. In our case, the mutable data structures that count are on disk. Everything else is only temporary state. I admit that it is a challenge to structure programs in a way such that parallel programs not sharing memory profit from mutable state. Note that it is also a challenge to debug locks in a multithreaded program so that they run 24/7. Parallelism is not easy after all. Then you almost always end up copying data unnecessarily because you cannot collect it otherwise, which increases memory consumption and massively degrades performance that, in turn, completely undermines the original point of parallelism. Ok, I understand. We are complete fools. :-) I think that the cost of copying data is totally overrated. We are doing this often, and even over the network, and hey, we are breaking every speed limit. The cost of interthread communication is then so high in OCaml that you will rarely be able to obtain any performance improvement for the number of cores desktop machines are going to see over the next ten years, by which time OCaml will be 10-100x slower than the competition. 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. And _if_ application programmers learn parallelism, then rather in the multi-processing/multiplexing setup we use, and not the multithreading style you propagate. And on servers (where parallelism ought to happen), the poor support of Windows for it (lacking fork and other cool features) is no problem. Gerd When was the last time you heard of a cool new windows app anyway? The last time we released a product. :-) . No 16Mb limit. What do you mean by 16mb limit? OCaml's strings and arrays are limited to 16Mb in 32-bit. . Inlining. isn't it best for the compiler to handle that? I wouldn't mind hearing another perspective on this, but I thought that compilers were smarter these days. Definitely not. Compilers uniformly suck at inlining. For example, agressive inlining is often beneficial in numerical code and often damaging in symbolic code. Compilers cannot tell the difference. This is very similar to unboxed data structures are always better, which also isn't generally true. I've got more gripes to add: . Missing types, like float32 and int16. . DLLs. -- Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany [EMAIL PROTECTED]
Re: [Caml-list] Re: Why OCaml rocks
On Friday 09 May 2008 16:38:55 Jeff Polakow wrote: Hello, We investigated alternative languages to diversify into last year and Haskell was one of them. The single biggest problem with Haskell is that it is wildly unpredictable in terms of performance and memory consumption. This is only the case if you don't understand lazy evaluation. Simon Peyton-Jones told me that. I am sure you will agree that he understands lazy evaluation. This is no different from OCaml, or any language. One must understand the operational semantics to write efficient code. Imagine how a C programmer feels when writing OCaml without knowing to make functions tail-recursive. Tail calls have simple rules. Graph reduction of a lazy program with optimizing rewrites and strictness analysis does not adhere to simple rules. Simple rules = predictable. I wonder if similar complaints (unpredicatable performance, memory use, dearth of practical information) will arise about F# as it starts to be widely adopted in the real world. F# has long since overtaken all other functional languages in terms of industrial uptake and I have not heard that complaint from anyone. Like OCaml, it follows simple rules and is predictable as a consequence. Some of the rules are very different in F#. For example, nested closures degrade performance in OCaml but improve performance in F#. This may well change as we transition to manycore and parallelism makes performance unpredictable. -- 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
First of all let's try to stop the squabling and have some actual some discussions with actual content (trolling is very tempting and I am the first to fall for it). OCaml is extremly nice but not perfect. Other languages have other tradeoffs and the INRIA is not here to fullfill all our desires. On Fri, May 9, 2008 at 9:40 PM, Gerd Stolpmann [EMAIL PROTECTED] wrote: Am Freitag, den 09.05.2008, 19:10 +0100 schrieb Jon Harrop: On Friday 09 May 2008 12:12:00 Gerd Stolpmann wrote: I think the parallelism capabilities are already excellent. We have been able to implement the application backend of Wink's people search in O'Caml, and it is of course a highly parallel system of programs. This is not the same class raytracers or desktop parallelism fall into - this is highly professional supercomputing. I'm talking about a cluster of ~20 computers with something like 60 CPUs. Of course, we did not use multithreading very much. We are relying on multi-processing (both forked style and separately started programs), and multiplexing (i.e. application-driven micro-threading). I especially like the latter: Doing multiplexing in O'Caml is fun, and a substitute for most applications of multithreading. For example, you want to query multiple remote servers in parallel: Very easy with multiplexing, whereas the multithreaded counterpart would quickly run into scalability problems (threads are heavy-weight, and need a lot of resources). 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. In our case, the mutable data structures that count are on disk. Everything else is only temporary state. Exactly. That is a completely different kettle of fish to writing high performance numerical codes for scientific computing. I don't understand. Relying on disk for sharing state is a big problem for us, but unavoidable. Disk is slow memory with a very special timing. Experience shows that even accessing state over the network is cheaper than over disk. Often, we end up designing our algorithms around the disk access characteristics. Compared to that the access to RAM-backed state over network is fast and easy. shm_open shares memories through file descriptors and, under linux/glibc, this done using /dev/shm. You can mmap this as a bigarray and, voila, shared memory. This is quite nice for numerical computation, plus you get closures etc... in your forks. Oh and COW on modern OS's makes this very cheap. I admit that it is a challenge to structure programs in a way such that parallel programs not sharing memory profit from mutable state. Note that it is also a challenge to debug locks in a multithreaded program so that they run 24/7. Parallelism is not easy after all. Parallelism is easy in F#. Wonders must have happened I'm not aware of. How does F# prevent deadlocks? 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#. 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. 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 Fri, 2008-05-09 at 19:10 +0100, Jon Harrop wrote: Parallelism is easy in F#. Now, that's a cliffhanger. Could you elaborate ? Cheers, David I think that the cost of copying data is totally overrated. We are doing this often, and even over the network, and hey, we are breaking every speed limit. You cannot afford to pay that price for parallel implementations of most numerical algorithms. Er... Not being a specialist, I may be wrong, but I seem to remember that you can afford that, as long as you're also doing something else during that copy. 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. Examples ? Pretty please ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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 Fri, May 09, 2008 at 11:13:26PM +0200, Berke Durak wrote: - For sharing complex data, you can marshall into a shared Bigarray. If the speed of Marshal becomes a bottleneck, a specialized Marshal that skips most of the checks/byte-oriented, compact serialization things that extern.c currently does could speed things up. At the risk of sounding like a broken record ... OR you could use Ancient which does the above, right. 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
Re: [Caml-list] Re: Why OCaml rocks
On Fri, May 09, 2008 at 07:09:57PM +0100, Jon Harrop wrote: F# has long since overtaken all other functional languages in terms of industrial uptake and I have not heard that complaint from anyone. Like OCaml, it follows simple rules and is predictable as a consequence. Figures to back up this extraordinary claim? (And I don't mean the unverifiable figures of a certain Cambridge-based consultancy). These commercial enterprises better hope they don't need to modify the F# compiler at all, and that MS keep releasing new versions and fixes forever, because the terms of the F# license would prevent them from fixing it themselves (unlike if they'd decided to go with an open source solution). 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
Re: [Caml-list] Re: Why OCaml rocks
On Sat, May 10, 2008 at 12:25:49AM +0200, David Teller wrote: 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. Examples ? Pretty please ? and please stop throwing him bones to carry on this _stupid_ troll thread. -- Vincent ___ 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
