Browse thread
More cores
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jon Harrop <jon@f...> |
| Subject: | Re: [Caml-list] More Caml |
On Tuesday 23 December 2008 15:32:52 Ashish Agarwal wrote: > > a lot more effort into numerics and string processing and a lot less > > effort into symbolics. > > Is there any fundamental reason these two goals must be at odds? No theoretical reason, AFAIK. > Why can't a compiler be good at numeric and symbolic computation? The required performance characteristics appear to be mutually exclusive when it comes to GCs. Symbolics benefit enormously from extremely fast allocation rates for short-lived values and numerics benefit enormously from efficient handling of shared memory. Today's GCs either provide one or the other. OCaml is ideal for symbolics and awful for parallel programming. The CLR is awful for symbolics and good for parallel programming. The JVM is arguably the best trade-off but its run-time cannot handle tail calls, which makes it a useless for performant functional languages. In the case of the compiler I'm writing, there are more pressing practical concerns. Primarily that it is extremely difficult to write an efficient GC like OCaml's, if not impossible within the confines of LLVM (and LLVM is the only thing making this feasible for me). I believe I can get some kind of GC working, possibly even a parallel GC. Moreover, I think I can remove all (performance) overhead associated with automatic memory management from numerical routines. I think that would be very compelling even if it were bad for symbolics... -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e