On Friday 25 September 2009 00:28:57 Jon Harrop wrote:
> Just to quantify this with a data point: the fastest (serial) version of my
> ray tracer benchmark is 10x slower with the new GC. However, this is
> anomalous with respect to complexity and the relative performance is much
> better for simple
On Saturday 26 September 2009 00:26:50 Benjamin Canou wrote:
> On the maintenance side, as Philippe said, we already have some half
> working version with ocaml 3.11.x, but partly because of the changes
> made to the native runtime in this release and partly because of [1],
> porting the patch is n
On Saturday 26 September 2009 14:51:21 kche...@math.carleton.ca wrote:
> > On Saturday 26 September 2009 01:45:50 kche...@math.carleton.ca wrote:
> >> Perhaps an off-topic and naive question: What does it take to beat F#
> >> and
> >> still have predictable performance?
> >
> > Provided you're talk
> On Saturday 26 September 2009 01:45:50 kche...@math.carleton.ca wrote:
>> Perhaps an off-topic and naive question: What does it take to beat F#
>> and
>> still have predictable performance?
>
> Provided you're talking abouts today's machines and don't care about pause
> times, HLVM with a paralle
On Friday 25 September 2009 22:39:42 Jon Harrop wrote:
> On Friday 25 September 2009 05:07:21 Jacques Garrigue wrote:
> > Hashtables in Python are a basic feature of the language,
> > and they are of course implemented in C. In ocaml, they are
> > implemented in ocaml (except the hashing function,
On Saturday 26 September 2009 01:45:50 kche...@math.carleton.ca wrote:
> Perhaps an off-topic and naive question: What does it take to beat F# and
> still have predictable performance?
Provided you're talking abouts today's machines and don't care about pause
times, HLVM with a parallel GC (not u
> I will add that we did not made this experiment to beat F# or python's
> hashtables, so I will not comment on that here. The point about
> performance is that it should be *predictable*.
Perhaps an off-topic and naive question:
What does it take to beat F# and still
have predictable performance?
Hi everyone,
And let's have a little prayer for Philippe who is now in bed, suffering
from its head and hands because of his teammates letting him answer all
the mail.
Just (half) kidding.
So,
Xavier Leroy a wrote (and probably described the work quite well) :
what they did is an amazing h
> Rethinking our application/algorithmic structure may not be a real
> deterrent. An application does not require parallel/concurrent
> processing everywhere. It is really a question of identifying where
> and when this is useful. Much like selecting the most "appropriate"
> data-structure for any
On Friday 25 September 2009 05:07:21 Jacques Garrigue wrote:
> Your benchmark seems strange to me, as you are comparing apples with
> oranges.
In some sense, yes. I was interested in the performance of the
defacto-standard hash table implementations and not the performance that can
be obtained b
Jon Harrop wrote:
On Thursday 24 September 2009 13:39:40 Stefano Zacchiroli wrote:
On Thu, Sep 24, 2009 at 12:52:24PM +0100, Jon Harrop wrote:
The next steps are to get oc4mc into the apt repositories and build
Uhm, I'm curious: how do you plan to achieve that?
Good question. I have no idea,
On Fri, Sep 25, 2009 at 1:28 AM, Jon Harrop wrote:
> On Thursday 24 September 2009 15:38:06 Philippe Wang wrote:
>> Very few programs that are not written with multicore in mind would
>> not be penalized.
>> I mean our GC is much much dumber than INRIA OCaml's one.
>> Our goal was to show it was p
> On Friday 25 September 2009 08:32:26 Hugo Ferreira wrote:
>> Put it another way; if parallel/concurrent programming could be
>> easily used with a minimum of effort then I believe "most people"
>> would use it simply because it is available.
>
> Once your run-time supports it, you just need a lib
On Friday 25 September 2009 08:32:26 Hugo Ferreira wrote:
> Put it another way; if parallel/concurrent programming could be
> easily used with a minimum of effort then I believe "most people"
> would use it simply because it is available.
Once your run-time supports it, you just need a library tha
On Sep 25, 2009, at 6:07 AM, Jacques Garrigue wrote:
First, like everybody else, I'd like very much to try this out.
Is there any chance it could compile on Snow Leopard :-)
(I suppose it's near impossible, but still ask...)
I haven't tried that yet, mostly because I guess that it wouldn't wo
Jon Harrop a écrit :
> If you want to draw aspirations based upon popularity, look at the most
> popular languages: Java and C#. [...]
I which world? Do you have references? These languages might be the most
commercially {backed,advertised,etc.}, so I guess you are refering to
the software indust
Hello,
In tried not getting into this discussion but I could not resist
commenting on the following:
Jacques Garrigue wrote:
>...
> ... There are applications for that (ray tracing is
> one), but this is not the kind of needs most people have.
>...
As with most technology people will or will no
First, like everybody else, I'd like very much to try this out.
Is there any chance it could compile on Snow Leopard :-)
(I suppose it's near impossible, but still ask...)
From: Jon Harrop
> Visual Basic has been a *lot* faster than OCaml for several years now, not
> least because it makes effic
On Sep 25, 2009, at 1:28 AM, Jon Harrop wrote:
On Thursday 24 September 2009 15:38:06 Philippe Wang wrote:
Very few programs that are not written with multicore in mind would
not be penalized.
I mean our GC is much much dumber than INRIA OCaml's one.
Our goal was to show it was possible to hav
On Thursday 24 September 2009 15:38:06 Philippe Wang wrote:
> Very few programs that are not written with multicore in mind would
> not be penalized.
> I mean our GC is much much dumber than INRIA OCaml's one.
> Our goal was to show it was possible to have good performance with
> multicores for OCa
> Visual Basic has been a *lot* faster than OCaml for several years now, not
> (...) Even Python (...) Java and C#. They are far more popular than OCaml for
> many
> reasons but parallel threads to make efficient multicore programming easy is
> a big one.
In general you sounds like a reasonabl
On Thursday 24 September 2009 17:49:33 Richard Jones wrote:
> On Thu, Sep 24, 2009 at 02:09:56PM +0100, Jon Harrop wrote:
> > Fair enough. I think this is the single most important development OCaml
> > has seen since its inception so I would personally drop OCaml in favor of
> > oc4mc even if it m
> Should we tell them that using CPU for nothing (side-effect for using
> a "slow language") has a bad effect on global warming? Could it be a
> wake-up call? :-p
It also has bad effect on battery life, but that does not refrain them
from releasing full software stacks for embedded devices ba
Well, let me join the chorus and congratulate.
I'll need to test this as soon as possible.
Cheers,
David
On Tue, 2009-09-22 at 23:30 +0200, Philippe Wang wrote:
> This is some additional "noise" about "OCaml for Multicore
> architectures" (or "Ok with parallel threads GC").
>
On Thu, Sep 24, 2009 at 06:56:16PM +0200, Philippe Wang wrote:
> On Sep 24, 2009, at 18:49 GMT+02:00, Richard Jones wrote:
>
> >On Thu, Sep 24, 2009 at 02:09:56PM +0100, Jon Harrop wrote:
> >>Fair enough. I think this is the single most important development
> >>OCaml has
> >>seen since its ince
On Sep 24, 2009, at 18:49 GMT+02:00, Richard Jones wrote:
On Thu, Sep 24, 2009 at 02:09:56PM +0100, Jon Harrop wrote:
Fair enough. I think this is the single most important development
OCaml has
seen since its inception so I would personally drop OCaml in favor
of oc4mc
even if it meant r
On Thu, Sep 24, 2009 at 02:09:56PM +0100, Jon Harrop wrote:
> Fair enough. I think this is the single most important development OCaml has
> seen since its inception so I would personally drop OCaml in favor of oc4mc
> even if it meant reverting to 3.10.2.
I think 'personally' is the key word th
On Sep 24, 2009, at 18:02 GMT+02:00, Pascal Cuoq wrote:
On Sep 24, 2009, at 5:47 PM, Philippe Wang wrote:
Is the copy operation parallelized?
Nope. When the world is stopped for the collection, everything is
done
sequentially until the world is resumed.
I don't think it's relevant to pa
On Sep 24, 2009, at 5:47 PM, Philippe Wang wrote:
Is the copy operation parallelized?
Nope. When the world is stopped for the collection, everything is done
sequentially until the world is resumed.
I don't think it's relevant to parallelize the copy operation (hell to
implement&debug, then I d
On Thursday 24 September 2009 13:11:24 ri...@happyleptic.org wrote:
> > Until now, OCaml sucked at parallelism. (...) OCaml programmers
> > can write OCaml programs that use multicore machines efficiently
> > for the first time.
>
> Subtle and strongly argumented, as expected.
I forgot to mention
On Thursday 24 September 2009 16:36:17 Philippe Wang wrote:
> >> I'm not too familiar with concurrency in ocaml.
> >> How does OC4MC compare with JoCaml?
> >
> > JoCaml is all about concurrency: minimizing latency. Oc4mc is all about
> > parallelism: maximizing throughput.
>
> Maybe a nice thing wo
>> I'm not too familiar with concurrency in ocaml.
>> How does OC4MC compare with JoCaml?
>
> JoCaml is all about concurrency: minimizing latency. Oc4mc is all about
> parallelism: maximizing throughput.
Maybe a nice thing would be to have both in one piece...
--
Philippe Wang
m...@philippewan
Hi,
> Very few programs that are not written with multicore in mind would
> not be penalized. I mean our GC is much much dumber than INRIA OCaml's
> one. Our goal was to show it was possible to have good performance with
> multicores for OCaml. Maybe someday we'll find some time to optimize
> the
I've seen a question about 3.11 and I think I didn't answer, so I'm
answering here :
We have tried to make OC4MC work with OCaml 3.11 (I don't remember the
subsubversion number). Currently, it does not work properly (it's
still too easy to write a program that crashes or deadlocks).
Cheers,
Phil
On Thu, Sep 24, 2009 at 3:11 PM, Jon Harrop wrote:
> Are values such as float arrays copied in their entirety or are they allocated
> outside the shared heap and only a pointer to them is copied?
They should be in a heap (page or shared). We don't allocate many
things outside the heaps.
> Is the
On Thu, Sep 24, 2009 at 09:55:53AM -0400, Mike Lin wrote:
> On Thu, Sep 24, 2009 at 8:39 AM, Stefano Zacchiroli wrote:
> > So, the real question is: is OC4MC going to be ported to mainline OCaml
> > and support in the future or not?
>
> Recalling how mainline had us waiting like 5 years for nativ
On Thu, Sep 24, 2009 at 04:40:53PM +0300, Rakotomandimby Mihamina wrote:
> I dont write so much programs that would really require multiple cores.
> But I think this is such a good "feature" that should be inclided in
> the main distribution...
I think you miss what does that would mean in terms o
On Thu, Sep 24, 2009 at 4:11 PM, Dario Teixeira wrote:
> Hi,
>
> Cheers for the work you guys put into this project! And I'd like to join
> the crowd that has questions, if I may:
>
> a) If I understand correctly, part of prerequisites for implementing the
> new GC was cleaning up the excessive
On Thu, Sep 24, 2009 at 3:40 PM, Rakotomandimby Mihamina
wrote:
> 09/24/2009 03:39 PM, Stefano Zacchiroli:
>>
>> So, the real question is: is OC4MC going to be ported to mainline OCaml
>> and support in the future or not?
>
> I dont write so much programs that would really require multiple cores.
Hi,
Cheers for the work you guys put into this project! And I'd like to join
the crowd that has questions, if I may:
a) If I understand correctly, part of prerequisites for implementing the
new GC was cleaning up the excessive use of imperative constructs in
the compiler's tree. Will the
On Thu, Sep 24, 2009 at 8:39 AM, Stefano Zacchiroli wrote:
>
> So, the real question is: is OC4MC going to be ported to mainline OCaml
> and support in the future or not?
Recalling how mainline had us waiting like 5 years for native exception
backtraces, and then another like 3 years for the ab
09/24/2009 03:39 PM, Stefano Zacchiroli:
So, the real question is: is OC4MC going to be ported to mainline OCaml
and support in the future or not?
I dont write so much programs that would really require multiple cores.
But I think this is such a good "feature" that should be inclided in
the mai
On Thursday 24 September 2009 13:14:35 Philippe Wang wrote:
> On Thu, Sep 24, 2009 at 3:47 AM, Jon Harrop wrote:
> > Following your advice, it seems to work perfectly now:
> >
> :-)
> :
> > Wow! 2.6x faster on 2 cores is good. ;-)
>
> your machine is more generous than ours (which is Intel, not AM
On Thursday 24 September 2009 13:39:40 Stefano Zacchiroli wrote:
> On Thu, Sep 24, 2009 at 12:52:24PM +0100, Jon Harrop wrote:
> > The next steps are to get oc4mc into the apt repositories and build
>
> Uhm, I'm curious: how do you plan to achieve that?
Good question. I have no idea, of course. :-
On Thu, Sep 24, 2009 at 12:52:24PM +0100, Jon Harrop wrote:
> The next steps are to get oc4mc into the apt repositories and build
Uhm, I'm curious: how do you plan to achieve that?
AFAICT the patch is only against 3.10.2, and in Debian we're at 3.11.1.
Thus far, we have never had support for more
On Thu, Sep 24, 2009 at 3:47 AM, Jon Harrop wrote:
> Following your advice, it seems to work perfectly now:
:-)
> Wow! 2.6x faster on 2 cores is good. ;-)
your machine is more generous than ours (which is Intel, not AMD) :-)
> That's a really fantastic piece of work. I'll do my best to study i
> Until now, OCaml sucked at parallelism. (...) OCaml programmers
> can write OCaml programs that use multicore machines efficiently
> for the first time.
Subtle and strongly argumented, as expected.
___
Caml-list mailing list. Subscription management:
09/24/2009 02:52 PM, Jon Harrop:
The next steps are to get oc4mc into the apt repositories
Amen! ;-)
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34
__
On Thursday 24 September 2009 11:00:57 kche...@math.carleton.ca wrote:
> > On Thursday 24 September 2009 01:01:58 you wrote:
> >
> > No problem. I'll be happy to get anything working!
> >
> > Following your advice, it seems to work perfectly now:
>
> I'm not too familiar with concurrency in ocaml.
On Thursday 24 September 2009 10:49:43 Richard Jones wrote:
> On Thu, Sep 24, 2009 at 02:47:17AM +0100, Jon Harrop wrote:
> > Wow! 2.6x faster on 2 cores is good. ;-)
>
> Isn't that impossible? Or is the multicore GC better than the single
> threaded one? (Sorry if this is a stupid or obvious que
Richard Jones schrieb:
> On Thu, Sep 24, 2009 at 02:47:17AM +0100, Jon Harrop wrote:
>> Wow! 2.6x faster on 2 cores is good. ;-)
>
> Isn't that impossible? Or is the multicore GC better than the single
> threaded one? (Sorry if this is a stupid or obvious question)
It might just happen that the
> On Thursday 24 September 2009 01:01:58 you wrote:
> No problem. I'll be happy to get anything working!
>
> Following your advice, it seems to work perfectly now:
I'm not too familiar with concurrency in ocaml.
How does OC4MC compare with JoCaml?
>
> $ ./matmul.th 500 1
> Temp de calcul: utime
> > Wow! 2.6x faster on 2 cores is good. ;-)
>
> Isn't that impossible? Or is the multicore GC better than the single
> threaded one? (Sorry if this is a stupid or obvious question)
There are so many factors that makes the running time unpredictable that
nothing is surprising any more. Haven't
On Thu, Sep 24, 2009 at 02:47:17AM +0100, Jon Harrop wrote:
> Wow! 2.6x faster on 2 cores is good. ;-)
Isn't that impossible? Or is the multicore GC better than the single
threaded one? (Sorry if this is a stupid or obvious question)
Rich.
--
Richard Jones
Red Hat
___
On Thursday 24 September 2009 01:01:58 you wrote:
> Ok... well, I guess that
> - whether it is something about your environment that is too different
> from ours (in which case build.sh is bad),
> - whether you have corrupted your installation (it could be by having
> a bad PATH value that makes or
Ok... well, I guess that
- whether it is something about your environment that is too different
from ours (in which case build.sh is bad),
- whether you have corrupted your installation (it could be by having
a bad PATH value that makes original ocamlopt be mixed up with oc4mc
ocamlopt)
What I su
On Thursday 24 September 2009 00:15:14 you wrote:
> make program.nc uses original ocamlopt
>
> make program.th uses the newly built ocamlopt with the necessary
> options (lib links)
>
> then you can compare program.nc and program.th
Aha! Progress, but now I get errors:
$ make matmul.th
../out/bin
make program.nc uses original ocamlopt
make program.th uses the newly built ocamlopt with the necessary
options (lib links)
then you can compare program.nc and program.th
On Thu, Sep 24, 2009 at 2:21 AM, Jon Harrop wrote:
> On Wednesday 23 September 2009 11:53:09 Goswin von Brederlow wrote:
>>
On Wednesday 23 September 2009 11:53:09 Goswin von Brederlow wrote:
> Has anyone tested this yet? Any success stories?
Well, I've used the build.sh script to build a patched OCaml 3.10.2 that
identifies itself as:
$ ocamlopt -v
The Objective Caml native-code compiler, version
3.10.2+patch-ocaml
I've updated the download page, it should be more robust to multiple
downloads now.
Cheers,
Philippe Wang
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Begin
On Wednesday 23 September 2009 13:21:35 Jon Harrop wrote:
> On Wednesday 23 September 2009 11:53:09 Goswin von Brederlow wrote:
> > Has anyone tested this yet? Any success stories?
>
> Its compiling. :-)
Oops, I just compiled a vanilla OCaml 3.10 and their patch is not currently
downloadable. I a
On Wednesday 23 September 2009 11:53:09 Goswin von Brederlow wrote:
> Has anyone tested this yet? Any success stories?
Its compiling. :-)
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Caml-list mailing list. Subscr
Philippe Wang writes:
> This is some additional "noise" about "OCaml for Multicore
> architectures" (or "Ok with parallel threads GC").
>
>
> Dear list,
>
> We have implemented an alternative runtime library for OCaml, one that
> allows threads to compute in parallel
This is some additional "noise" about "OCaml for Multicore
architectures" (or "Ok with parallel threads GC").
Dear list,
We have implemented an alternative runtime library for OCaml, one that
allows threads to compute in parallel on different cores of now
wides
64 matches
Mail list logo
