Parallel Shreds

Eric Hedekar

27 Jan 2009 27 Jan '09

9:50 p.m.

Hi, I'm just curious as to how parallel chuck's processing actually is? I've read in the ICMC2003 paper that "ChucK is a concurrent language, which allows multiple independent paths of computation to be executed in parallel." That implies (to my ear anyway) that ChucK allows each shred to run on it's own processor core in a multi-core processor. Is this the case, or is it merely an 'illusion of parallelism' whereby the parallel processing is merely a higher-level construct of shreds advancing time on their own accord in the VM? Any info would be greatly appreciated. Thanks. -Eric Hedekar -- _______________________________________ http://greyrockstudio.blogspot.com

Attachments:

attachment.html (text/html — 833 bytes)

Show replies by date

Spencer Salazar

27 Jan 27 Jan

11:18 p.m.

In fact, the VM is single-threaded. Shreds are multi-tasked cooperatively, in that only a single shred is running at a time in a given chuck instance, and that a shred is not interrupted by another shred until the current shred specifically allows it (by me.yield() or => now). Additionally, audio is only generated when no shreds are running (e.g. when all shreds are concurrently chucking something => now). I think in 2003 parallel was still generally accepted to mean "running sequentially within the same approximate slice of time" :D , before development/marketing of consumer multi-core architectures really picked up. spencer On Jan 27, 2009, at 6:50 PM, Eric Hedekar wrote:

...

Hi, I'm just curious as to how parallel chuck's processing actually is? I've read in the ICMC2003 paper that "ChucK is a concurrent language, which allows multiple independent paths of computation to be executed in parallel." That implies (to my ear anyway) that ChucK allows each shred to run on it's own processor core in a multi-core processor. Is this the case, or is it merely an 'illusion of parallelism' whereby the parallel processing is merely a higher- level construct of shreds advancing time on their own accord in the VM? Any info would be greatly appreciated. Thanks.

-Eric Hedekar

-- _______________________________________ http://greyrockstudio.blogspot.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Stephen Sinclair

28 Jan 28 Jan

12:11 p.m.

On Tue, Jan 27, 2009 at 9:50 PM, Eric Hedekar wrote:

...

Hi, I'm just curious as to how parallel chuck's processing actually is? I've read in the ICMC2003 paper that "ChucK is a concurrent language, which allows multiple independent paths of computation to be executed in parallel." That implies (to my ear anyway) that ChucK allows each shred to run on it's own processor core in a multi-core processor. Is this the case, or is it merely an 'illusion of parallelism' whereby the parallel processing is merely a higher-level construct of shreds advancing time on their own accord in the VM? Any info would be greatly appreciated. Thanks.

It's parallel, but not concurrent. Parallel is a semantic thing -- it's not an "illusion" though I guess you could call it that. It allows you to reason about audio processing routines that execute in parallel in terms of ChucK's logical timeline. However, they don't run in separate operating system threads, which would be "concurrent". If you really need to do such a thing, you could use OSC for synchronization and run two instances of ChucK, but at the moment it won't split things into different CPUs for you automatically. Steve

Tom Duff

11:43 p.m.

On Wed, 28 Jan 2009, Stephen Sinclair wrote:

...

It's parallel, but not concurrent. ... However, they don't run in separate operating system threads, which would be "concurrent".

Standard terminology in CS is more or less the reverse. "Concurrent" means apparently happening at the same time, "parallel" means executing on more than one CPU. Multi-threaded programs are concurrent, but they're only parallel if they're running on more than one core. Of course, these things can change. "Core" used to mean RAM. Now it means CPU. -- Tom Duff. PLEASE GO ON.

Eric Hedekar

29 Jan 29 Jan

12:10 a.m.

...

On Wed, 28 Jan 2009, Stephen Sinclair wrote:

...
It's parallel, but not concurrent. ... However, they don't run in separate operating system threads, which would be "concurrent".

