What about the standard library being single-threaded? How hard will it be
to adjust it for multiple threads, will OCaml maintainers even agree to such
adjustments and how will this affect performance?
On Mon, Sep 22, 2008 at 10:03 PM, Jon Harrop <
[EMAIL PROTECTED]> wrote:
> On Monday 22 Septemb
On Mon, 2008-09-22 at 20:03 +0100, Jon Harrop wrote:
> Sure thing. I wrote to the guys doing this work a couple of times and they
> were very friendly. Apparently they are currently ironing out the last of the
> bugs before going public.
>
> I don't think I am the only person struggling to conta
On Monday 22 September 2008 08:51:03 Alan Schmitt wrote:
> On 21 sept. 08, at 23:41, Jon Harrop wrote:
> > The good news is that the parallel GC is coming along nicely and
> > this will be a solved problem before long... :-)
>
> I'd love to hear more about this. Could you develop?
Sure thing. I wr
On 21 sept. 08, at 23:41, Jon Harrop wrote:
The good news is that the parallel GC is coming along nicely and
this will be
a solved problem before long... :-)
I'd love to hear more about this. Could you develop?
Alan
PGP.sig
Description: This is a digitally signed message part
On Sunday 21 September 2008 20:05:15 Michaël Grünewald wrote:
> This is true while your are concerned with matrix over the real or
> complex numbers, but if you want to use arbitrary precision arithmetic,
> finite fields, quaternions or any ring you like, then you are stuck.
> Linear algebra is use
Richard Jones wrote:
If you also follow the rest of that thread, there's a message passing
OCaml version by Gerd Stolpmann which also scales properly.
To be honest, matrix multiplication interests me not at all since no
one is hand coding their own matrix multiplication when there are
perfectly
If you also follow the rest of that thread, there's a message passing
OCaml version by Gerd Stolpmann which also scales properly.
To be honest, matrix multiplication interests me not at all since no
one is hand coding their own matrix multiplication when there are
perfectly good, parallel librarie
Zitat von Kuba Ober <[EMAIL PROTECTED]>:
[...]
> If you count the "efficiency" of such out-of-the-blue uncached truly
> random
> access in terms of clock cycles, current hardware may be 1-2 orders
> of
> magnitude less efficient than almost any 8-bit microcontroller out
> there...
> On most MCUs yo
Zitat von J C <[EMAIL PROTECTED]>:
> On Fri, Jul 11, 2008 at 5:23 PM, Oliver Bandel
> <[EMAIL PROTECTED]> wrote:
>
> > For example, if you have a non-profit research project,
> > you can use the BOINC infrastructure, which provides
> > about 58 PCs to help you :)
> >
> >
>
http://en.wikipedia.
> > It is a stop-gap solution...
>
> That is not true. Many-core machines will always be decomposed into
> shared-memory clusters of as many cores as possible because shared memory
> parallelism will always be orders of magnitude more efficient than
> distributed parallelism.
The way "shared memor
On Monday 14 July 2008 18:04:01 Mike Lin wrote:
> Incidentally, it occurs to me that when one is optimizing the kind of tight
> numerical loops that can really benefit from shared memory, the FIRST step,
> before parallelizing, is to do away with any heap allocations in the loop.
> The following is
On Mon, Jul 14, 2008 at 01:08:23PM +0100, Jon Harrop wrote:
> I believe you are correct. Moreover, I suspect that adding support for OpenMP
> to OCaml would be difficult because the current OCaml implementation is
> thread unsafe.
OpenMP isn't your typical library. It's a set of wierd preproces
On Mon, Jul 14, 2008 at 8:08 AM, Jon Harrop <[EMAIL PROTECTED]> wrote:
>
> Perhaps the parallel GC could enable support for things like OpenMP but I
> personally would rather see a shift to similar functionality to that of
> Microsoft's TPL because (I assume) it is better for parallel tree
> opera
On Monday 14 July 2008 12:32:53 J C wrote:
> On Thu, Jul 10, 2008 at 4:35 AM, Jon Harrop <[EMAIL PROTECTED]> wrote:
> > OCaml already has OS native threads (albeit with a global lock), already
> > supports OpenMP and can already be used to write parallel programs that
> > exploit multiple cores.
>
On Thu, Jul 10, 2008 at 4:35 AM, Jon Harrop <[EMAIL PROTECTED]> wrote:
> OCaml already has OS native threads (albeit with a global lock), already
> supports OpenMP and can already be used to write parallel programs that
> exploit multiple cores.
>
> ...
> Incidentally, MP is good for distributed p
On Fri, Jul 11, 2008 at 5:23 PM, Oliver Bandel
<[EMAIL PROTECTED]> wrote:
> For example, if you have a non-profit research project,
> you can use the BOINC infrastructure, which provides
> about 58 PCs to help you :)
>
> http://en.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Com
On Fri, Jul 11, 2008 at 7:06 AM, Xavier Leroy <[EMAIL PROTECTED]> wrote:
> Look at GPUs, which are the closest we have
> today to a manycore system: 128 cores are available today, more is
> in preparation, but the programming model is definitely not SMP.
I was reading an article about CUDA writte
On Fri, 11 Jul 2008, Gerd Stolpmann wrote:
Well, it is an open question whether this alternative holds. I mean
there is a market, and if the market says, "no we don't need that
multicore monsters", the chip companies cannot simply ignore it.
You're still assuming the chip companies *have a c
Zitat von Peng Zang <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thursday 10 July 2008 11:01:31 pm Brian Hurt wrote:
> > On Thu, 10 Jul 2008, Gerd Stolpmann wrote:
> > > I wouldn't take this article too seriously. It's just
> speculation.
> >
> > I would take the a
> CLR & JVM running easily on 1024 cores, this I gotta see!
not ideal but apparently (i don't work for them and have never used
them) if you stick to (unfortunately proprietary $ystem$ like) Azul,
you can get up to 864 cores.
___
Caml-list mailing list.
>[...] There are good reasons to think that the
>illusion of shared memory cannot be maintained in the presence of
>hundreds of computing elements, even using cc-NUMA techniques
>(i.e. hardware emulation of shared memory on top of high-speed
>point-to-point links).
I'm not arguing any of your poin
On Fri, Jul 11, 2008 at 02:43:53PM +0100, Jon Harrop wrote:
> On Friday 11 July 2008 14:01:45 Gerd Stolpmann wrote:
> > In the past, it was very important for hardware vendors that existing
> > software runs quicker on new CPU generations. This is no longer true for
> > multicore. So unless there i
On Friday 11 July 2008 15:03:48 Basile STARYNKEVITCH wrote:
> As a case in point, I suggest an experiment (which unfortunately I don't
> have the time or motivation to realize). Replace the current Ocaml GC
> either in bytecode or in nativecode ocaml by Boehm's collector (which is
> multithread com
On Fri, 2008-07-11 at 16:06 +0200, Xavier Leroy wrote:
. . .
> The interesting question that this community should focus on
> (rather than throwing fits about concurrent GC and the like) is coming
> up with good programming models for parallelism. I'm quite fond of
> message passing myself, but
Zitat von Xavier Leroy <[EMAIL PROTECTED]>:
[...]
> The interesting question that this community should focus on
> (rather than throwing fits about concurrent GC and the like) is
> coming
> up with good programming models for parallelism.
OK, I agree, but parallel programming is not really new.
It
On Friday 11 July 2008 15:03:48 Basile STARYNKEVITCH wrote:
> It is not specific to Linux (and probably not even to *opensource*
> functional programming languages; I believe proprietary functional
> languages implementations face the same problems).
Indeed, Mathematica has the same problem but, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 10 July 2008 11:01:31 pm Brian Hurt wrote:
> On Thu, 10 Jul 2008, Gerd Stolpmann wrote:
> > I wouldn't take this article too seriously. It's just speculation.
>
> I would take the article seriously.
>
> > Just open up your mind to this pers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 10 July 2008 10:00:02 am Jon Harrop wrote:
> Today's biggest shared-memory supercomputers already have thousands of
> cores.
>
> > Also, this is a CNET article.. not exactly known for being in depth or
> > well researched and this article i
J C wrote:
> I know that Caml team wanted to see if many-core shared-memory systems
> were going to stick around before bothering with Caml development that
> takes advantage of them.
> Well, it looks like they are here to stay, after all:
> http://news.cnet.com/8301-13924_3-9981760-64.html
As oth
Jon Harrop wrote:
Ironically, given the hype surrounding functional programming for parallelism,
all open source FPLs were left behind. On Linux, even the future prospects
are bleak: no tail calls on the JVM, prohibitively difficult to implement an
efficient concurrent GC yourself and Mono is
On Friday 11 July 2008 14:01:45 Gerd Stolpmann wrote:
> In the past, it was very important for hardware vendors that existing
> software runs quicker on new CPU generations. This is no longer true for
> multicore. So unless there is a software revolution that makes it simple
> to exploit multicore,
Am Donnerstag, den 10.07.2008, 23:01 -0400 schrieb Brian Hurt:
>
> On Thu, 10 Jul 2008, Gerd Stolpmann wrote:
>
> >
> > I wouldn't take this article too seriously. It's just speculation.
>
> I would take the article seriously.
>
> > Just open up your mind to this perspective: It's a big risk f
On Thu, 10 Jul 2008, Gerd Stolpmann wrote:
I wouldn't take this article too seriously. It's just speculation.
I would take the article seriously.
Just open up your mind to this perspective: It's a big risk for the CPU
vendors to haven taken the direction to multi-core.
*Precisely*. It
Hello Jon,
Zitat von Oliver Bandel <[EMAIL PROTECTED]>:
[...]
> And a question to the message passing: which message passing
> technique
> from Ocaml did you use?
[...]
Oh, sorry, I read your mail again and saw that you talked about
Richards OCaml implementation.
I googled for some keyords and
Zitat von Oliver Bandel <[EMAIL PROTECTED]>:
[...]
> There are better architectures. Some DSPs had made more
> instructions per second with some hundred MHz than some GHz-Intel
> CPU's,
> becuase if you only need one cycle to load (more than none) new
... (more then ONE) ...
___
Zitat von Jon Harrop <[EMAIL PROTECTED]>:
> On Thursday 10 July 2008 23:25:36 you wrote:
> > On Thu, Jul 10, 2008 at 03:00:02PM +0100, Jon Harrop wrote:
> > > OCaml is already ~8x slower than F# on today's eight core
> desktops.
> >
> > You don't half talk a load of nonsense. MPI OCaml programs o
Zitat von Gerd Stolpmann <[EMAIL PROTECTED]>:
>
> Am Mittwoch, den 09.07.2008, 22:57 -0700 schrieb J C:
> > I know that Caml team wanted to see if many-core shared-memory
> systems
> > were going to stick around before bothering with Caml development
> that
> > takes advantage of them.
> >
> > Wel
On Thursday 10 July 2008 23:25:36 you wrote:
> On Thu, Jul 10, 2008 at 03:00:02PM +0100, Jon Harrop wrote:
> > OCaml is already ~8x slower than F# on today's eight core desktops.
>
> You don't half talk a load of nonsense. MPI OCaml programs on 8 cores
> are just as fast...
You may recall that we
On Thu, Jul 10, 2008 at 03:00:02PM +0100, Jon Harrop wrote:
> Today's biggest shared-memory supercomputers already have thousands of cores.
Distributed shared memory perhaps, but thousand core machines are
certainly not UMA SMP. It's simply not possible for them to be.
> OCaml is already ~8x slo
Am Mittwoch, den 09.07.2008, 22:57 -0700 schrieb J C:
> I know that Caml team wanted to see if many-core shared-memory systems
> were going to stick around before bothering with Caml development that
> takes advantage of them.
>
> Well, it looks like they are here to stay, after all:
>
> http://
On Thursday 10 July 2008 14:44:25 Peng Zang wrote:
> On Thursday 10 July 2008 01:57:44 am J C wrote:
> > I know that Caml team wanted to see if many-core shared-memory systems
> > were going to stick around before bothering with Caml development that
> > takes advantage of them.
> >
> > Well, it lo
On Thu, Jul 10, 2008 at 8:47 AM, Oliver Bandel
<[EMAIL PROTECTED]> wrote:
> Is JoCaml somehow related to Camlp3l?
Camlp3l is a set of libraries and helper tools which are written in
OCaml. It is not tied to a particular OCaml release.
JoCaml provides a separate compiler and runtime. It is, at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 10 July 2008 01:57:44 am J C wrote:
> I know that Caml team wanted to see if many-core shared-memory systems
> were going to stick around before bothering with Caml development that
> takes advantage of them.
>
> Well, it looks like they a
On Thursday 10 July 2008 06:57:44 J C wrote:
> ...many-core shared-memory systems...OpenMP-style primitives...
Incidentally, MP is good for distributed parallelism but fails to take
advantage of shared memory (with a concurrent GC).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ff
Hello,
Zitat von Erik de Castro Lopo <[EMAIL PROTECTED]>:
]...]
>
> Not exactly OpenMP, but see
>
>JoCaml : http://jocaml.inria.fr/
>CoThreads : http://cothreads.sf.net/
[...]
Is JoCaml somehow related to Camlp3l?
Ciao,
Oliver
___
Caml-l
On Thursday 10 July 2008 06:57:44 J C wrote:
> As much as I hate to look a gift horse in the mouth, and I think Caml
> has been a great and grossly underappreciated product, I need to see
> if writing Caml is a viable code investment for the coming years or
> something like Haskell, SML, F# or even
J C wrote:
> As much as I hate to look a gift horse in the mouth, and I think Caml
> has been a great and grossly underappreciated product,
Agreed.
> I need to see
> if writing Caml is a viable code investment for the coming years or
> something like Haskell,
I think Haskell's STM is way overhy
I know that Caml team wanted to see if many-core shared-memory systems
were going to stick around before bothering with Caml development that
takes advantage of them.
Well, it looks like they are here to stay, after all:
http://news.cnet.com/8301-13924_3-9981760-64.html
As much as I hate to look
48 matches
Mail list logo