On Sat, May 1, 2010 at 2:21 PM, Tim E. Real <termtech@rogers.com> wrote:
I've always wondered why they don't make a fixed-point co-processor...
That's what the three other 3.4G cores are for... or should be, in a more ideal world.
It's too bad people don't write programs that can automatically decompose into a parallel-execution (e.g. multithread) solution. Today's talk on using continuation-passing style in scheme was a step in the right direction (
http://lac.linuxaudio.org/2010/download/kjetil.pdf ) -- "Implementing a Polyphonic MIDI Software Synthesizer using Coroutines, Realtime Garbage Collection, Closures, Auto-Allocated Variables, Dynamic Scoping, and Continuation Passing Style Programming" Kjetil Matheussen. [[plug:
http://mitpress.mit.edu/sicm/book.html -- Structure and Interpretation of Classical Mechanics ]]
Speaking of java, all these concepts should be "cloudified" -- figure out a way to get google app engine to make a "cloudsynth" (of course, it should integrate qmidinet so as to setup midi routing appropriately). Maybe using clojure -- since it's basically lisp in java, with attention paid to parallel programing. And since underlying clojure is java, you get the standardized and widely-used/debugged java.math libs such as arbitrary precision arithmetic, so you can mix and remix to your hearts' content without bit-loss... of course, if a mix itself was a closure, then there'd be no bit-loss, or copying, since everything would just be a computation upon an original, prior, sound source. (You'll be able to 'unmix' any sound -- kind of like an infinite "mix" undo -- and like self-describing data, a "self describing mix")....
For more info on clojure and functional programming:
The Promises of Functional Programming
By Konrad Hinsen
Adopting a functional programming style could make your programs more robust, more compact, and more
easily parallelizable. However, mastering it requires some effort.
Wondering whether Google App Engine would be able to host such an application, I check
THE BIG CAVEAT
Two unusual aspects of the Google AppEngine environment create pretty major constraints on your ability to write idiomatic Clojure.
First, an AppEngine application runs in a security context that doesn't permit spawning threads, so you won't be able to use Agents, the clojure.parallel library, or Futures.
Second, one of the most exciting features of AppEngine is that your application will be deployed on Google's huge infrastructure, dynamically changing its footprint depending on demand. That means you'll potentially be running on many JVMs at once. Unfortunately this is a strange fit for Clojure's concurrency features, which are most useful when you have precise control over what lives on what JVM (and simplest when everything runs on one JVM). Since shared references (Vars, Refs, and Atoms) are shared only within a single JVM, they are not suitable for many of their typical uses when running on AppEngine. You should still use Clojure's atomic references (and their associated means of modification) for any state that it makes sense to keep global per-JVM, since there may be multiple threads serving requests in one JVM. But remember JVMs will come and go during the lifetime of your application, so anything truly global should go in the Datastore or Memcache.
-- Niels.