Re: [OT] Threads, inelegance, and Java

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 07:25, Aaron Lehmann wrote:
> On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> > Just the fact that some people use Java (or any other language) does
> > not mean, that they don't care about "performance, system-design or
> > any elegance whatsoever" [2].
>
> However, the very concept of Java encourages not caring about
> "performance, system-design or any elegance whatsoever".

The same arguments were made 30 years ago about writing the OS in a high 
level language like C rather than in raw assembly.  And back in the days of 
the sub-1-mhz CPU, that really meant something.

> If you cared
> about any of those things you would compile to native code (it exists
> for a reason). Need run-anywhere support? Distribute sources instead.
> Once they are compiled they won't need to be reinterpreted on every
> run.

I don't know about that.  The 8 bit nature of java bytecode means you can 
suck WAY more instructions in across the memory bus in a given clock cycle, 
and you can also hold an insane amount of them in cache.  These are the real 
performance limiting factors, since the inside of your processor is clock 
multiplied into double digits nowdays, and that'll only increase as die sizes 
shrink, transistor budgets grow, and cache sizes get bigger.

In theory, a 2-core RISC or 3-core VLIW processor can execute an interpretive 
JVM pretty darn fast.  Think a jump-table based version (not quite an array 
of function pointers dereferenced by the bytecode, instead something that 
doesn't push anything on the stack since you know where they all return to).  
The lookup is seperate enough that it can be done by another (otherwise idle) 
processor core.  Dunno how that would affect speculative execution.  But the 
REAL advantage of this is, you run straight 8 bit java code that you can fit 
GOBS of in the L1 and L2 caches.

Or if you like the idea of a JIT, think about transmeta writing a code 
morphing layer that takes java bytecodes.  Ditch the VM and have the 
processor do it in-cache.

This doesn't mean java is really likely to outperform native code.  But it 
does mean that the theoretical performance problems aren't really that bad.  
Most java programs I've seen were written by rabid monkeys, but that's not 
the fault of the language. [1].

I've done java on a 486dx75 with 24 megabytes of ram (my old butterfly 
keyboard thinkpad laptop), and I got decent performance out of it.  You don't 
make a lot of objects, you make one object with a lot of variables and 
methods in it.  You don't unnecessarily allocate and discard objects 
(including strings, the stupid implementation of string+string+string is 
evil,) to bulk up the garbage collector and fragment your memory.  The 
garbage collector does NOT shrink the heap allocated from the OS, the best 
you can hope for is that some of it'll be swapped out, which is evil, but an 
implementation problem rather than a language design problem.)

For a while I was thinking of fixing java's memory problems by implementing a 
bytecode interpreter based on an object table.  (Yeah, one more layer of 
indirection, but it allowed a 64 bit address space, truly asynchronous 
garbage collection, and packing the heap asynchronously as well.  I was 
actually trying to get it all to work within hard realtime constraints for a 
while.  (No, you can't allocate a new object within hard realtime.  But you 
could do just about everything else.)  But Sun owns java and I didn't feel 
like boxing myself in with one of thier oddball licenses.  Maybe I'll look at 
python's bytecode stuff someday and see if any of the ideas transfer over...)

How many instructions does your average processor really NEED?  MIT's first 
computer had 4 instructions: load, save, add, and test/jump.  We only need 32 
or 64 bits for the data we're manipulating.  8 bit code is a large part of 
what allowed people to write early video games in 8k of ram.

By the way: Python's approach to memory management is to completely ignore 
it.  Have you seen the way it deals with loops?  (Hint: allocate an object 
for each iteration through the loop, and usually this is done up front 
creating a big array of them that is then iterated through.)  And this turns 
out to be a usable enough approach that people are writing action games in 
python via SDL bindings.  The largest contributing factor to Java's 
reputation for bad performance is that most java programmers really really 
suck.  (Considering that most of them were brand new to the language in 1998 
and even veterans like me only learned it in 1995, it's not entirely 
suprising.  And that for many of them, it's their first language period...)

So if it's possible to write efficient code in python, it's GOT to be 
possible to write efficient code in Java, which can at least loop without 
allocating objects in the process.  (Yeah, I know about map, I'm trying to 
make a point here. :)

Rob

[1] Java 1.1 anyway.  1.0 hadn't seen the light of day in real usage yet, and 
as such doesn't actually work very well.  1.1 was revised based on the 
complaints from the field, and is in my opinion where the language peaked.  
(And that's still what I teach to students whenever I do an intro to Java 
course at the local community college.)

Java 1.2 is bloated, and Swing is just evil.  I haven't even looked at 3.  
Sun has the same case of featuritis that infests netscape navigator, 
microsoft word, and every other piece of proprietary software that's already 
sold a bunch of copies to users and now has to figure out how to get MORE 
money out of them.  Where "one more feature" may cause yet another customer 
to buy it, and is therefore worth money.  Open Source doesn't have that 
problem because we have to maintain this gorp ourselves, and we're far too 
lazy to include anything in there unless there would be serious and 
widespread complaints if it were removed.  About the only proprietary 
software that DOESN'T have this problem is games, because people solve old 
games and put them aside, so you can always write another game and sell it to 
the same people.

[OT] Threads, inelegance, and Java

[Aaron Lehmann]

On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> Just the fact that some people use Java (or any other language) does
> not mean, that they don't care about "performance, system-design or
> any elegance whatsoever" [2].

However, the very concept of Java encourages not caring about
"performance, system-design or any elegance whatsoever". If you cared
about any of those things you would compile to native code (it exists
for a reason). Need run-anywhere support? Distribute sources instead.
Once they are compiled they won't need to be reinterpreted on every
run.

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 12:53, Larry McVoy wrote:

> We couldn't believe that Java was really that bad so our GUI guy, Aaron
> Kushner, sat down and rewrote the revision history browser in Java.
> On a 500 node graph, the Java tool was up to 85MB.  The tk tool doing
> the same thing was 5MB.  Note that we routinely run the tool on files
> with 4000 nodes, we can't even run the Java tool on files that big,
> it crashes.

I can second that.

I recently mentioned an OS/2 abonination called Feature Install.  Around 1996 
I tried to port Feature Install to java 1.0.  I got as far as the response 
file reading code, and reading in a 100k file exhausted available memory on 
the 32 megabyte machine I was working on.

Remember, every single java object includes a BUNCH of data, including two 
semaphores (one event, one mutex) and who knows what else.  On OS/2 the 
overhead of a java 1.0 object (new Object();) was 2 kilobytes!  In later 
versions they got that down to around 200k, but it's still just rediculous.  
Every single String, every pointless Integer() wrapper, every temporarily 
created Stringbuffer() discarded by a + operation left there littering the 
stack.

Plus I have yet to see a JVM that actually reclaims heap space after a 
garbage collect and gives it back to the OS.  (You have to be able to 
relocate objects to do this at all reliably...)

So if you create a large number of small objects, EVER, (tree, etc,) it's 
going to explode the heap and it'll never come down until the program exits.

> So, yeah, we have done what you think we haven't done, and we've tried
> the Java way, we aren't making this stuff up.  We run into Java fanatics
> all the time and when we start asking "so what toolkits do you use" we
> get back "well, actually, err, umm, none of them are any good so we write
> our own".  That's pathetic.

Also true.

The Graphics class isn't too bad, and lightweight containers are actually 
quite nice.  But swing is just insanely bad (I have to understand 
model/view/controller and select a look-and-feel just to pop up a dialog with 
an "ok" button?), and the only serious third party challenger to it was from 
MIcrosoft...

Rob

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 13:03, Tony Hoyle wrote:

> (Just came back from a .NET conference...  MS are currently rewriting
> all their apps in bytecode... whoopee...  They're even porting *games*
> to run on it.  I can see it now 'MS Flight Simulator .NET' (Requires
> quad Pentium 4 1.6Ghz minimum) :-o )

Well, that ought to make Intel happy.  The price of a new desktop box around 
these parts has dropped to about $250, and that comes preassembled.  $25 for 
ram, $80 hard drive, $40 processor in ~$30 motherboard, and the floppy, case, 
power supply, and keyboard are all a rounding error.  The monitor's still 
expensive, but those are recycled from system to system and you can get a 17 
inch for $99 from goodwill computers.

So how exactly DOES MS expect to stop the Linux folks from reverse 
engineering .NET apps?  Patents?  Giving up on the client side and moving to 
an ASP business model (toe to toe with AOL)?  Constant gratuitous 
compatability changes to try to prevent all those nasty GPL viruses from 
evolving an immunity to their new proprietary drug?  (Without, of course, 
being obvious enough to trigger a third antitrust trial after the 1995 and 
1998 ones...)

Just curious...

> Tony

Re: [OT] Threads, inelegance, and Java

[Ben Greear]

Aaron Lehmann wrote:
> 
> On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> > Just the fact that some people use Java (or any other language) does
> > not mean, that they don't care about "performance, system-design or
> > any elegance whatsoever" [2].
> 
> However, the very concept of Java encourages not caring about
> "performance, system-design or any elegance whatsoever". If you cared

System-design and elegance are easy to get
in Java, and in fact are independent of language.  Good c code will beat
Java in most cases, performance wise, but lately the difference has become
small enough not to matter for most applications.  Speed is not the most
important feature in a great many programs, otherwise we'd all be using
assembly still.

> about any of those things you would compile to native code (it exists
> for a reason). Need run-anywhere support? Distribute sources instead.

When was the last time you wrote a large cross-platform GUI that just
worked on other platforms, without any additional tweaking, after you
developed it on your Linux machine?

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: [OT] Threads, inelegance, and Java

[Russell Leighton]

Ben Greear wrote:
<snip>

> System-design and elegance are easy to get
> in Java, and in fact are independent of language.  Good c code will beat
> Java in most cases, performance wise, but lately the difference has become
> small enough not to matter for most applications.

Rather a sweeping statement.

I don't buy it...depends what you mean by "most applications".
I bet 90% of the  "most"  would be better served by
being written in Visual Basic (or Perl, or Python, or PHP pick your poison
for a very high level language)...and if you really care about
resource usage and/or performance you don't
want a very high high level language and Java does not leap to mind
as part of the set of credible alternatives.

I had a company that gaves us a tech briefing of their system.
They dumped mega-bucks into multiple Sun E10000s they needed to run their Java apps...
the were proud of their scalable design, just add more hardware!
True, the high level design was fine and trivially scalable w/more hw BUT
what a waste, if their app was done in C they could have
had it run faster and it would have cost them significantly less (in the millions of $$).
The lack of a good operating system _dependent_ interface
makes running fast hard in Java when you need to do IO...
yes, there is always JNI so you can add a little C to mmap a file or whatever,
but if you are doing that, you slide down the slippery slope of justifying Java.
That's just one aspect, don't get me started (e.g., memory mangement, method call
overhead, type checking, yuk).

> Speed is not the most
> important feature in a great many programs, otherwise we'd all be using
> assembly still.

Agreed.

It's a judgement call.

I just think that Java is not particularly good at anything (jack of all trades master of none).


--
---------------------------------------------------
Russell Leighton    russell.leighton@247media.com
---------------------------------------------------

Re: [OT] Threads, inelegance, and Java

[Davide Libenzi]

On 20-Jun-2001 Russell Leighton wrote:
> Ben Greear wrote:
> <snip>
> 
>> System-design and elegance are easy to get
>> in Java, and in fact are independent of language.  Good c code will beat
>> Java in most cases, performance wise, but lately the difference has become
>> small enough not to matter for most applications.
> 
> Rather a sweeping statement.
> 
> I don't buy it...depends what you mean by "most applications".
> I bet 90% of the  "most"  would be better served by
> being written in Visual Basic (or Perl, or Python, or PHP pick your poison
> for a very high level language)...and if you really care about
> resource usage and/or performance you don't
> want a very high high level language and Java does not leap to mind
> as part of the set of credible alternatives.
> 
> I had a company that gaves us a tech briefing of their system.
> They dumped mega-bucks into multiple Sun E10000s they needed to run their
> Java apps...
> the were proud of their scalable design, just add more hardware!
> True, the high level design was fine and trivially scalable w/more hw BUT
> what a waste, if their app was done in C they could have
> had it run faster and it would have cost them significantly less (in the
> millions of $$).

1) HW is cheaper than software engineers time

2) to find Java developers is easier than to find C developers

