[aprssig] followup on Rant about cross platform
Gregg Wonderly
gregg at wonderly.org
Mon Sep 18 23:15:48 EDT 2006
Jim Lux wrote:
> The idea I was trying to develop was that people developing software for
> love (which is the vast majority, if not all, of amateur radio software)
> have to make decisions about how to allocate their scarce resources.
> The easy decision (because developers for love tend to want to minimize
> the work making their baby) is to work in what you know, and,
> statistically, that's not likely to be Java (no matter how wonderful it
> may or may not be).
I really do appreciate the fact that there is time to be spent learning. We all
have to spend the time that we can doing the things that make our lives as
pleasant and enjoyable as we'd like for them to be.
I think about it this way. It's really easy to sit on the couch and watch TV.
If I get up off the couch and ride my bike, I get some exercise. If I get
enough exercise, my body might last longer and I might actually get to
accomplish more than I hoped I could by living through tomorrow a few more times.
In any kind of task that requires learning new things, we all feel put back by
the concept of the unknown boundry on intervals of time that might be required.
Many things are wastes of time. Others are eye opening, and/or life changing
that we never imagined the benefits or results. In the case of software
development, computer science has not really advanced lately from a technology
perspective. We are able to create the same type of software faster because of
IDEs and faster computers.
We largely are still solving computing problems with the same computational
constructs and flow structures. Everyone is recreating the same software
someone else has already created for either a different langauge or a different
operating system that has specific functional interfaces not supported by
another programs structure. This is a tremendous waste of time, and practically
it creates a division of software capabilities which make it even more likely
that various pieces of software will not work together.
The development of XML and Web-Services standards are an attempt to allow all of
these computer languages to share a common form of communications. This is very
popular, although it is not a scalable solution for the long run.
The Java Virtual machine supports 100s of languages (see
http://www.robert-tolksdorf.de/vmlanguages.html). You can use any of those
languages anywhere there is a JVM. This is the same model that .Net is aimed
at. Perhaps Microsoft sees these issues and undertands. But, I think more than
anything that they are trying to make all languages work on .Net to maintain
their customer base. .Net restricts all .Net languages to the features of the
Common Language Runtime (CLR), which means that their C++ is capable of no more
than C#, including the loss of multiple inheritence. So, it comes down to the
fact that the runtime environments are collapsing into platforms of software
libraries. The hardware is getting farther away from the software developers
thoughts.
> When you talk of DSP code (e.g. the example Gregg gave of a PSK31
> engine, or some other modem implementation), the likely coder is someone
> who is almost certainly not from the Java world, if only because Java
> isn't particularly popular for these applications, especially in an
> embedded environment.
There are almost no differences between Java and C for math expressions. The
only subtle differences are in getting to more advanced math functions using the
the library objects. I don't want to turn this into a how to write Java
series. If anyone wants more pointers just send me a request.
> This is not to say that you couldn't write hard-real-time DSP code in
> Java (Ii suspect you could, with sufficient resources), but rather that,
> most likely, the code base they would be starting from is more likely to
> be in ASM or C. There is a lot of work involved in writing modem code,
> especially to handle all the corner cases and deal with the
> idiosyncracies of the surrounding environment, while still giving good
> performance, and most people start with something that they know works
> somewhere, and then modify it for the new platform. As they say, old
> habits die hard.
Any program on a timesharing operating system has to deal with this issue. At
some point in a time shared envionment, you won't have the CPU, some other code
will. To do DSP code right, you really need to use the operating system
provided buffering and process it asynchronously, not try and read it one byte
at a time and risk loss of data. This is present in most audio processing
applications that I've seen these days. The built in buffering and audio I/O
facilities in windows is largely why using the audio card on PCs has gotten so
popular.
Audio processing in most amatuer radio operations is not that compute intensive.
Optimizations are typically being done for the numbers it seems to me. If
your DSP code is that tight against the wall on a PC, you really need to just go
get a DSP board and build an embedded system.
Call you analog phone on you digital cell phone and listen to the delays created
by the digital audio processing systems that are part of those systems. We all
know these delays are there. We interrupt each other sometimes because of the
delays leaving holes in the coversation. If the commercial systems can't get by
without these delays, what makes us feel that we have to try so hard to achieve
absolute hard realtime results? It's not possible on a timesharing OS.
> I'll also comment that in many of the DSP projects I've been involved
> in, the non-determinism of timing in standard Java would make it an
> out-of-the-gate non-starter, even if it were available for the target
> processor. Sure, one could probably come up with a custom
> implementation of the JVM/JRE with appropriate determinism, hooks to the
> hardware, etc., but then, you're not in the "write once, run everywhere"
> model anymore. I readily confess that I know next to nothing about how
> one might even start doing this in Java.
The first thing that is important is to realize that Java has queuing and
threading support that makes it trivial to create a thread that is reading data
from an audio stream and queuing it to a processing queue. Another thread can
read from that processing queue, and process the audio data and then queue it
for use by a third thread. This allows multi-processor/multi-core computers to
trivally become more powerful to the user by overlapping latency. This is not
available in standard C/C++ (except through 3rd party libraries or OS specific
features) and many other programming environments have no support at all.
> I understand that there are
> efforts being made to create a "real-time Java", but, it's nowhere near
> as mature as the existing body of knowledge in Asm or C (better the
> devil you know, etc.). But this gets back to the point about people tend
> to want to work in the environment they are familiar with, which,
> statistically, is not Java.
At Javaone this year, I wrote Java software using the RTSJ (Real Time System for
Java) implementation that Sun has done for Solaris. That Java software drove a
slot car around the track. I had the input of track position markers. I could
thus see where I was on the track and my speed (time between markers). For
output, I could drive a Digital to Analog converter that provide control of the
power present on the track, and braking. I had to go around the track twice,
once on the inside and once on the outside. I was about 13th out of 100 or more
contestants.
Real Time is about predictable scheduling more than anything else. The RTSJ
(which you can get for a few other processors, but which only makes sense for
time sharing systems), is a solution that exists now as a specification and has
some existing implementations.
There are processors such as the AJile microcontroller which run Java directly.
The 100mhz version of that processor is very power conservative by design.
There are demos of it doing MPEG video decoding, without any jitters or hiccups
in processing. So, realtime is possible for Java. Most audio/video
applications are mostly about applying some very specific software architectures
to manage the issues that you might have on your target platform. You have to
do that for any language though. Java happens to provide the same APIs and
programming constructs on all platforms. That makes it easier to write it once
and run it anywhere.
> So, it's a pretty bold request to ask a volunteer to take on not only
> coding/porting up some sort of modem (a non-trivial task in itself, but
> one that is small enough to be done in a reasonable time ), but also to
> ask that they learn a whole new computing environment, with just as many
> idiosyncracies as, say, Windows.
This is an important issue. I don't think though that there is as large a
barrier as some perceive. I think that there are differences which feel very
different because of limited experiences. But, those things can be gotten past
fairly easily with someone who can help you think in the right way to get started.
> You'd probably have to show that the
> new environment provides some really useful functionality (to the
> volunteer) that they currently don't have available, or that is a pain
> to get. That is, it will make their job noticeably easier if they
> adopt, for example, Java. An appeal to an abstract altruism: "it will
> help society in the future" is a much harder sell. It's true you've at
> least got them volunteering in the first place, so it's not a totally
> lost cause. There's a similar discussion going on in the SDR-1000 world
> about the adoption of a language called Erlang.
When I started using Java seriously, I did it mostly because of garbage
collection/memory management. There was enough support in Java1.0.1 with the
Hashtable and Vector classes, for the programming structures that I used most
often, that I no longer had to manage any memory stuff myself, other than
dropping references to things I didn't need to use any longer. This was in
1995/1996 when there were still not too many interesting libraries for C/C++
related to data structures management. A decade later, everyone has looked at
the power of the Java platform's libraries and found the convenience of them to
be attractive.
Look at what Microsoft has done in developing .Net. They took the concepts of
the java platform and wrapped it in Microsoft covers so that they could change
more things to tightly integrate it into their OS (the java license that they
had did not allow private changes to be made public as they were doing with
J++). Windows has a lot of things that are very specific to the OS design and
to the historical line of the development of the windows programming model.
Many of these things are different from other OS and GUI environments, and that
is one of the big factors which makes portability of software very difficult.
There is a lot more of the OS and hardware visible in the windows APIs than
there is in many other more portable software systems. So, you have to consider
those issues to manage portability when writing software with certain language
environments.
> Gosh, people are still developing applications for ham radio that are
> based on MS-DOS, and probably modified from code originally written for
> a Z80 running CP/M. In that context, Java is just a young stripling
> with a lot of growing left to do. And, I see ham radio software moving
> towards a more "componentized" implementation, with cleaner interfaces
> among components. I really shouldn't care what langauge the PSK engine
> is written in, as long as it's available for my platform and it has the
> right hooks to make it work.
Right, and that's my biggest concern. No one seems to see the benefits of
crossplatform portability with clear enough sight to understand the larger
benefits that we might actually be able to reach by using portable software.
Imagine being able to write modules to plug into a users environment, instead of
having to write a whole application framework, and then make the user sort
through your UI and learn how to use it.
I know a lot of this sounds like a pipe dream. But, there really is a chance to
make a dramatic change in how software for Amatuer Radio applications is done.
It's just a matter of people deciding to, and being able to get engaged in
making the change toward open/portable systems happen.
I'll leave it at that, I've certainly gone on for more that I intended.
Gregg Wonderly
W5GGW
More information about the aprssig
mailing list