Michael Gogins wrote:
> 
> Another misconception: these days, Java IS fast. I do all my new DSP coding
> in Java. Java with best compilers is now about 1/2 the speed of C++. This is
> fast enough.

Don't you think a factor of 2 is a lot ? Pity to waste half of your cpu power
for the beauty of no recompile. Non-platform specific C or C++ code might be
just as well.
-- 
Greetings,
Michel
.........................................................................
  Michel Jullian   Directeur General             email mj@exbang.com
  Exbang Industries S.A.
  Mas Chauvain   route de Villeneuve             tel +33(0) 499 529 878
  Maurin     34970 Lattes     France             fax +33(0) 499 529 879
.........................................................................

>Michael Gogins wrote:
>> 
>> Another misconception: these days, Java IS fast. I do all my new DSP coding
>> in Java. Java with best compilers is now about 1/2 the speed of C++. This is
>> fast enough.

Well I did not receive the above posting, so I may be quoting out of context.

First, half as fast is too slow when I've spent lots of time
just to get 20% speed ups in C.

Second, whether something is fast has nothing to do with whether 
something is real time. A real time system has guarantees on latency.
Java's GC scheme does not. It must suspend all threads to do its collection
and the way its finalization scheme is designed it is difficult to
make it a guaranteed real time system. You can't guarantee that on 
any particular system you'll be able to get a real time GC for your
Java implentation. 

I know of no Java that is capable of running in real time with performance
guarantees and able to run in an interrupt routine where memory allocation 
is illegal.
SuperCollider was designed to be able to do this.

Third, the SC virtual machine is C which is far more portable than Java.
If I wanted to port to a DSP chip I could not get a Java compiler for it.
That is why SC is in C and not C++.


This is from a different posting:

>Is there any way that the SuperCollider language would lend itself to
>implementation of those so-popular unit generator wiring forms? Now that I
>have played with Generator a little, I rather like them.

Yes, however wire up diagrams are not easily able to express the
dynamic things you can do in a supercollider program.
It would be a subset of what you could do with the language.


   --- james mccartney     james@audiosynth.com   http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:






dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html

>I know of no Java that is capable of running in real time with performance
>guarantees and able to run in an interrupt routine where memory allocation 
>is illegal. SuperCollider was designed to be able to do this.

i am not sure how much of SC runs (or can run) in an interrupt
routine, but if its a lot then i am suprised that you seem proud of
this. although this is undoubtedly an approach that helps raw speed,
it seems incredibly unportable, and also very hard to ever plan on
using in a multiprocessor system. If you wanted to do this kind thing
on Linux, BeOS or various other systems, you'd be totally hosed. You
would totally destroy system timing, amongst other things. You could
never do inter-processor synchronization within an interrupt routine.

i am at a loss to understand why you chose to do things in an
interrupt routine. i guess i am just too much of a unix head to grok
the Mac (and maybe Windows) world.

>Third, the SC virtual machine is C which is far more portable than Java.

Michael's idea, I think, is to not write the VM in Java, but to use a
C implementation to support Java's "native methods" (i.e. things that
appear to be builtins in Java). I'm not attracted to this idea all
that much, but it seems like quite a reasonable one to me.

>If I wanted to port to a DSP chip I could not get a Java compiler for it.
>That is why SC is in C and not C++.

I think you will find that GCC exists for most of the worthwhile DSP
chips out there, and with it, G++. Thats certainly true for the SHARC 26XXX
and Motorola 56K series. 

At 1:12 PM -0600 6/17/99, Paul Barton-Davis wrote:

>using in a multiprocessor system. If you wanted to do this kind thing
>on Linux, BeOS or various other systems, you'd be totally hosed. You
>would totally destroy system timing, amongst other things. 

Totally false. How would I totally destroy system timing?
I see no problem at all with porting to Linux or BeOS.
I'm writing BeOS MediaKit code right now. I am aware of the issues
involved there and there is nothing there that would prevent SC 
from living there.

You could
>never do inter-processor synchronization within an interrupt routine.

On the Mac it is an interrupt routine, on BeOS you are in a MediaKit
call back where you are also not able to do things which take
unbounded amounts of time either. SC's GC runs in bounded time.
Java's does not.

>I think you will find that GCC exists for most of the worthwhile DSP
>chips out there, and with it, G++. Thats certainly true for the SHARC 26XXX
>and Motorola 56K series. 

Availability of C++ compilers are improving but they are still horrible
for the most part for DSP code generation.
I wrote the high level firmware for the Level Control Systems digital
mixers http://www.lcsaudio.com and we used C because the C++ compilers
sucked so badly.

I also wrote LCS's host software on BeOS. It is still one of the 
largest programs ever shipped on BeOS, so I think I know that platform.


   --- james mccartney     james@audiosynth.com   http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program: