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
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 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
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 you
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 communication
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 that
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
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 for you to
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 will
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
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 why
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
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 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
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
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
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
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 see
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
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
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 me
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
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 etc
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
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 said that.
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 it is
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 some
27 matches
Mail list logo
