On Sat, May 1, 2010 at 2:21 PM, Tim E. Real <[email protected]> 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: See http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0609/rW_CS_FunctionalProgramming.pdfas good intro. > 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 http://elhumidor.blogspot.com/2009/04/clojure-on-google-appengine.html which says: 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. http://nielsmayer.com
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