3) the ETA of the same project developed in Java is shorter than the same
        project done in C


This depend heavily on the type of project but these are points that every
software Co. has to face when starting a new project.




- Davide

Re: [OT] Threads, inelegance, and Java

[Larry McVoy]

On Wed, Jun 20, 2001 at 08:12:29AM -0700, Ben Greear wrote:
> Aaron Lehmann wrote:
> > On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
> > > Just the fact that some people use Java (or any other language) does
> > > not mean, that they don't care about "performance, system-design or
> > > any elegance whatsoever" [2].
> > 
> > However, the very concept of Java encourages not caring about
> > "performance, system-design or any elegance whatsoever". If you cared
> 
> System-design and elegance are easy to get
> in Java, and in fact are independent of language.  Good c code will beat
> Java in most cases, performance wise, but lately the difference has become
> small enough not to matter for most applications.  Speed is not the most
> important feature in a great many programs, otherwise we'd all be using
> assembly still.
> 
> > about any of those things you would compile to native code (it exists
> > for a reason). Need run-anywhere support? Distribute sources instead.
> 
> When was the last time you wrote a large cross-platform GUI that just
> worked on other platforms, without any additional tweaking, after you
> developed it on your Linux machine?

When was the last time you did the same thing?  Nobody gets client side
Java to work properly across all the platforms without a lot of tweaking.

And the last time we did it was recently, the entire BK GUI is in tcl/tk,
almost 20,000 lines of code (that would be 80,000 for you Java fans),
and the GUI has revision history browsers, changeset browsers, source
browsers, check in tools, diff tools, rename tools, file mergers, etc.
It's pretty complete and it typically comes very close to just working
across all platforms.  The sort of differences we deal with are little
things like the font names not being the same on Unix/NT.  Java would
*love* to be that good, it's nowhere near.

Here's some more stats.  We fired up a Java based file merge tool on a
file and then did the same thing with our tk based one.  The Java tool
took 38MB to do the same merge as the tk one; the tk one took 4MB.  And
before you start saying "well, the tk one must be simplistic", we hand
the Guiffy guy our test cases all the time and it fails them.  So it's
a pretty reasonable apples to apples, in fact, it's slanted in favor of
the Java tool.

We couldn't believe that Java was really that bad so our GUI guy, Aaron
Kushner, sat down and rewrote the revision history browser in Java.
On a 500 node graph, the Java tool was up to 85MB.  The tk tool doing
the same thing was 5MB.  Note that we routinely run the tool on files 
with 4000 nodes, we can't even run the Java tool on files that big,
it crashes.

You could argue that we need custom widgets to do what we are doing,
but that's lame.  We don't need any custom widgets for tk, in fact, 
we are using straight tk, no extensions.

So, yeah, we have done what you think we haven't done, and we've tried
the Java way, we aren't making this stuff up.  We run into Java fanatics
all the time and when we start asking "so what toolkits do you use" we
get back "well, actually, err, umm, none of them are any good so we write
our own".  That's pathetic.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [OT] Threads, inelegance, and Java

[Russell Leighton]

....this is getting way OT...everyone wants make Linux work well for all programming
methods as long as poor compromises are not made...most of the people that matter
on this list can define "poor" so I am not worried about the future of Linux.

Last 0.02 below and this should be take off the list.

Davide Libenzi wrote:

>

<snip>

> 1) HW is cheaper than software engineers time

Most of the time this is true...kinda depends on the project and other constraints.
I'd hate to make a system that has poor $$/hw when scaling it just because the programmers are lazy.

>
>
> 2) to find Java developers is easier than to find C developers

Good developers are hard to find , period.

My experience is that there are a whole bunch of people out there that have
ONLY coded Java and they should not be let near a computer.

>
>
> 3) the ETA of the same project developed in Java is shorter than the same
>         project done in C
>

Very debatable ... and the point I was making was not about C ... for example, Java servlets and JSP
are probably a very big part of the Java app "world"...I'd take PHP over that
any day for apps that require a DHTML GUI on a database...just depends on what you
are doing and your requirements...would you write a device driver in Java?...
what I find stunning about Java (and I said this before) is that :
"Java is not particularly good at anything (jack of all trades master of none)."

>
> This depend heavily on the type of project but these are points that every
> software Co. has to face when starting a new project.
>

