Messages in this thread | | | From | Rob Landley <> | Subject | Re: [OT] Threads, inelegance, and Java | Date | Wed, 20 Jun 2001 15:15:53 -0400 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |