From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-02-05 18:12:35
Hi John and Andreas,
> don't get me wrong - I'd love to use Java, it's just that I
> encountered some problems in my testing.
If I was still a Java evangelist, I would try to convince you,
that Java is the best thing since sliced bread, and that the
sky is green too, and I can be very convincing (ask M$ ;) ...
But Java only shines within a certain window of things, and
I'm not a Java evangelist anymore. My motivations are not much
different than Jim Meissner's, I'd like to see something good
come out of this effort.
The choice of programming tools is a tough dilemma. There are
always political factors to consider. My favorite combo is
blackdown java on slackware linux. As I said, I will be trying
this combo for NF, but I won't ask that this be the choice
for this project. I am a an avid linux fan. One of the big
problems though is that a lot of people still don't use linux,
especially the non techies. It is still not clear to me who
the target audience for OpenEEG is. If it's a hobby/hacker
effort, then I think linux is hands down and obvious choice.
But if it's for everyday users, or EEG practitioners, then
linux might not be acceptable. In other words, I hate to
say it, but if you want to go outside the realm of the
techies, a windows version may be the only real choice. If
Java was fast enough, it might be a way to get this to work
on both platforms, but it may not be. That is why I will be
doing some of my own independent testing of Java for this
purpose, to see if it suffices. I have learned some tricks
at optimization and such with Java.
I have no problem at all with GNU C, in fact I am a huge
fan of GNU, and I think that linux is more significant than
Java in the big scheme of things. Right now I am assuming
that we are proceeding with a linux/C based design, since
that seems to be what everyone wants. But again, the
question is, who is the target audience, and what do they
want?
> Suppose the signal processing is done in native code, and
> only the user interface is written in Java.
Actually, GUI seems to be the slowest part of Java. I have
done lots of multhithreaded Java code, and lots of network
code with Java. The fact that it is interpreted does not
make it magnitudes slower, but UI is a cycle hog. Our box
that we made with mitsubishi ran 16-20 Java threads at the
same time with good results. I have seen hundreds of 3rd
party Java apps (graphical too) that perform well, but
people need to do some optimization tricks to achieve
that end.
> JNIEXPORT jint JNICALL
I am open to all ideas re software. I think that Jim-P
is doing some excellent work with filtering. Now I think
we need to work on specifying features, including the
problem of how to support training protocols.
> Another problem that cropped up: how does one keep the
> garbage collector from preempting the process?
This is one of the main arguments against Java, and yet
it's usually a non issue, as most systems are not of the
"hard real time" variety. I have mentioned before that
"vertical prototypes" are the way to prove or disprove
these things. If anything is questionable, especially
performance and user response, that is when you want to
do a quick-and-dirty vertical prototype to prove that
it works and/or seek alternatives. There are some GC
tricks, but I don't think it's worth getting into that
now. Also, just FYI, for future reference, those VMs
on silicon are capable of deterministic real-time,
they use a completely different garbage collection
method than the software VMs. I have also seen some
tools that can turn Java code to native, in fact some
allow you to pick which methods you want to make into
native and which remain bytecode.
John, I actually do want to "send EEG over the net"
too, because I'm a networking nut, but let's be honest
and say that this is of little practical value. Why
would someone really want to do this in real-time?
It does make sense that data can be sent around, but
we could just record a session in a file and then
transport the file after the session. Me being able
to watch your waves rolling in as they happen would
be one of those "cool!" things, but what is the real
value of it? Anyone? Anyone? Bueller? Bueller? <g>
Also, RMI might not be the best protocol for this
kind of remote sending. I absolutely love RMI, and
Sun hired me because I was an RMI freak. I wrote an
article about RMI when it was in alpha 1 version
using JDK 1.02 in 1995. RMI is a slick interface.
It is an evolution of the old procedural RPC, it
is essentially object-oriented RPC. But there is
a trade-off you make in that clean and elegant way
of coding. It is a synchronous protocol. It will
use three threads for every connection. It will
send remote object stubs over the net as bytecode.
I have actually tested RMI over 10,000 miles and
it works great, but again ONLY within a certain
problem space. With EEG we are talking about a
lot of data, and a stream of data. So for remote
sending, assuming there really is a need for this
in real time (and I doubt there is), RMI may not
work well, my gut fell is that it won't. A better
approach would probably be plain ole TCP sockets.
Namaste,
Doug
PS. Don't ask me to write MFC code ;-)
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:38 BST