Yup...hard decisions. No silver bullet.

>
> - Davide

--
---------------------------------------------------
Russell Leighton    russell.leighton@247media.com
---------------------------------------------------

Re: [OT] Threads, inelegance, and Java

[Tony Hoyle]

Davide Libenzi wrote:


> 1) HW is cheaper than software engineers time


Compared to E1000s???  You must be talking about some *really* expensive 
engineers!


> 2) to find Java developers is easier than to find C developers


Depends on where you are in the world.  It's certainly not true here 
(everyone knows C/C++...  Haven't had a java developer apply for a job 
in months).

 
> 3) the ETA of the same project developed in Java is shorter than the same
>         project done in C


Depends on the developers.  Good developers can churn out the same 
project to roughly the same timescale in any language (except possibly 
assembly).

Java is useful if you need the cross platform bit & the target users 
aren't technically savvy enough to recompile.  For an in-house app where 
you control the hardware you'd be better off using a C/C++/RAD & doing 
it native.

Tony


(Just came back from a .NET conference...  MS are currently rewriting 
all their apps in bytecode... whoopee...  They're even porting *games* 
to run on it.  I can see it now 'MS Flight Simulator .NET' (Requires 
quad Pentium 4 1.6Ghz minimum) :-o )

Tony

-- 
"Two weeks before due date, the programmers work 22 hour days
  cobbling an application from... (apparently) one programmer
  bashing his face into the keyboard." -- Dilbert

tony@hoyle.geek 
	http://www.tony.hoyle.geek
tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: [OT] Threads, inelegance, and Java

[Martin Dalecki]

Rob Landley wrote:

> The same arguments were made 30 years ago about writing the OS in a high
> level language like C rather than in raw assembly.  And back in the days of
> the sub-1-mhz CPU, that really meant something.

And then those days we are still writing lot's of ASM in kernels...

> I don't know about that.  The 8 bit nature of java bytecode means you can
> suck WAY more instructions in across the memory bus in a given clock cycle,
> and you can also hold an insane amount of them in cache.  These are the real

What about the constant part of instructions? What about the alignment
characteristics
of current CPU busses?

> performance limiting factors, since the inside of your processor is clock
> multiplied into double digits nowdays, and that'll only increase as die sizes
> shrink, transistor budgets grow, and cache sizes get bigger.
> 
> In theory, a 2-core RISC or 3-core VLIW processor can execute an interpretive
> JVM pretty darn fast.  Think a jump-table based version (not quite an array

Bullshit! In theory the JVM resembles some very very old instruction
set well suited for a CISC CPU. In esp. the leak of registers is even
bigger
then on i386 arch. And bloody no compiler will be able to optimize this
sanely... And then there arises the problem of local variable management
and
so on. There where attempts already made to design a CPU according to
this
specs. As far as one can see they have all failed. Even Sun himself gave
up
his design. The compact instruction set is due to Javas inheritance from
the embedded world - nothing else. Too compact instruction set designs
make
for very nasty instruction decoders and therfore slow CPUs. This
complexity can be better overcome by the IBM memmory compressor chip
then in the instruction set itself.

> Or if you like the idea of a JIT, think about transmeta writing a code
> morphing layer that takes java bytecodes.  Ditch the VM and have the
> processor do it in-cache.

Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No
matter
what they try to make you beleve. A venerable classical desing like
the Geode outperforms them in any terms. There is simple significant
information
lost between compiled code and source code. Therefore no JIT compiler
in this world will ever match the optimization opportunities of a
classic
C compiler! IBM researched opportunities for code morphing long ago
before
Transmeta come to live - they ditched it for good reasons. Well the
actual
paper states that the theorethical performance was "just" 20% worser
then
a comparable normal design. Well "just 20%" is a half universe diameter
for
CPU designers.

> This doesn't mean java is really likely to outperform native code.  But it
> does mean that the theoretical performance problems aren't really that bad.
> Most java programs I've seen were written by rabid monkeys, but that's not
> the fault of the language. [1].

Think garbage collector - this explains nearly 90% of the performance
problems
Java code has. The remaining 10% are still by a factor of 10 bad in
comparision to classical code. Think zero copy on write - most Java code
induces insane
amounts of copyiing data around for no good reaons (Sring class and
friends
for example). Java code will never ever perform well.
 
> How many instructions does your average processor really NEED?  MIT's first
> computer had 4 instructions: load, save, add, and test/jump.  We only need 32
> or 64 bits for the data we're manipulating.  8 bit code is a large part of
> what allowed people to write early video games in 8k of ram.

Ton's of them. Please just remember how the RISC instruction set designs
evolved
over time. It was no accident!

-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 15:27, Mike Harrold wrote:
> Martin Dalecki wrote:>
>
> > Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No
> > matter
> > what they try to make you beleve. A venerable classical desing like
> > the Geode outperforms them in any terms. There is simple significant

>[root@mobile1 /root]# cat /proc/cpuinfo
>processor       : 0
>vendor_id       : CyrixInstead
>cpu family      : 5
>model           : 7
>model name      : Cyrix MediaGXtm MMXtm Enhanced
>stepping        : 4
>fdiv_bug        : no
>hlt_bug         : no
>sep_bug         : no
>f00f_bug        : no
>coma_bug        : no
>fpu             : yes
>fpu_exception   : yes
>cpuid level     : 2
>wp              : yes
>flags           : fpu msr cx8 cmov 16 mmx cxmmx
>bogomips        : 46.89

Let's just say I haven't exactly been thrilled with the performance of the 
geode samples we've been using at work.  I have a 486 at home that 
outperforms this sucker.  Maybe it's clocking itself down for heat reasons, 
but it really, really sucks.  (Especially since I'm trying to get it to do 
ssl.)

And yes, we're thinking about transmeta as a potential replacement for the 
next generation hardware.  We're also looking around for other (x86 
compatable) alternatives...

> > Well the actual paper states that the theorethical performance was "just" 
> > 20% worser then a comparable normal design. Well "just 20%" is a half 
> > universe diameter for CPU designers.

In the case of transmeta, that's in exchange for a third processor core, 
which is probably worth something.

20% is only about 3 months of moore's law.  90% of processor speed 
improvements over the past few years have been die size shrinks.  You could 
clock a 486 at several hundred mhz with current manufacturing techniques, and 
get better performance out of it than low end pentiums.  (Somebody did it 
with a bottle of frozen alcohol and got themselves injured, but was managing 
a quite nice quake frame rate before the bottle exploded.)  And that's not 
counting the fact a pentium has twice as many pins to suck data through...

And I repeat, if you're clocking the processor over 10x the memory bus rate, 
your cache size and your memory bus become fairly important limiting factors. 
 (Modern processors are much more efficient about using the memory bus, doing 
bursts and predictive prefetches and all.  But that's a seperate issue.)

Look at pentium 4.  Almost all the work done there was simply so they could 
clock the sucker higher, because Intel uses racy logic in their designs and 
had to break everything down into really small pipeline stages to get the 
timing tolerances into something they could manufacture above 1 ghz.  It's AT 
LEAST 20% slower per clock than a PIII or Athlon.  It's all noise compared to 
manufacturing advances shrinking die sizes and reducing trace lengths and 
capacitance and all that fun stuff...

> So what? Crusoe isn't designed for use in supercomputers. It's designed
> for use in laptops where the user is running an email reader, a web

Not just that, think "cluster density".

142 processors per 1U, air cooled, running around 600 mhz each.  The winner 
hands down in mips per square foot.  (Well, I suppose you could do the same 
thing with arm, but I haven't seen it on the market yet.  I may not have been 
paying attention...)

> browser, a word processor, and where the user couldn't give a cr*p about
> performance as long as it isn't noticeable (20% *isn't* for those types
> of apps), but where the user does give a cr*p about how long his or her
> battery lasts (ie, the entire business day, and not running out of power
> at lunch time).

Our mobiles aren't (currently) battery powered, but a processor that doesn't 
clock itself down to 46 bogomips when it's running without a fan is a GOOD 
thing if you're trying to pump encrypted bandwidth through it at faster than 
350 kilobytes per second.  (The desktop units are getting 3.5 megs/second 
running the same code...)

