2 May
2010
2 May
'10
12:20 a.m.
On Sat, May 1, 2010 at 2:21 PM, Tim E. Real <termtech(a)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:
See
http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0609/r…
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