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