> Yes, it *can* be used in a supercomputer (or more preferably, a cluster
> of Linux machines), or even as a server where performance isn't the
> number one concern and things like power usage (read: anywhere in
> California right now ;-) ), and rack size are important. You can always
> get faster, more efficient hardware, but you'll pay for it.

It's still not power, it''s heat.  You can run some serious voltage into a 
rack pretty easily, but it'll melt unless you bury the thing in fluorinert, 
which is expensive.  (Water cooling of an electrical applicance is NOT 
something you want to be anywhere near when anything goes wrong.)

Processors in a 1U are tied together by a PCI bus or some such.  The latency 
going from one to another is very low.  Processors in different racks are 
tied together by cat 5 or myrinet or some such, and have a much higher 
latency due to speed of light concerns.  A tightly enough coupled cluster can 
act like NUMA, which can deal with a lot more applications than high-latency 
clustering can.  (There hasn't been as much push for research here because 
it's been too expensive for your average grad student to play with, but now 
that the price is coming down...)

> Remember, the whole concept of code-morphing is that the majority of
> apps that people run repeat the same slice of code over and over (eg,
> a word processor). Once crusoe has translated it once, it doesn't need
> to do it again. It's the same concept as a JIT java compiler.

Except code morphing's translation happens about when you suck stuff in from 
main memory into the L1 or L2 cache, which is happening WAY slower than the 
inside of the processor is dealing with anyway, so basically it gives the 
processor extra work to do exactly when it's likely to be spending time on 
wait states...

> /Mike - who doesn't work for Transmeta, in case anyone was wondering... :-)

Neither does

Rob.

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
> Mike Harrold wrote:
>
> Well the transmeta cpu isn't cheap actually.

Any processor's cheap once it's got enough volume.  That's an effect not a 
cause.

> And if you talk about
> super computing, hmm what about some PowerPC CPU variant - they very
> compettetiv in terms of cost and FPU performance! Transmeta isn't the
> adequate choice here.

You honestly think you can fit 142 PowerPC processors in a single 1U, air 
cooled?

Liquid air cooled, maybe...

> Well both of those concepts fail in terms of optimization due
> to the same reason: much less information is present about
> the structure of the code then during source code compilation.

LESS info?

Anybody wanna explain to me how it's possible to do branch prediction and 
speculative execution at compile time?  (Ala iTanium?)  I've heard a few 
attempts at an explanation, but nothing by anybody who was sober at the 
time...

You have less time to work, but you actually have MORE info about how it's 
actually running...

> Additionaly there may be some performance wins due to the
> ability of runtime profiling (anykind thereof), however it still remains
> to be shown that this performs better then statically analyzed code.

Okay, I'll bite.  Why couldn't a recompiler (like MetroWerks stuff) do the 
same static analysis on large code runs that GCC or some such could do if you 
give it -Oinsane and let it think for five minutes about each file?

Obviously the run-time version isn't going to spend the TIME to do that.  But 
claiming the information to perform these actions isn't available just 
because your variables no longer have english names...

> > /Mike - who doesn't work for Transmeta, in case anyone was wondering...
> > :-)
>
> /Marcin - who doesn't bet a penny on Transmeta

/Rob, who still owns stock in Intel of all things.

Rob

Re: [OT] Threads, inelegance, and Java

[Henning P. Schmiedehausen]

Aaron Lehmann <aaronl@vitelus.com> writes:

>On Wed, Jun 20, 2001 at 09:00:47AM +0000, Henning P. Schmiedehausen wrote:
>> Just the fact that some people use Java (or any other language) does
>> not mean, that they don't care about "performance, system-design or
>> any elegance whatsoever" [2].

>However, the very concept of Java encourages not caring about
>"performance, system-design or any elegance whatsoever". If you cared

Care to elaborate? It's an application programming language, not a
kernel hacker language, you know.

I won't call Java the perfect solution for everything, but it's an
useful tool for a certain type of applications.

>for a reason). Need run-anywhere support? Distribute sources instead.
>Once they are compiled they won't need to be reinterpreted on every
>run.

Thanks buddy. I've seen too many "#ifdef _SOLARIS_ || _LINUX &&
!_X86_" definition deserts to not wanting to do this again. Portability 
without os-specific tweaks for more than two or three platforms is a dream.

And most if not all commercial platforms don't come with perl, python,
tcl/tk or anything else installed. Many even without a (C-)compiler. 
Most without a C++-compiler.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [OT] Threads, inelegance, and Java

[Henning P. Schmiedehausen]

Davide Libenzi <davidel@xmailserver.org> writes:

>On 20-Jun-2001 Russell Leighton wrote:
[...]
>> I had a company that gaves us a tech briefing of their system.
>> They dumped mega-bucks into multiple Sun E10000s they needed to run their
>> Java apps...
>> the were proud of their scalable design, just add more hardware!
>> True, the high level design was fine and trivially scalable w/more hw BUT
>> what a waste, if their app was done in C they could have
>> had it run faster and it would have cost them significantly less (in the
>> millions of $$).

>1) HW is cheaper than software engineers time

>2) to find Java developers is easier than to find C developers

>3) the ETA of the same project developed in Java is shorter than the same
>        project done in C

4) The Java project is easier ported from e.g. Windows to Linux or
   Solaris to Windows.

Amen. You're right on spot. HW is cheap. Even E10K are cheap
(relatively seen. ;-) )

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [OT] Threads, inelegance, and Java

[William T Wilson]

On Wed, 20 Jun 2001, Aaron Lehmann wrote:

> However, the very concept of Java encourages not caring about
> "performance, system-design or any elegance whatsoever". If you cared
> about any of those things you would compile to native code (it exists

Native code does not help performance much and it doesn't help elegance or
system design at all.

Programmers put incredible amounts of effort into design with C-related
languages because they have to.  If they don't their program will not
work.  Java makes it easy to write bad code that (mostly) works.  This
might mean that the average quality of Java code is not as good as it
might be.  But it's not a good reason not to write in Java.

Programmers that put the same amount of effort into their Java code that
they would have in C/C++ will write better programs faster than they would
have in C.  The fact that most programmers will not do this is not the
fault of the language, but the programmers.

> for a reason). Need run-anywhere support? Distribute sources instead.

Distributing source gives you run-anywhere support provided that everyone
you distribute to has the same compiler that you do and that you haven't
missed any platform specific endianness, word size or type definition
problems, and that your program doesn't require any I/O that isn't in the
standard libraries, especially graphics.

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 18:07, J . A . Magallon wrote:
> On 20010620 Rob Landley wrote:

> What do you worry about caches if every bytecode turns into a jump and more
> code ?

'cause the jump may be overlappable with extra execution cores in RISC and 
VLIW?

I must admit, I've never actually seen somebody try to assembly-level 
optimize a non-JIT java VM before.  JIT always struck me as a bit of a 
kludge...

> And that native code is not in a one-to-one basis with respect to
> bytecode, but many real machine code instructions to exec a bytecode op ?

