Re: [q-lang-users] q in Q

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Well, there's a few approaches to that.  I presume a classical compiler
> to assembly language chain is out.  Then there's compilation to C,
> or compilation to something else (Chicken, e.g.) that compiles to C.
> Then there is compilation to some standard byte code set with JIT
> compilation in place, like the JVM or the CLR.  Any or all of these
> would probably make q-in-Q feasible.

Yes, we already discussed this here a while ago... Translating Q's 
bytecode would be the most straightforward approach. JIT compilation 
looks nice, but I'm also considering compilation to C or maybe Ksi (the 
latter approach would be tied to gcc, however). This is still a while 
away, though (I first want to resolve all the remaining portability 
issues and finish the Q companion book).

> Reference counting has its own costs, though, specifically the cost of
> recursive freeing, which is unpredictable in scope.

Yes, that's true. But in my experience it seems to work well enough for 
soft-realtime apps even on slower PCs (especially the computer music 
applications wouldn't work at all if this wasn't the case; there you can 
hear timing glitches quite easily). Doing low-latency audio stuff is 
more demanding, of course, but there are other, more specialized audio 
engines like SuperCollider for that, which can be controlled from Q via OSC.

> Q has a global interpreter lock, right?  So all threads except one have
> to be running C code, but which one it is can change.

Yes, that's right. That global mutex will probably have to go before we 
all run computers with 1024 cpus. ;-) But right now this implementation 
seems to work pretty well and also makes the job for the external module 
writer much simpler.

> The whole idea probably isn't practical.

:(

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag