On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote:
On 11/29/2010 04:33 PM, Oliver Bandel wrote:
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
You use shared
On Tue, Nov 30, 2010 at 2:55 PM, oli...@first.in-berlin.de wrote:
(A thread-specific GC for thread-specific variables would help here,
making global locks only necessary when accessing global used variables.
But I don't know if such a way would be possible without changing the
GC-stuff
On 11/30/2010 12:55 PM, oli...@first.in-berlin.de wrote:
There is one problem with this... when you have forked, then
you obviously have separated processes and also in each process
your own ocaml-program with it's own GC running...
...neatly sidestepping the problem that the GC needs to lock
Am Dienstag, den 30.11.2010, 13:55 +0100 schrieb
oli...@first.in-berlin.de:
On Tue, Nov 30, 2010 at 09:10:36AM +0100, Stephan Houben wrote:
On 11/29/2010 04:33 PM, Oliver Bandel wrote:
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver
Am Dienstag, den 30.11.2010, 15:04 +0100 schrieb Stephan Houben:
On 11/30/2010 12:55 PM, oli...@first.in-berlin.de wrote:
There is one problem with this... when you have forked, then
you obviously have separated processes and also in each process
your own ocaml-program with it's own GC
On Tue, Nov 30, 2010 at 03:04:32PM +0100, Stephan Houben wrote:
On 11/30/2010 12:55 PM, oli...@first.in-berlin.de wrote:
There is one problem with this... when you have forked, then
you obviously have separated processes and also in each process
your own ocaml-program with it's own GC
On Tue, Nov 30, 2010 at 4:29 PM, oli...@first.in-berlin.de wrote:
And here I see a thread-specific GC as a solution.
It seems to me that this way was not thought about before,
and people thought about changing the GC to be able to handle multiple
threads.
Instead I mean: each thread that is
On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
I don't think this is the reason. Many people can ignore Windows,
actually.
The problem is more that your whole program needs then to be
restructured - multi-processing implies a process model (which is the
master, which are the workers). With
Am Dienstag, den 30.11.2010, 16:30 +0100 schrieb Stephan Houben:
On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
I don't think this is the reason. Many people can ignore Windows,
actually.
The problem is more that your whole program needs then to be
restructured - multi-processing implies
On Tue, Nov 30, 2010 at 05:07:31PM +0100, Gerd Stolpmann wrote:
Am Dienstag, den 30.11.2010, 16:30 +0100 schrieb Stephan Houben:
On 11/30/2010 02:22 PM, Gerd Stolpmann wrote:
I don't think this is the reason. Many people can ignore Windows,
actually.
The problem is more that your
What would be responsible for collecting the shared heap?
Cheers,
Jon.
Eray wrote:
Seconded, why is this not possible? That is to say, why cannot each thread
maintain a separate GC,
if so desired?
___
Caml-list mailing list. Subscription
November 2010 07:33
To: oli...@first.in-berlin.de
Cc: Caml List
Subject: Re: [Caml-list] Re: Is OCaml fast?
Le 28/11/2010 19:17, oli...@first.in-berlin.de a écrit :
On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote:
Hello,
To the extent that this rule is the same
-list-
boun...@yquem.inria.fr] On Behalf Of Christophe Raffalli
Sent: 29 November 2010 07:33
To: oli...@first.in-berlin.de
Cc: Caml List
Subject: Re: [Caml-list] Re: Is OCaml fast?
Le 28/11/2010 19:17, oli...@first.in-berlin.de a écrit :
On Sat, Nov 27, 2010 at 04:58:55PM +0100
Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oli...@first.in-berlin.de:
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
[...]
The main problem was that other languages have bigger standard
libraries, whereas OCaml has a very small one (just what is needed
to compile
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oli...@first.in-berlin.de:
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
[...]
The main problem was that other languages have bigger standard
libraries, whereas OCaml has a
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oli...@first.in-berlin.de:
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
[...]
The main problem was
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
Am Montag, den 29.11.2010, 17:12 +0100 schrieb Oliver Bandel:
Zitat von Gerd Stolpmann i...@gerd-stolpmann.de:
Am Sonntag, den 28.11.2010, 19:14 +0100 schrieb
oli...@first.in-berlin.de:
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote:
[...]
The main problem was that other languages have bigger standard
libraries, whereas OCaml has a very small one (just what is needed
to compile the compiler, actually). In many problems, you could
benefit from using a very
On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote:
Hello,
To the extent that this rule is the same for all languages and that most
languages on the shootout are also garbage collected, I think OCaml's
problem with this benchmark do point at a weakness of the current
GC
Le 28/11/2010 19:17, oli...@first.in-berlin.de a écrit :
On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote:
Hello,
To the extent that this rule is the same for all languages and that most
languages on the shootout are also garbage collected, I think OCaml's
problem with this
Hello,
To the extent that this rule is the same for all languages and that most
languages on the shootout are also garbage collected, I think OCaml's
problem with this benchmark do point at a weakness of the current
GC code.
This is untrue ... the bintree example, is just bad in OCaml because
On 11/25/2010 11:12 PM, Jon Harrop wrote:
Stefan wrote:
I think OCaml's problem with this benchmark do point at a weakness of the
current
GC code.
What makes you think that ?
I have contributed to some of the solutions that you can find there (and
some other ones were rejected because
On Wed, 24 Nov 2010 06:50:15 +, Isaac Gouy wrote:
Jeff Meister nanaki at gmail.com writes:
We know what your rules are for binary-trees; repeating them does
not help.
When Christophe TROESTLER wrongly states - OCaml is not authorized
to make use of its very own library! - he shows
On Wed, Nov 24, 2010 at 12:24 PM, Christophe Troestler
christophe.troestler+oc...@umh.ac.bechristophe.troestler%2boc...@umh.ac.be
wrote:
On Wed, 24 Nov 2010 06:50:15 +, Isaac Gouy wrote:
Jeff Meister nanaki at gmail.com writes:
We know what your rules are for binary-trees;
Hello,
Here is a test of gctweak.ml on the now famous binary-tree shootout bench ...
As you can see it is a 30% speed up which is not too bad, just adding
a file on the compilation command line !
I reattached the file, because I correct a few comments in it ... and a syntax
error
that is only
Hey, guys.
Time to stop this, please.
Thanks,
David
On Nov 24, 2010, at 8:13 PM, Isaac Gouy wrote:
Ed Keith e_d_k at yahoo.com writes:
I am not asking WHAT the rules are but a JUSTIFICATION
for them (which you
have been incapable of providing so far).
I feel no need to provide a
Isaac Gouy wrote:
David Allsopp dra-news at metastack.com writes:
-snip-
Reducing an entire programming language's strengths (or
weaknesses!) to a single number is just not really realistic - the
truth is more complex than one single-precision floating point
number (or even an array
Gerd Stolpmann i...@gerd-stolpmann.de writes:
Am Dienstag, den 23.11.2010, 17:53 + schrieb Isaac Gouy:
Christophe TROESTLER Christophe.Troestler+ocaml at umh.ac.be writes:
On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
C version : 12.11 secs
OCaml version : 47.22
Maybe you should read Tainted Truth: The Manipulation of Fact In
America by Cynthia Crossen ?
--Fabrice
Isaac Gouy wrote, On 11/23/2010 03:20 AM:
Dario Teixeira darioteixeira at yahoo.com writes:
-snip-
There's lies, damn lies, and shootout statistics.
-snip-
After all, facts are facts,
Sent: 23 November 2010 10:38
To: igo...@yahoo.com
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Re: Is OCaml fast?
On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
C version : 12.11 secs
OCaml version : 47.22 secs
OCaml version with GC parameters tuned (interesting alternative
] On Behalf Of Christophe TROESTLER
Sent: 23 November 2010 10:38
To: igo...@yahoo.com
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Re: Is OCaml fast?
On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
C version : 12.11 secs
OCaml version : 47.22 secs
OCaml version with GC
On Tue, 23 Nov 2010 18:03:10 + (UTC)
Isaac Gouy igo...@yahoo.com wrote:
Jon Harrop jonathandeanharrop at googlemail.com writes:
Note that the regex-dna solution for Haskell tweaks its GC
parameters via the -H command-line parameter:
Note that there is no restriction on tuning
Am Dienstag, den 23.11.2010, 17:53 + schrieb Isaac Gouy:
Christophe TROESTLER Christophe.Troestler+ocaml at umh.ac.be writes:
On Tue, 23 Nov 2010 02:03:48 +, Isaac Gouy wrote:
C version : 12.11 secs
OCaml version : 47.22 secs
OCaml version with GC parameters tuned
Am Dienstag, den 23.11.2010, 20:28 + schrieb Isaac Gouy:
(It would be actually interesting to compare various versions of this test
with different memory management methods.)
So do that comparison and publish the results.
Please don't tell me what I am supposed to do. I'm not a troll
On Tue, 23 Nov 2010 17:53:14 +, Isaac Gouy wrote:
Christophe TROESTLER writes:
Since you are here, please explain why C can use memory pools and vec
tor instructions but tuning the GC of OCaml ― although it is part of
the standard library ― is considered an “alternative”.
Yes, an answer to a better question.
-Original Message-
From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
boun...@yquem.inria.fr] On Behalf Of Isaac Gouy
Sent: 23 November 2010 18:07
To: caml-l...@inria.fr
Subject: [Caml-list] Re: Is OCaml fast?
Jon Harrop
On Tue, Nov 23, 2010 at 06:03:10PM +, Isaac Gouy wrote:
Jon Harrop jonathandeanharrop at googlemail.com writes:
Note that the regex-dna solution for Haskell tweaks its GC parameters via
the -H command-line parameter:
Note that there is no restriction on tuning the GC for
On Tue, Nov 23, 2010 at 02:01:33AM +, Isaac Gouy wrote:
David Rajchenbach-Teller David.Teller at univ-orleans.fr writes:
I can confirm that old code-snippets were removed (and that both faster
solutions and environment
variable tweaks were rejected).
Even back in 2001, Doug
Hello,
I think that this benchmark is lacking in the algorithms department. Where
is a dynamic programming problem? A graph algorithm? Anything with
non-trivial time/space complexity? Anything a little more complex than
matrix product?
Also, it's not uncommon to disallow low-level optimizations
39 matches
Mail list logo