Sure.  But if they're honestly doing real work, that's ok then.  (If they're 
setting up and tearing down unnecessary state, that's bad.  I must admit the 
friction between register and stack based programming models was pretty bad 
in the stuff I saw back around JavaOS, which was long enough ago I can't say 
I remember the details as clearly as I'd like...)

Then again JavaOS was an abortion on top of Slowaris.  Why they didn't just 
make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots 
off a single floppy", I'll never know.  I mean, they were using green threads 
and a single task for all threads ANYWAY...  (Actually, I know exactly why.  
Sun thinks in terms of Solaris, even when it's totally the wrong tool for the 
job.  Sigh...)

Porting half of Solaris to Power PC for JavaOS has got to be one of the most 
peverse things I've seen in my professional career.

> I have seen school projects with interfaces done in java (to be 'portable')
> and you could go to have a coffee while a menu pulled down.

Yeah, but the slowness there comes from the phrase "school project" and not 
the phrase "done in java".  I've seen menuing interfaces on a 1 mhz commodore 
64 that refreshed faster than the screen retrace, and I've WRITTEN java 
programs that calculated animated mathematical function plots point by point 
in realtime on a 486.

> Would you implement a search funtion into a BIG BIG database in java ?

You mean spitting out an SQL request that goes to a backend RDMS?  I've done 
it.  (Via MQSeries to DB2.)

Interestingly, a rather large chunk of DB2 itself seems to be implemented in 
Java  Dunno how much, though.  Probably not the most performance critical 
sections.  But it uses a heck of a lot of it...

> No, you give a java interface to C or C++ code.

A large part of this is "not reinventing the wheel".

Also, I'd like to point out that neither Java 1.0 nor Java 1.1 had an API to 
truncate an existing file.  (I pointed that out to Mark English at Sun back 
when I worked at IBM, and apparently nobody'd ever noticed it before me.  
Fixed in 1.2, I'm told.)

> Until java can be efficiently compiled, it is no more than a toy.

I haven't played with Jikes.

> Then why do you use Java ? If you just write few objects with many methods
> you are writing VisualBasic.

That was below the belt.  I'm trying to figure out if you've just violated a 
corolary of Godwin's law with regards to language discussions, but I'll let 
it pass and answer seriously.

Because used that way, Java doesn't suck nearly as badly as visual basic 
does?  (My cumulative life experience trying to program in visual basic adds 
up to about three hours, so I don't consider myself an authority on it.  But 
I've had enough exposure to say it sucks based on actually trying to use it.) 
 That and it was developed on OS/2 to be deployed on (at least) windows 95, 
98, and power macintosh?

I still had threading inherent in the language.  The graphics() class is 
actually a fairly nice API for doing simple 2d line drawing stuff in a 
portable way.  (It is too, except for fonts.  If you don't use any 
heavyweight AWT objects, and you're religious about using fontmetrics to 
measure your text, you can actually get pretty portable displays.)  I still 
had the GOOD bits of C++ syntax without having to worry about conflicting 
virtual base classes.  It's TRULY object oriented, with metaclasses and 
everything.

> See above. Traversing a list of objects to draw is not time consuming,
> implementing a zbuffer or texturing is. Try to implement a zbuffer in java.

I'll top that, I tried to implement "deflate" in java 1.0.  (I was porting 
info-zip to java when java 1.1 came out.

Yeah, the performance sucked.  But the performance of IBM's OS/2 java 1.0 jdk 
sucked compared to anything anybody's using today (even without JIT).

> The problem with java is that people tries to use it as a general purpose
> programming language, and it is not efficient. It can be used to organize
> your program and to interface to low-level libraries written in C. But
> do not try to implement any fast path in java.

I once wrote an equation parser that took strings, substituted values for 
variables via string search and replace, and performed the calculation the 
string described.  It did this for every x pixel in a 300 pixel or so range 
to get the resulting y value, then iterated through the array thus created 
and played connect the dots to graph the function.  On a 486 it could update 
the display about four times a second as different values were plugged in.

That may not have been nearly as fast as it would have been in C, but it was 
fast enough for me.  (And most of that was the darn string creation to 
substitue in the values, but I never got around to doing a more efficient 
variable lookup table method because I didn't have to, the performance was 
good enough.)

> If java or pyton were so efficient, you could write a ray-tracer or a
> database search engine in java or python, etc. Look, write it in java, not
> use a java interface to a binary module.

And it'd be even faster if you wrote it in hand optimized assembly.  Your 
point being?.

Somebody wrote a distributed.net key cracker in Java, which is about 5% as 
efficient as the hand-optimized assembly native code key crackers people 
usualy used.  Benchmarking one of those on a pentium desktop, it still beat 
my little 486 laptop using the native thing, which had been the height of 
technology about six years earlier.  And I can leave the java key cracker 
running for an hour or two in a web browser at the local library without 
anyone getting too upset.  I can't do that with a native one.  (What they 
object to is installing software, you see.  Not running it.)

I'm upset that Red Hat 7.1 won't install on that old laptop because it only 
has 24 megs of ram and RedHat won't install in that.  I haven't heard anybody 
else complain about that.  (Their questionable compiler descisions, sure.  
The security, of course.  The fact they will no longer install in 16 megs of 
ram, no.)

There's a gameboy emulator written in java out on the net somewhere that 
plays gameboy games in a web page as fast as the original gameboys used to.  
I find that useful.

Attacking java because of the performance is like attacking C because its 
memory management system is held together with duct tape (stack overflows, 
memory leaks, wild pointers, all so easy to do in C).  It's a complete red 
herring if you ask me...

Rob

Re: [OT] Threads, inelegance, and Java

[Mike Harrold]

Martin Dalecki wrote:> 
> Rob Landley wrote:
> 
> > Or if you like the idea of a JIT, think about transmeta writing a code
> > morphing layer that takes java bytecodes.  Ditch the VM and have the
> > processor do it in-cache.
> 
> Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No
> matter
> what they try to make you beleve. A venerable classical desing like
> the Geode outperforms them in any terms. There is simple significant
> information
> lost between compiled code and source code. Therefore no JIT compiler
> in this world will ever match the optimization opportunities of a
> classic
> C compiler! IBM researched opportunities for code morphing long ago
> before
> Transmeta come to live - they ditched it for good reasons. Well the
> actual
> paper states that the theorethical performance was "just" 20% worser
> then
> a comparable normal design. Well "just 20%" is a half universe diameter
> for
> CPU designers.

So what? Crusoe isn't designed for use in supercomputers. It's designed
for use in laptops where the user is running an email reader, a web
browser, a word processor, and where the user couldn't give a cr*p about
performance as long as it isn't noticeable (20% *isn't* for those types
of apps), but where the user does give a cr*p about how long his or her
battery lasts (ie, the entire business day, and not running out of power
at lunch time).

Yes, it *can* be used in a supercomputer (or more preferably, a cluster
of Linux machines), or even as a server where performance isn't the
number one concern and things like power usage (read: anywhere in
California right now ;-) ), and rack size are important. You can always
get faster, more efficient hardware, but you'll pay for it.

Remember, the whole concept of code-morphing is that the majority of
apps that people run repeat the same slice of code over and over (eg,
a word processor). Once crusoe has translated it once, it doesn't need
to do it again. It's the same concept as a JIT java compiler.

/Mike - who doesn't work for Transmeta, in case anyone was wondering... :-)

Re: [OT] Threads, inelegance, and Java

[Martin Dalecki]

Mike Harrold wrote:
> So what? Crusoe isn't designed for use in supercomputers. It's designed
> for use in laptops where the user is running an email reader, a web
> browser, a word processor, and where the user couldn't give a cr*p about
> performance as long as it isn't noticeable (20% *isn't* for those types
> of apps), but where the user does give a cr*p about how long his or her
> battery lasts (ie, the entire business day, and not running out of power
> at lunch time).

I'm just to good in remembering the academing discussion about
code morphing beeing a way to get more performance out of a chip
design. They where claiming, that due to the fact they could make
the underlying chip design much simpler and VLIW, the performance offset
by the emulation wouldn't be smaller than the performance win
in therms of a suprerior underlying chip architecture.
This was set off to provide compensation for the biggest hurdle
of VLIW design - insane code size and partially huge memmory
bus bandwidth designs due to this. (Why do you think the itanim
sucks on integer performance?)
After this turned out the be the fact in reality - IBM dropped
the developement of code morphing chips. Well transmeta turned
to claims that the main advantage of it's design is much smaller
power consumption. Well but in relity underclocked modern
design optimized for power consumtions beat the transmeta
chip easly: Geode, and the recently announced VIA chip to name a few.
In comparision to chip design esp. targetted at low power consumtion
the transmeta chip is laughable: this ARM please! My psion
beats *ANY* chip from them by huge magnitude.

> Yes, it *can* be used in a supercomputer (or more preferably, a cluster
> of Linux machines), or even as a server where performance isn't the
> number one concern and things like power usage (read: anywhere in
> California right now ;-) ), and rack size are important. You can always
> get faster, more efficient hardware, but you'll pay for it.

Well the transmeta cpu isn't cheap actually. And if you talk about
super computing, hmm what about some PowerPC CPU variant - they very
compettetiv in terms of cost and FPU performance! Transmeta isn't the
adequate choice here.

> Remember, the whole concept of code-morphing is that the majority of
> apps that people run repeat the same slice of code over and over (eg,
> a word processor). Once crusoe has translated it once, it doesn't need
> to do it again. It's the same concept as a JIT java compiler.

Well both of those concepts fail in terms of optimization due
to the same reason: much less information is present about
the structure of the code then during source code compilation.
And therefore usually the performance of any kind of JIT compiler
*sucks* in comparision to classical sophisticated compilers.
Additionaly there may be some performance wins due to the
ability of runtime profiling (anykind thereof), however it still remains
to be shown that this performs better then statically analyzed code.

