Couple of thoughts/observations:
- Erlang has a vm, so that would avoid building a vm.
On the downside, erlang is not pure: the message-passing and the io:
commands imply the possibility of side-effects.
Still, it could be good enough for a proof-of-concept?
- implementation as a library functi
On Thu, Aug 23, 2007 at 06:27:43AM +0100, Hugh Perkins wrote:
> On 8/22/07, Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
> > Automatic threading is inherently limited by data dependencies.
> > You can't run a function that branches on an argument in parallel
> > with the computation producing t
On 8/22/07, Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
> Automatic threading is inherently limited by data dependencies.
> You can't run a function that branches on an argument in parallel
> with the computation producing that argument. Even with arbitrarily
> many processors and no communica
On 8/21/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
I highly doubt that automatic threading will happen any time this
decade
Hm. I happen to have an old Sun C compiler on my old UltraSPARC box.
cc -V => Sun Workshop 6 update 2 C 5.3 2001/05/15.
One of its options is '-xautopar'. I'll let yo
On Wed, Aug 22, 2007 at 04:07:22AM +0100, Hugh Perkins wrote:
> On 8/21/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> > I highly doubt that automatic threading will happen any time this decade
> > - but I just learned something worth while from reading this email. ;-)
>
> That's an interesting ob
> multicore box ;-) It's my main show-stopper right now. Any clues on
> how to get access to one, eg via ssh? 32-core or higher would be
> favorite ;-) but I guess even just a 4-core or so is enough for
> proof-of-concept?
I think you'll have plenty of work to be before you get to the stage
of
On 8/21/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> I highly doubt that automatic threading will happen any time this decade
> - but I just learned something worth while from reading this email. ;-)
>
That's an interesting observation. I cant say I dont believe it, but
I'm interested to know w
Tim Chevalier wrote:
Anyone can submit a paper to a CS journal or conference. While most
people who do so are affiliated with universities, research labs, or
(more rarely) non-research companies, there are independent
researchers out there, and sometimes you'll notice a paper where
someone is lis
On 8/21/07, Tim Chevalier <[EMAIL PROTECTED]> wrote:
> I don't think you have to worry too much about the political
> obstacles. People want automatic multithreading, and in a year or two
> we'll all have multicore boxen. In any case, if you don't solve the
> technical problems, the political ones
On 8/21/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:
> On 8/11/07, Neil Bartlett <[EMAIL PROTECTED]> wrote:
> > You're absolutely right that a dynamic/adaptive approach is the only
> > one that will work when the tasks are of unknown size. Whether this
> > approach is as easy as you think is open fo
On 8/11/07, Neil Bartlett <[EMAIL PROTECTED]> wrote:
> You're absolutely right that a dynamic/adaptive approach is the only
> one that will work when the tasks are of unknown size. Whether this
> approach is as easy as you think is open for you to prove. I look
> forward to testing your VM implemen
On Aug 13, 2007, at 2:53 PM, Mitar wrote:
Hi!
I am thinking about a model where you would have only n threads on a
n-core (or processor) machine. They would be your worker threads and
you would spawn them only once (at the beginning of the program) and
then just delegate work between them.
On
Hi!
I am thinking about a model where you would have only n threads on a
n-core (or processor) machine. They would be your worker threads and
you would spawn them only once (at the beginning of the program) and
then just delegate work between them.
On 8/13/07, Jan-Willem Maessen <[EMAIL PROTECTED
On Aug 11, 2007, at 12:35 PM, Brian Hurt wrote:
You guys might also want to take a look at the Cilk programming
language, and how it managed threads. If you know C, learning Cilk
is about 2 hours of work, as it's C with half a dozen extra
keywords and a few new concepts. I'd love to se
On Sat, 11 Aug 2007, Sebastian Sylvan wrote:
How is this any better than using "par" in Haskell?
Mainly how the threads are actually scheduled. Mind you, I'm an
*incredible* Haskell newbie, so take all of my comments with a 5-pound
salt block, but as I understand how the current implement
On 11/08/07, Brian Hurt <[EMAIL PROTECTED]> wrote:
>
> You guys might also want to take a look at the Cilk programming language,
> and how it managed threads. If you know C, learning Cilk is about 2 hours
> of work, as it's C with half a dozen extra keywords and a few new
> concepts. I'd love to
Brian Hurt wrote:
The key idea of Cilk is that it's easier to deparallelize than it is
to parallelize, especially automatically. So the idea is that the
program is written incredibly parallel, with huge numbers of
microthreads, which are (on average) very cheap to spawn. The runtime
then dep
You guys might also want to take a look at the Cilk programming language,
and how it managed threads. If you know C, learning Cilk is about 2 hours
of work, as it's C with half a dozen extra keywords and a few new
concepts. I'd love to see Cilk - C + Haskell as a programming language.
The
Hugh,
I certainly think it would be wrong to declare that NDP is doomed to
failure... not because you would be making an enemy of SPJ (I'm pretty
sure you wouldn't!) but because it actually aims to solves a less
ambitious problem: the problem of parallelising the SAME task applied
to different dat
On 8/11/07, Thomas Conway <[EMAIL PROTECTED]> wrote:
> There are many papers about this in the Parallel Logic Programming
> area. It is commonly called "Embarrassing Parallelism".
Ah, I wasnt very precise ;-) I didnt mean I dont understand the
problem; I meant I dont understand why people think i
On 8/11/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:
> > - parallelism must be quite coarse to offset overheads
> >(which I think is the problem with expecting things like map and fold
> > to parallelised automagically; they're just too small grained for it to
> > be worthwhile)
>
> Someone else
Hugh Perkins wrote:
- parallelism must be quite coarse to offset overheads
(which I think is the problem with expecting things like map
and fold
to parallelised automagically; they're just too small grained for
it to
be worthwhile)
Someone else said that. I dont und
On 8/10/07, Bayley, Alistair <[EMAIL PROTECTED]> wrote:
>
> Well, the Harris/Singh paper summarises the common problems:
> - not many programs are inherently parallel
If thats the case, then multicores are not going to be very useful. Where
there's a will there's a way.
What I think is: if maps
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Hugh Perkins
>
> Not many replies on this thread? Am I so wrong that no-one's
> even telling me? I find it hard to believe that if there
> were obvious errors in the proposition that anyone would
> resist pointing them out to
On Aug 10, 2007, at 9:31 AM, Hugh Perkins wrote:
Not many replies on this thread? Am I so wrong that no-one's even
telling me? I find it hard to believe that if there were obvious
errors in the proposition that anyone would resist pointing them
out to me ;-)
So, that leaves a couple of
Not many replies on this thread? Am I so wrong that no-one's even telling
me? I find it hard to believe that if there were obvious errors in the
proposition that anyone would resist pointing them out to me ;-)
So, that leaves a couple of possibilites: some people are agreeing, but see
no point i
On 8/10/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote:
>
> Perhaps have a look at this new paper:
>
> "Feedback directed implicit parallelism in Haskell"
> http://research.microsoft.com/~tharris/papers/2007-fdip.pdf
>
> -- Don
>
Ok interesting. So: it's a viable strategy, it's sortof
hughperkins:
>
>Haskell/FP seems to have solved the hardest bit of
>threading, which is making it obvious which bits of a
>program are parallelizable, and which are not.
>Remains to actually parallelize out the programs. Am I
>being naive or is this trivial?
>Is there som
28 matches
Mail list logo
