| |
ZL3AI > APRDIG 22.09.06 00:33l 232 Lines 12791 Bytes #999 (0) @ WW
BID : 8798-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 27 #19, 5/6
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<F6GGY<F4BWT<IW2OAZ<ZL2BAU
Sent: 060921/2210Z @:ZL2BAU.#87.NZL.OC #:5684 [Waimate] $:8798-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 30
Date: Tue, 19 Sep 2006 05:15:48 +0200
From: Gregg Wonderly <gregg_at_wonderly.org>
Subject: Re: [aprssig] followup on Rant about cross platform
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
------------------------------
Read previous mail | Read next mail
| |