> /Mike - who doesn't work for Transmeta, in case anyone was wondering... :-)

/Marcin - who doesn't bet a penny on Transmeta

Re: [OT] Threads, inelegance, and Java

[Pete Zaitcev]

> This [code morphing and binary tranlation]
>  was set off to provide compensation for the biggest hurdle
> of VLIW design - insane code size and partially huge memmory
> bus bandwidth designs due to this. (Why do you think the itanim
> sucks on integer performance?)

First, Merced does not suck on integer performance.
It does about 300 SPEC CPU2000 at 733MHz, give or take,
subject to compiler improvements.
That blows all RISCs out of the water (except Alpha, yet.
The best result they submitted is 511 base 533 peak
at 833MHz).

> [...] Well but in relity underclocked modern
> design optimized for power consumtions beat the transmeta
> chip easly: Geode, and the recently announced VIA chip to name a few.

Man, where do you get this falsehood. TM-5400 is way, way
faster than Geode (several times for any benchmark).
This is exactly the reason why Transmetians love to
showcase DVD playing and other performance related
stuff - it is where they beat Geode. Geode's performance
is quite adequate for kiosk/POS app and it's a formiddable
competitor for anything that needs no performance.

> In comparision to chip design esp. targetted at low power consumtion
> the transmeta chip is laughable: this ARM please! My psion
> beats *ANY* chip from them by huge magnitude.

"Beats" by what metric? Sucks harder?

-- Pete

Re: [OT] Threads, inelegance, and Java

[Tony Hoyle]

Rob Landley wrote:

> So how exactly DOES MS expect to stop the Linux folks from reverse 
> engineering .NET apps?  Patents?  Giving up on the client side and moving to 
> an ASP business model (toe to toe with AOL)?  Constant gratuitous 
> compatability changes to try to prevent all those nasty GPL viruses from 
> evolving an immunity to their new proprietary drug?  (Without, of course, 
> being obvious enough to trigger a third antitrust trial after the 1995 and 
> 1998 ones...)

They probably *want* people to port the .NET VM to Linux.  You should 
have seen their diagrams...  Lots of pretty boxes saying how the various 
parts of .NET work and a small greyed out area at the bottom saying 
'Win32'.  They kept saying 'Cross platform' and 'Open standards' (the 
VM* has been submitted to ECMA apparently)....

Of course when that happens everyone will continue using MS software, 
but on top of their chosen OS.  MS make more $$$ (we keep buying 
Exchange, Office, etc. but running them on Linux) and they are happy. 
MS Exchange runs on AS400/Solaris/etc., so it becomes an 'Enterprise' 
solution that PHBs throughout the world inflict on us, and MS make even 
*more* $$$.

Tony

* aka. 'Common Language Runtime'
-- 
"Two weeks before due date, the programmers work 22 hour days
  cobbling an application from... (apparently) one programmer
  bashing his face into the keyboard." -- Dilbert

tony@hoyle.geek 
	http://www.tony.hoyle.geek
tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: [OT] Threads, inelegance, and Java

[Richard B. Johnson]

On Wed, 20 Jun 2001, Rob Landley wrote:

> On Wednesday 20 June 2001 13:03, Tony Hoyle wrote:
> 
> > (Just came back from a .NET conference...  MS are currently rewriting
> > all their apps in bytecode... whoopee...  They're even porting *games*
> > to run on it.  I can see it now 'MS Flight Simulator .NET' (Requires
> > quad Pentium 4 1.6Ghz minimum) :-o )
> 

Interesting... Hmmm. The first Flight Simulator to run on a PC
ran on a 4.47 MHz PC/XT. The core state-machine ran off the BIOS
timer-tick at 18.206 ticks/second. It was written in MASM by me.
The graphics was written by many PROGRAM EXCHANGE contributors and
was written in Turbo Pascal. I was the "SysOp" of that BBS system
in the days when the Internet was nothing more than a college-to
-college experiment. 

It required 256k or RAM and had the flight dynamics of a real
Cessna 150 airplane. It was, therefore, difficult to fly.
Once it was appropriated by M$, they removed the long-mode oscillations,
the spiral instability, the roll/yaw coupling, and most of the inertial
characteristics so that any kid could fly it.

Then they sold it to millions of kids, getting enough money to
buy out competition and control the new personal computer market.

Early on, they didn't even hide the appropriated code although
it needed to be booted directly. I disassembled the core and
found exactly what I had written. Things changed of course as
the product matured.

It's probably written in Threaded-Java now (he ducks behind his keyboard).
And, that's probably why it needs 4 CPUs and a 1.xx GHz clock.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: [OT] Threads, inelegance, and Java

[Tony Hoyle]

Richard B. Johnson wrote:


> It's probably written in Threaded-Java now (he ducks behind his keyboard).
> And, that's probably why it needs 4 CPUs and a 1.xx GHz clock.

s/Java/C#/

Same thing, but....


Tony

-- 
"Two weeks before due date, the programmers work 22 hour days
  cobbling an application from... (apparently) one programmer
  bashing his face into the keyboard." -- Dilbert

tony@hoyle.geek 
	http://www.tony.hoyle.geek
tmh@nothing-on.tv 
http://www.nothing-on.tv

Re: [OT] Threads, inelegance, and Java

[Daniel Phillips]

On Wednesday 20 June 2001 22:40, Richard B. Johnson wrote:
> Interesting... Hmmm. The first Flight Simulator to run on a PC
> ran on a 4.47 MHz PC/XT. The core state-machine ran off the BIOS
> timer-tick at 18.206 ticks/second. It was written in MASM by me.
> The graphics was written by many PROGRAM EXCHANGE contributors and
> was written in Turbo Pascal. I was the "SysOp" of that BBS system
> in the days when the Internet was nothing more than a college-to
> -college experiment.
>
> It required 256k or RAM and had the flight dynamics of a real
> Cessna 150 airplane.

I could have sworn I ran it on a 64K machine.

Now, how did Bruce Artwick and Sublogic fit into this?

--
Daniel

Re: [OT] Threads, inelegance, and Java

[Richard B. Johnson]

On Wed, 20 Jun 2001, Daniel Phillips wrote:

> On Wednesday 20 June 2001 22:40, Richard B. Johnson wrote:
> > Interesting... Hmmm. The first Flight Simulator to run on a PC
> > ran on a 4.47 MHz PC/XT. The core state-machine ran off the BIOS
> > timer-tick at 18.206 ticks/second. It was written in MASM by me.
> > The graphics was written by many PROGRAM EXCHANGE contributors and
> > was written in Turbo Pascal. I was the "SysOp" of that BBS system
> > in the days when the Internet was nothing more than a college-to
> > -college experiment.
> >
> > It required 256k or RAM and had the flight dynamics of a real
> > Cessna 150 airplane.
> 
> I could have sworn I ran it on a 64K machine.
>

Not unless you got the original version that did RS-232C "graphics"
on a CP/M Machine (Ampro Little Board). That ran with 48k usable.

The GUI using Turbo Pascal required a lot of RAM.
 
> Now, how did Bruce Artwick and Sublogic fit into this?
> 
> --
> Daniel
> 

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

RE: [OT] Threads, inelegance, and Java

[Holzrichter, Bruce]

>The GUI using Turbo Pascal required a lot of RAM.

:o)  Now adays that sounds kind of funny...

Did you have anything to do with the c-64 version as well.  Now that brings
back memories........
 

Re: [OT] Threads, inelegance, and Java

[Aaron Lehmann]

On Wed, Jun 20, 2001 at 08:12:29AM -0700, Ben Greear wrote:
> When was the last time you wrote a large cross-platform GUI that just
> worked on other platforms, without any additional tweaking, after you
> developed it on your Linux machine?

I'd say that would be the last time I wrote something in GTK. SDL has
similar portability.

RE: [OT] Threads, inelegance, and Java

[Richard B. Johnson]

On Wed, 20 Jun 2001, Holzrichter, Bruce wrote:

> 
> 
> >The GUI using Turbo Pascal required a lot of RAM.
> 
> :o)  Now adays that sounds kind of funny...
> 
> Did you have anything to do with the c-64 version as well.  Now that brings
> back memories........
>  

