Interesting read:
http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
Personal comments:
Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
up - I don't see why it inhibits (in spite of the many initial
difficulties as mentioned in the paper) the growth of using Java for
device drivers development. Contrast it against udev - esp in terms of
usability/supportability/extensibility etc. udev is a Linux thing,
whereas Java is at industry level. If everyone write applications
device drivers using Java (minus the extreme hardware arch specific
stuff, but supports all the low level protocol specific stuff like
TCP/IP, NFS, USB etc) then I think it has potential to compete against C
lang - the monopolizer till today in the kernel world
(Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
the Solaris in Linux, won't it be cool?
In article <[email protected]> you wrote:
> (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> the Solaris in Linux, won't it be cool?
I think the device driver reuse between the various C-kernels is pretty big.
For efficiency and since the low level stuff is a major part of device
drivers, I cant see a Java solution. I guess we would see drivers in Forth before :)
Gruss
Bernd
From: Peter Teoh <[email protected]>
Date: Mon, 31 Mar 2008 10:14:55 +0800
> Ie, imagine using a drivers written for the Solaris in Linux, won't
> it be cool?
About as cool as a fart in a spacesuit.
On Mon, Mar 31, 2008 at 04:59:00AM +0200, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> > the Solaris in Linux, won't it be cool?
>
> I think the device driver reuse between the various C-kernels is pretty big.
> For efficiency and since the low level stuff is a major part of device
> drivers, I cant see a Java solution. I guess we would see drivers in Forth before :)
Don't forget assembler converted to binary by bash(1) and a stunning
innovation of . added in front of directory names...
[if you want to summon you-know-what, might as well do that properly]
On Mon, Mar 31, 2008 at 10:14:55AM +0800, Peter Teoh wrote:
> Interesting read:
>
> http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
>
> Personal comments:
>
> Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
> up - I don't see why it inhibits (in spite of the many initial
> difficulties as mentioned in the paper) the growth of using Java for
> device drivers development. Contrast it against udev - esp in terms of
> usability/supportability/extensibility etc. udev is a Linux thing,
> whereas Java is at industry level. If everyone write applications
> device drivers using Java (minus the extreme hardware arch specific
> stuff, but supports all the low level protocol specific stuff like
> TCP/IP, NFS, USB etc) then I think it has potential to compete against C
> lang - the monopolizer till today in the kernel world
> (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> the Solaris in Linux, won't it be cool?
Oh fantastic! That way, we could have drivers which eat 1Gig of RAM for
almost nothing. Also, my experience with Java developers shows that what
Java really is is a way to lower the entry level in the development world.
That way, you can have completely incompetent people write complex
applications without even thinking that it will run on a real machine.
Most often, if it works in their IDE, they think it's OK to deploy (not
mentioning the fact that RFC compliance is far from being a problem in
these people's work). Of course, there are still real coders using this
language, and they may do great things (when the frameworks permit).
When you see salesmen announcing that their app will require about
400 GHz of CPU and half a TB of RAM to run, and noone even cares,
you understand there's a big problem with the way things are written
(the app that one was supposed to replace could run on 2 GHz of CPU
and 4 GB of RAM in the C version).
So please keep these technologies for sucking your nearby powerplant's
power and justifying your boss that you need a monster machine which
would make HPC people jealous, but I would hate it to make it easier
for the people I described above to pollute the kernel with their crap.
Willy
On Mon, 2008-03-31 at 10:14 +0800, Peter Teoh wrote:
> Interesting read:
>
> http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
>
> Personal comments:
>
> Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
> up - I don't see why it inhibits (in spite of the many initial
> difficulties as mentioned in the paper) the growth of using Java for
> device drivers development. Contrast it against udev - esp in terms of
> usability/supportability/extensibility etc. udev is a Linux thing,
> whereas Java is at industry level. If everyone write applications
> device drivers using Java (minus the extreme hardware arch specific
> stuff, but supports all the low level protocol specific stuff like
> TCP/IP, NFS, USB etc) then I think it has potential to compete against C
> lang - the monopolizer till today in the kernel world
> (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> the Solaris in Linux, won't it be cool?
You're off by one day for an April fool...
Ben.
Willy Tarreau wrote:
> On Mon, Mar 31, 2008 at 10:14:55AM +0800, Peter Teoh wrote:
>
[snip]
>> imagine using a drivers written [in java] for
>> the Solaris in Linux, won't it be cool?
>>
> [...]
>
> So please keep these technologies for sucking your nearby powerplant's
> power and justifying your boss that you need a monster machine which
> would make HPC people jealous, but I would hate it to make it easier
> for the people I described above to pollute the kernel with their crap.
Perhaps somebody will argue that Java runs on quite small, even
low-power. machines; but all of that would still miss the point, I
think, that it's the differences between operating systems which prevent
drivers written for one platform from "just working" on another. Look
at the effort that NDISwrapper has to go through to make a mere subset
of Windows drivers work on Linux: It wouldn't be any easier if those
drivers were written in Java. Platforms are different and drivers
reflect those differences and that's the way it is.
And it's *still* not April 1. This thread would have been quite clever
if it were.
On Mon, 2008-03-31 at 10:14 +0800, Peter Teoh wrote:
> Interesting read:
>
> http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
>
> Personal comments:
>
> Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
> up - I don't see why it inhibits (in spite of the many initial
> difficulties as mentioned in the paper) the growth of using Java for
> device drivers development. Contrast it against udev - esp in terms of
> usability/supportability/extensibility etc. udev is a Linux thing,
> whereas Java is at industry level. If everyone write applications
> device drivers using Java (minus the extreme hardware arch specific
> stuff, but supports all the low level protocol specific stuff like
> TCP/IP, NFS, USB etc) then I think it has potential to compete against C
> lang - the monopolizer till today in the kernel world
> (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> the Solaris in Linux, won't it be cool?
LOL.. good joke!
But as others have pointed out, you missed April's fools by 1 day.
On Mon, Mar 31, 2008 at 11:28 AM, Peter Zijlstra <[email protected]> wrote:
> On Mon, 2008-03-31 at 10:14 +0800, Peter Teoh wrote:
>
> > Interesting read:
> >
> > http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
> >
> > Personal comments:
> >
> > Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
> > up - I don't see why it inhibits (in spite of the many initial
> > difficulties as mentioned in the paper) the growth of using Java for
> > device drivers development. Contrast it against udev - esp in terms of
> > usability/supportability/extensibility etc. udev is a Linux thing,
> > whereas Java is at industry level. If everyone write applications
> > device drivers using Java (minus the extreme hardware arch specific
> > stuff, but supports all the low level protocol specific stuff like
> > TCP/IP, NFS, USB etc) then I think it has potential to compete against C
> > lang - the monopolizer till today in the kernel world
> > (Windows/MacOS/Linux/BSD etc). Ie, imagine using a drivers written for
> > the Solaris in Linux, won't it be cool?
>
>
> LOL.. good joke!
>
> But as others have pointed out, you missed April's fools by 1 day.
It is actually 1st of april in Kiritimati for about 45 minutes at the
time of this writing.
http://www.timeanddate.com/worldclock/city.html?n=274
Peter Zijlstra pisze:
> On Mon, 2008-03-31 at 10:14 +0800, Peter Teoh wrote:
>> Interesting read:
>>
>> http://research.sun.com/techrep/2006/smli_tr-2006-156.pdf
>>
>> Personal comments:
>>
>> Since KVM and Xen/OpenVZ etc other virtual machines are beginning to pop
>> up - I don't see why it inhibits (in spite of the many initial
>> difficulties as mentioned in the paper) the growth of using Java for
>> device drivers development. Contrast it against udev - esp in terms of
>> usability/supportability/extensibility etc. udev is a Linux thing,
>> whereas Java is at industry level. If everyone write applications
>> device drivers using Java (minus the extreme hardware arch specific
>> stuff, but supports all the low level protocol specific stuff like
>> TCP/IP, NFS, USB etc) then I think it has potential to compete against C
Java? Compete against C? Don't scare embedded devs.
On Mon, Mar 31, 2008 at 7:58 PM, Jacek Luczak <[email protected]> wrote:
> Peter Zijlstra pisze:
> >
> Java? Compete against C? Don't scare embedded devs.
>
The future is always uncertain for us. Embedded development usually
emphasizes on performance, unlike those of the desktop. So which
language will be king tomorrow in embedded, it boils down to
performance + optimization + ease of development. Just imagine:
from 10 lines of C reduced to 2 lines of XXX-based language software -
I think the 10 lines will scare off the embedded developers of
tomorrow. I may be wrong :-).
-
Regards,
Peter Teoh
Thank you for the comments.
>
> I think the device driver reuse between the various C-kernels is pretty big.
> For efficiency and since the low level stuff is a major part of device
> drivers, I cant see a Java solution. I guess we would see drivers in Forth before :)
not sure about forth, but fortran is claimed to be faster than C,
based on ease of optimization reason:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
For a surprising benchmark dated Oct2007, this guy started off without
knowing who will win:
http://www.stefankrause.net/wp/?p=4
http://www.stefankrause.net/wp/?p=6
Looking at all those number, unbelivebly Java performed better than
gcc in several ways. To quote the author:
"# Saying that C is generally several times faster than java is -
according to those benchmarks - simply wrong."
but he also cautioned:
"# Saying that Java is faster than C can also be pretty wrong,
especially if you have to stick with one JVM."
http://www.freewebs.com/godaves/javabench_revisited/
http://kano.net/javabench/
well, performance of speed is one thing, but other stuff like (for
desktop computing) ease of support, enhancement, and ease of use need
to be considered as well. That's why .Net, with its huge overheads,
still has a huge followers, even though its predecessor is much more
efficient and faster, and delivering the same level of GUI programming
feature.
For embedded and server-based computing performance will still be
king. But won't you be enticed to a new world of programming where
one or two liners can replaced 10 lines in C? With the complexity in
locking and irq handling all taken care of underneath you? Ie,
automatic synchronization done by some other components in the kernel,
thus reducing the lines of codes?
Well.....the future is uncertain....i cannot predict it :-). Happy
April Fool's Day (I like that joke!!!! LOL...)
-
Regards,
Peter Teoh
On Mon, Mar 31, 2008 at 11:18 PM, Peter Teoh <[email protected]> wrote:
> Thank you for the comments.
>
>
> >
> > I think the device driver reuse between the various C-kernels is pretty big.
> > For efficiency and since the low level stuff is a major part of device
> > drivers, I cant see a Java solution. I guess we would see drivers in Forth before :)
>
> not sure about forth, but fortran is claimed to be faster than C,
> based on ease of optimization reason:
>
> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>
> For a surprising benchmark dated Oct2007, this guy started off without
> knowing who will win:
>
> http://www.stefankrause.net/wp/?p=4
> http://www.stefankrause.net/wp/?p=6
>
> Looking at all those number, unbelivebly Java performed better than
> gcc in several ways. To quote the author:
>
> "# Saying that C is generally several times faster than java is -
> according to those benchmarks - simply wrong."
>
> but he also cautioned:
>
> "# Saying that Java is faster than C can also be pretty wrong,
> especially if you have to stick with one JVM."
>
> http://www.freewebs.com/godaves/javabench_revisited/
> http://kano.net/javabench/
>
> well, performance of speed is one thing, but other stuff like (for
> desktop computing) ease of support, enhancement, and ease of use need
> to be considered as well. That's why .Net, with its huge overheads,
> still has a huge followers, even though its predecessor is much more
> efficient and faster, and delivering the same level of GUI programming
> feature.
>
> For embedded and server-based computing performance will still be
> king. But won't you be enticed to a new world of programming where
> one or two liners can replaced 10 lines in C? With the complexity in
> locking and irq handling all taken care of underneath you? Ie,
> automatic synchronization done by some other components in the kernel,
> thus reducing the lines of codes?
>
> Well.....the future is uncertain....i cannot predict it :-). Happy
> April Fool's Day (I like that joke!!!! LOL...)
Just would like to comment further: analogous to the trend that with
the huge increase in storage space availability, size of storage
required is of minimal concerns, in comparison with other more serious
bottlenecks, the future CPU may have so much spare execution cycles,
that emulation (like what Java or AMD Pacifica or Intel VMX is doing)
is a much needed feature instead, as it provide other feature like
security assurance etc, without affecting interactivity on the users,
or perhaps being overshadowed by other bottleneck (like network I/O,
or harddisk I/O etc).
Thanks.
--
Regards,
Peter Teoh
On Mon, Mar 31, 2008 at 6:52 PM, Peter Teoh <[email protected]> wrote:
> Just would like to comment further: analogous to the trend that with
> the huge increase in storage space availability, size of storage
> required is of minimal concerns, in comparison with other more serious
> bottlenecks, the future CPU may have so much spare execution cycles,
> that emulation (like what Java or AMD Pacifica or Intel VMX is doing)
> is a much needed feature instead, as it provide other feature like
> security assurance etc, without affecting interactivity on the users,
> or perhaps being overshadowed by other bottleneck (like network I/O,
> or harddisk I/O etc).
Sure, let's all develop power-hungry applications cause the technology
and infrastructure can support it. And to hell with increasing energy
prices, energy crisis and global warming. Only thing that matters to
me is figuring out how to set the CLASSPATH properly! The world, may
it crumble for all I care!