Re: [q-lang-users] Executables and modules

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

Sean E. Russell wrote:
> 1) You knew some annoying person was bound to ask this, sooner or later: Dr. 
> Gräf, you chose to compile to bytecode; have you considered compiling to 
> native code, or to some other intermediate language that could be compiled to 
> native code?  

Yes, of course I have considered this, but there are some things in the 
language, especially the runtime special forms, which makes this 
difficult and I can't say what the actual speed improvements would be. 
The key here is to find an existing backend (maybe gcc) which already 
supports a lot of architectures and is suitable to handle the special 
requirements of Q; otherwise I'd end up having to support all those 
different architectures myself, a nightmare. That's one of the key 
points which speaks in favour of an interpreter: it's much easier to 
make it portable, at least nowadays where a decent C compiler is 
available for virtually every platform under the sun (no pun intended ;-).

> 	In addition to the two common reasons for wanting this -- speed and the 
> ability to make executables -- there is a third reason: interpreters add 
> another dependency failure point.  That is, yet one more dependency that 
> could change and cause an application to break.  In particular, interpreters 
> are often more brittle than other dependencies (like libc), since they tend 
> to change more radically and more often.

Well, leaving endianness and 64 bit issues aside (which would be pretty 
much the same, whether you have a bytecode compiler or a native compiler 
with associated runtime), the core of an interpreter is usually very 
portable anyway. In my experience, portability issues almost always 
arise in the addon libraries. (At least that's true now that we have C 
compilers+libraries adhering to a standard everywhere. It used to be a 
lot different in the "bad old days.")

Concerning the 2nd point (ability to make executables): We already have 
that, it's called qcwrap.

> 2) Exactly why is Q's speed so similar to Haskell's?  The consensus appears to 
> be that Haskell's lazy evaluation is (by and large) what kills it in 
> performance comparisons.  Q, however, is by default eager.  The interpreted 
> nature of Q (and evaluated Haskell) probably masks issues such as lazy/eager 
> performance issues, but any thoughts on this are welcome.

Don't forget static vs. dynamic typing. That's what gives both ML and 
Haskell a big edge in computation speed over more dynamic languages. 
Concerning lazy vs. eager, the performance issues with the former only 
become apparent when large intermediate terms have to be constructed. 
With simple tail-recursive definitions, even interpreted Haskell can be 
very fast, and then it may well be that lazy but unboxed evaluation is 
faster than an eager but boxed computation. OTOH, I found that with 
plain heavy-duty recursion on simple objects, such as the tak benchmark, 
the Q interpreter indeed is faster than Hugs; so it all depends on the 
type of benchmark.

Cheers,
Albert

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