No. I never even had one. 


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: [OT] Threads, inelegance, and Java

[Alan Cox]

> This is exactly the reason why Transmetians love to
> showcase DVD playing and other performance related
> stuff - it is where they beat Geode. Geode's performance
> is quite adequate for kiosk/POS app and it's a formiddable

Geode is jut about capable of MPEG1. The VIA processors are extremely 
interesting in the price/performance positioning. Neither of them are going
to win a power consumption battle with an ARM

Re: [OT] Threads, inelegance, and Java

[Pete Zaitcev]

> Then again JavaOS was an abortion on top of Slowaris. [...]

This is a false statemenet, Rob. It was an abortion, all right,
but not related to Solaris in any way at all.

JavaOS existed in two flavours minimum, which had very little
in common. The historically first of them (Luna), was a home-made
executive with pretty rudimentary abilities. I must admit I am
not intimately familiar with its genesis. A part of it was related
to the JavaOS running on Sun 701 chip, but what came first,
I cannot tell. Second flavour of JavaOS was made on top of
Chorus, and, _I think_, used large parts of Luna in the the
JVM department, but it had decent kernel, with such novations
as a device driver interface :)

> make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots 
> off a single floppy", I'll never know.

Such a thing existed. I do not remember its proper name,
but I remember that it booted from hard disk. Floppy
was too small for it.

> Porting half of Solaris to Power PC for JavaOS has got to be one of the most 
> peverse things I've seen in my professional career.

I never heard of PPC port of either of JavaOSes, although
Chorus runs on PPC. Perhaps this is what you mean.

Solaris for PPC existed, but never was widespread.
It did not have JVM bundled.

> I'm upset that Red Hat 7.1 won't install on that old laptop because it only 
> has 24 megs of ram and RedHat won't install in that. [...]

You blew adding a swap partition, I suspect...

-- Pete

Re: [OT] Threads, inelegance, and Java

[Dan Kegel]

Russell Leighton wrote:
> The lack of a good operating system _dependent_ interface
> makes running fast hard in Java when you need to do IO...
> yes, there is always JNI so you can add a little C to mmap a file or whatever,

JDK 1.4 beta comes with a way to memory-map files, and various
other I/O improvements (like poll(); see http://www.jcp.org/jsr/detail/51.jsp).
Chris Smith will have some nio benchmarks up on http://www.jlinux.org/
next week or so showing how well their nonblocking network I/O performs.

Sun is slowly getting their act together on the I/O front with java.
Still, the competition from C# and for that matter gcj will probably be 
a good thing, keep 'em on their toes.

(Disclaimer: I served on the JSR-51 expert group, representing the linux 
point of view, kinda.)
- Dan

Re: [OT] Threads, inelegance, and Java

[Albert D. Cahalan]

Rob Landley writes:
> On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
>> Mike Harrold wrote:

>> super computing, hmm what about some PowerPC CPU variant - they very
>> compettetiv in terms of cost and FPU performance! Transmeta isn't the
>> adequate choice here.
>
> You honestly think you can fit 142 PowerPC processors in a single 1U,
> air cooled?

That 142 would be what, a SHARC DSP system? It sure doesn't look
like Transmeta's Crueso. The best I found was 6 and 8 per 1U:

"RLX has managed to tuck 24 servers into a 3U enclosure" --> 8/U
"WebBunker units can hold 12 processors [in 2U]" --> 6/U

For PowerPC I found 32/U to 40/U, in increments of 9U.
See www.mc.com for an example. The processor gets you 4 (four!)
floating-point fused multiply-add operations per cycle, typically
at 400 MHz. Being optimistic, that's a teraflop in 9U.

> Liquid air cooled, maybe...

Nope, plain old air or conduction.

If you're going to rant about off-topic junk, at least try to
throw in a few useful references so people can check facts and
maybe take advantage of whatever it is you're ranting about.
(yeah, yeah, sorry about the VGA console thing)

Re: [OT] Threads, inelegance, and Java

[Henning P. Schmiedehausen]

Tony Hoyle <tmh@magenta-netlogic.com> writes:

>'Win32'.  They kept saying 'Cross platform' and 'Open standards' (the 
>VM* has been submitted to ECMA apparently)....

Relax. That's their stunt at Sun. Once they killed the Java VM (that's
what they hope), they will not give a hoot about the "Standards" they
helped to create. Note that in all their "open" and "cross platform"
and "multi language" slides, the absence of Java screams loudly.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [OT] Threads, inelegance, and Java

[Jonathan Morton]

>  > I have seen school projects with interfaces done in java (to be 'portable')
>>  and you could go to have a coffee while a menu pulled down.
>
>Yeah, but the slowness there comes from the phrase "school project" and not
>the phrase "done in java".  I've seen menuing interfaces on a 1 mhz commodore
>64 that refreshed faster than the screen retrace, and I've WRITTEN java
>programs that calculated animated mathematical function plots point by point
>in realtime on a 486.

Sure, but the Commodore had highly-optimised code working for it.  I 
think I'm a long way beyong the "school project" stage, but I've had 
REAL difficulty getting Java to perform well.

As one of the assignments in my 1st-year CompSci course, we got to 
write a program which checked for balanced braces in a source file. 
We were supposed to do this in Java - at the time, the Blackdown 
1.1.8 JVM was current.  I and a classmate used a 160K C source file 
from a MUD as a test load.  He ran it multiple times on the Solaris 
system provided for 1st-year programming, I ran it on my Linux 486.

My first effort was a nice "clean" OOP-friendly implementation which 
made heavy use of Java's nice-looking String operators.  As anyone 
who has worked with Java will be able to guess, this was also an 
extremely slow and inefficient implementation.  I recall it took 
upwards of 2 minutes to parse that source file and confirm that it 
had properly-paired braces.  This on a machine which now handles DNS, 
e-mail, webcaching, webserving, and sometimes gateway duties for my 
other machines.

Much work later, I garnered an implementation that used more C-like 
operators and looked much messier, but ran 6 times quicker.  Most of 
the work went into eliminating object creation and destruction, which 
tickled Java's extremely slow garbage collection.  I still don't 
fully understand why free() has no equivalent in Java.  My classmate 
got his version running even faster, but I don't know how he managed 
it.

Then I quickly hacked up a C version of the same program using the 
same algorithm, and compiled it using GCC.  It immediately ran 6 
times quicker still, and consumed less than a 50th of the memory.

With 28Mb RAM, I could only run 4 copies of the Java program in 
parallel before the machine started thrashing, but the C version got 
to 20 copies before the terminal simply got too sluggish to start any 
more (the machine was not thrashing, it was just under severe load). 
All 20 copies completed in less time than a single instance of the 
original Java implementation.

Incidentally, I've used VB as well, and it's even worse.  I couldn't 
get a P75 to drive a stepper-motor at more than 4 steps per second, 
and that was hardly a complex algorithm.  Given that I learned basic 
programming techniques using BBC BASIC on a 2MHz 6502, I *know* 
that's pathetic even for interpreted BASIC.  When an ARM610 at 40MHz 
running interpreted BASIC can outperform highly-optimised 16-bit x86 
assembly on a 486SX/40, you know Acorn got their interpreter done 
better than M$ did.

>  > Until java can be efficiently compiled, it is no more than a toy.
>
>I haven't played with Jikes.

Nor have I.  But frankly, I don't care.  Neither C, nor C++, nor Java 
make good beginner's languages.  The former two are efficient and 
safe if handled with some care.  The latter is safe but not efficient 
even in an expert's hands.

>I still
>had the GOOD bits of C++ syntax without having to worry about conflicting
>virtual base classes.

Hmmmm...  a well-designed C++ system doesn't have to worry about that 
either.  C++'s features are only bad if misused - it's an expert's 
language for crying out loud.

>  > See above. Traversing a list of objects to draw is not time consuming,
>  > implementing a zbuffer or texturing is. Try to implement a zbuffer in java.
>
>I'll top that, I tried to implement "deflate" in java 1.0.  (I was porting
>info-zip to java when java 1.1 came out.
>
>Yeah, the performance sucked.  But the performance of IBM's OS/2 java 1.0 jdk
>sucked compared to anything anybody's using today (even without JIT).