Are there any efforts being made to make the VM parallel (or as you might say, concurrent)? It seems like that's the future of programming models, and seeing as ChucK is hardly a lightweight in computing resources.... or is garbage collection a higher priority for the dev team? -Eric -- _______________________________________ http://greyrockstudio.blogspot.com

Ge Wang

12:50 a.m.

Greetings!

...

Are there any efforts being made to make the VM parallel (or as you might say, concurrent)? It seems like that's the future of programming models, and seeing as ChucK is hardly a lightweight in computing resources.... or is garbage collection a higher priority for the dev team?

We are certainly interested in taking advantage of many-core CPU's, but no current effort is yet being made. I think this challenge is there for many, if not most, systems today. Perhaps new low-level programming paradigms (e.g., for imperative languages at the C/C++/assembler level) have to be deployed before these systems can truly be parallelized. For example, Apple's next OS X release, "Snow Leopard", will apparently offer concurrent language primitives ("blocks") which the kernel can then efficiently farm out to cores - additionally the OS abstracts the number of actual cores so programmers don't always need to take this into account. Not sure yet how well things like this will work in practice, but this seems like a start. In short, it's hard problem, and I think for many systems, it may need to be addressed in the form of new language primitives + OS support. Ge!

Stephen Sinclair

9:50 a.m.

On Wed, Jan 28, 2009 at 11:43 PM, Tom Duff wrote:

...

On Wed, 28 Jan 2009, Stephen Sinclair wrote:

...
It's parallel, but not concurrent. ... However, they don't run in separate operating system threads, which would be "concurrent".

Standard terminology in CS is more or less the reverse. "Concurrent" means apparently happening at the same time, "parallel" means executing on more than one CPU. Multi-threaded programs are concurrent, but they're only parallel if they're running on more than one core.

Sorry, my bad, maybe it is the other way around. I think a big challenge for running shreds in parallel will be dealing with memory issues. Right now it's a big advantage that you can access global variables and things within shreds without worrying about clobbering other shreds, but this would be a problem with true concurrency. Perhaps the best solution would be transactional memory, but it's quite hard to implement from what I understand. Steve

Rogan Carr

12:35 p.m.

I'm going to throw my 2¢ behind Ge. I've done some parallel programming, and I don't think this is the route we want to go. The Mac OS "blocks" sound like what most of the CS parallel people have been talking about how the next wave of parallel computers will be programmed. It might be a few years, but I think waiting for language primitives (a fortran-like forall loop, for example) and OS support is the way to go. Rogan On Thu, Jan 29, 2009 at 8:50 AM, Stephen Sinclair wrote:

...

On Wed, Jan 28, 2009 at 11:43 PM, Tom Duff wrote:

...
On Wed, 28 Jan 2009, Stephen Sinclair wrote:

...
It's parallel, but not concurrent. ... However, they don't run in separate operating system threads, which would be "concurrent".

Standard terminology in CS is more or less the reverse. "Concurrent" means apparently happening at the same time, "parallel" means executing on more than one CPU. Multi-threaded programs are concurrent, but they're only parallel if they're running on more than one core.

Sorry, my bad, maybe it is the other way around.

I think a big challenge for running shreds in parallel will be dealing with memory issues. Right now it's a big advantage that you can access global variables and things within shreds without worrying about clobbering other shreds, but this would be a problem with true concurrency. Perhaps the best solution would be transactional memory, but it's quite hard to implement from what I understand.

Steve _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

5768

Age (days ago)

5769

Last active (days ago)

List overview

Download

7 comments

6 participants

participants (6)

Eric Hedekar
Ge Wang
Rogan Carr
Spencer Salazar
Stephen Sinclair
Tom Duff

Parallel Shreds

Eric Hedekar

Spencer Salazar

Stephen Sinclair

Tom Duff

Eric Hedekar

Ge Wang

Stephen Sinclair

Rogan Carr

tags

participants (6)