That reminds me...  allocating a two-dimensional array in Java is a 
*real* *pain*.  You have to declare the darn thing as an array of 
arrays, and then allocate that array of arrays explicitly, and then 
loop through that bloody array and allocate each subarray 
individually!  The alternative is to allocate a one-dimensional array 
and use what amounts to heavy pointer arithmetic, which can't be 
cheap on the CPU.

>  > The problem with java is that people tries to use it as a general purpose
>>  programming language, and it is not efficient. It can be used to organize
>>  your program and to interface to low-level libraries written in C. But
>>  do not try to implement any fast path in java.
>
>I once wrote an equation parser that took strings, substituted values for
>variables via string search and replace, and performed the calculation the
>string described.  It did this for every x pixel in a 300 pixel or so range
>to get the resulting y value, then iterated through the array thus created
>and played connect the dots to graph the function.  On a 486 it could update
>the display about four times a second as different values were plugged in.
>
>That may not have been nearly as fast as it would have been in C, but it was
>fast enough for me.  (And most of that was the darn string creation to
>substitue in the values, but I never got around to doing a more efficient
>variable lookup table method because I didn't have to, the performance was
>good enough.)

I'd really like to see how you did that - my experience of Java is 
that you'd need some extremely clever code to handle such an 
operation even that fast.  I had to move my main 1st-year project 
from the 486 to a PowerBook (which benchmarks considerably faster 
than a P166/MMX) and Apple's JVM before it performed adequately for 
presentation.  Incidentally, that same project refused to compile on 
Sun's JDK under Solaris - oh, the irony.  My team received the 
runners-up prize for that effort.

>  > If java or pyton were so efficient, you could write a ray-tracer or a
>>  database search engine in java or python, etc. Look, write it in java, not
>>  use a java interface to a binary module.
>
>And it'd be even faster if you wrote it in hand optimized assembly.  Your
>point being?.

You can write a raytracer and a database in Java or Python all you 
like, or even VB if you're a masochist.  Just don't complain when it 
eats 5x the RAM and is 50x slower than the competition which uses 
bogstandard C or C++.  Raytracing is slow enough on state-of-the-art 
hardware and well-optimised C code, as it is.  From what I hear, 
databases need all the efficiency they can get too.

>Somebody wrote a distributed.net key cracker in Java, which is about 5% as
>efficient as the hand-optimized assembly native code key crackers people
>usualy used.  Benchmarking one of those on a pentium desktop, it still beat
>my little 486 laptop using the native thing, which had been the height of
>technology about six years earlier.  And I can leave the java key cracker
>running for an hour or two in a web browser at the local library without
>anyone getting too upset.  I can't do that with a native one.  (What they
>object to is installing software, you see.  Not running it.)

And this increases your chances of finding the key by very little for 
a significant amount of effort.  Big deal.

>I'm upset that Red Hat 7.1 won't install on that old laptop because it only
>has 24 megs of ram and RedHat won't install in that.  I haven't heard anybody
>else complain about that.  (Their questionable compiler descisions, sure. 
>The security, of course.  The fact they will no longer install in 16 megs of
>ram, no.)

SuSE 4.3 won't do a network install with less than 75Mb to it's name, 
but it'll install from disc in much less than that.  I persuaded an 
8Mb 486 to start running the Red Hat 6.1 installer by running fdisk, 
mkswap and swapon by hand from that nice little terminal they give 
you on tty2.  However it thrashed for several days before I told it 
to give up and used a spare machine with more RAM to perform the 
install.

>There's a gameboy emulator written in java out on the net somewhere that
>plays gameboy games in a web page as fast as the original gameboys used to. 
>I find that useful.

Fair enough.  Just remember that the PC you're running it on is 
hundreds of times more powerful than the machine it's emulating.  I'd 
like to see the same trick done for the Gameboy Advance though.

>Attacking java because of the performance is like attacking C because its
>memory management system is held together with duct tape (stack overflows,
>memory leaks, wild pointers, all so easy to do in C).  It's a complete red
>herring if you ask me...

Actually, it isn't.  An experienced coder can use techniques to avoid 
C's pitfalls by doing it right.  Java's performance and 
resource-hogging problems hurt everyone, even the experts.

Now, don't get me wrong here.  Java does have uses, in applications 
where fast development time and portability are more important than 
performance or resource utilisation.  However, that set of 
applications is a lot smaller than most Java defenders realise.

-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Re: [OT] Threads, inelegance, and Java

[Rob Landley]

On Wednesday 20 June 2001 23:13, Pete Zaitcev wrote:
> > Then again JavaOS was an abortion on top of Slowaris. [...]
>
> This is a false statemenet, Rob. It was an abortion, all right,
> but not related to Solaris in any way at all.

I worked on the sucker for six months at IBM in 1997.  I don't know if the 
code we worked on is the code you're thinking of, but we had a unix kernel 
(which my coworkers SAID was solaris) with a JVM running on top of it as the 
init task.  Ported to Power PC by some overseas IBM lab (might have been the 
japanese guys).  We had two flavors of it to test, one the Power PC build and 
one the Intel build, and to make the Intel build work first we installed 
Solaris for Intel.

Other fun little details included that when I left IBM it still couldn't read 
from the hard drive, so the entire system TFTP'd itself through the network 
at boot, including a compressed ramdisk image containing Lotus Desktop.  The 
machine required 64 megs of memory to run that (~32 megs or so of which was 
for the ramdisk, and no it didn't run executables straight out of the 
ramdisk, it copied them into MORE ram to run).

> JavaOS existed in two flavours minimum, which had very little
> in common. The historically first of them (Luna), was a home-made
> executive with pretty rudimentary abilities.

I believe that's what we were using, and that home-made executive was a 
stripped down version of the solaris kernel.

> Second flavour of JavaOS was made on top of
> Chorus, and, _I think_, used large parts of Luna in the the
> JVM department, but it had decent kernel, with such novations
> as a device driver interface :)

You haven't lived until you've seen java code, with inline assembly, claiming 
to be a video framebuffer device driver thing.  That sort of thing gives you 
a real appreciation for the portions of your life where you DON'T have to 
deal with that kind of thing.

I only had to go into there to debug stuff though, mostly I was working on 
the application end of things.  (Taking third party closed source 
beta-release nonsense from people who wanted a single point of contact with 
IBM who turned out to be someone in Poughkipsee who had quit the company a 
couple weeks back.  So it didn't work, we didn't have source, the people who 
supplied it wouldn't talk to us, and when we did trace a problem to the 
JavaOS code and reported it to Sun they went "we fixed that over a month ago 
and we've been sending you twice-weekly drops!"  But of course our codebase 
didn't sync with their codebase more than once a month or so because there 
was so much porting effort involved...

And you wonder why I quit...

> Such a thing existed. I do not remember its proper name,
> but I remember that it booted from hard disk. Floppy
> was too small for it.

Maybe.  Wouldn't have been nearly as big as JavaOS, though.  FAR better 
suited to an embedded system...

> > Porting half of Solaris to Power PC for JavaOS has got to be one of the
> > most peverse things I've seen in my professional career.
>
> I never heard of PPC port of either of JavaOSes, although
> Chorus runs on PPC. Perhaps this is what you mean.

It was called "JavaOS for Business"...

http://www.javaworld.com/javaworld/jw-05-1998/jw-05-idgns.javaos.html

And was killed about a year later...

http://news.cnet.com/news/0-1003-200-346375.html?tag=bplst

I worked on it for six months in the second half of 1997.

> Solaris for PPC existed, but never was widespread.
> It did not have JVM bundled.

We mostly used AIX on the PPC systems that weren't directly testing the new 
code.

> > I'm upset that Red Hat 7.1 won't install on that old laptop because it
> > only has 24 megs of ram and RedHat won't install in that. [...]
>
> You blew adding a swap partition, I suspect...

This was before it let me run fdisk or Disk Druid.  I'll try again this 
weekend...

> -- Pete

Rob

Re: [OT] Threads, inelegance, and Java

[Adam Sampson]

Rob Landley <landley@webofficenow.com> writes:

> > However, the very concept of Java encourages not caring about
> > "performance, system-design or any elegance whatsoever".
> The same arguments were made 30 years ago about writing the OS in a high 
> level language like C rather than in raw assembly.

30 years ago we didn't have C compilers that produce better code than
you can write by hand. ;)

-- 
Adam Sampson <azz@gnu.org>                  <URL:http://azz.us-lot.org/>