Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Apple Inc. -- Ignore unavailable to you. Want to Upgrade?

To: Phillip C. Lee who wrote (10804)	4/3/1998 2:07:00 PM
From: George von Dassow	Respond to of 213177

Phil, (another off-topic about Java, sorry) Alomex' statement about the relative speed of just-in-time compiled Java versus C++ is accurate, at least with respect to computation-only code that uses primitives. I discussed this is in a couple of previous posts - see #10648 and #10117 if you are interested. I do all my work in Java now, and I wouldn't have switched of it were 20x slower than C++. I know this isn't terribly relevant to a stock board, but it came up in the context of whether Java and Rhapsody compete, which is relevant. To reiterate briefly, my experience is that certain Java library classes are INEXPLICABLY slow; to write fast code you have to avoid that stuff. Also, interface stuff is slow, and as yet it is quirky. But it's getting better. Also, yes Java does use pointers. It just doesn't let _programmers_ manipulate the pointers directly. Kind of analogous to references in C++. I don't know much about how the VM manages memory in detail, because each could be different. All they have to do is conform to a specified behavior. Also, Alomex in post 10793 said: just-in-time compilers (JIT) compile the byte code to native code on the fly. So it is possible to run Java without interpreting it. As a minor semantic detail, I'd say the job of ALL VMs, JIT or otherwise, is to compile the byte code to native code on the fly. The JIT VMs cache the native code, thus do not need to re-interpret. Depending on the extent to which your code is iterative and so forth, the JIT makes more or less difference in speed, and in my case, with a lot of iterative steps, the difference is 20-30 fold. Honest, Phil :) And finally, in response to Sam's question: 1) what Alomex said (#10802). 2) there are lots of very useful interpreted languages, like Lisp, Smalltalk, TCL, Python, Perl, Icon, AppleScript etc. Many of those can also be compiled. 3) I remember "the old basic days" a la my childhood friends the Vic20, the TI99-4A, and Trash-80s - numbered lines, single thread of execution, no functions... come to think of it, Java is not a bit like that. 4) Java isn't really interpreted in the sense that BASIC and Lisp are anyway. It is very misleading. There's a big difference between parsing the code at run time (like BASIC) and simply converting the Java byte code to native byte code at run time. 5) I honestly have yet to encounter a single thing that I can't do somehow in Java that I could do in C++, except for old habits, like pointer math. I used to do a lot of pointer math (probably why I did so much debugging). To reiterate something from a previous post, I avoided Java for a long time. I thought it all sounded pretty lame and useless. A colleague showed me some stuff he was working on, and I started to learn a little about the language for fun, and made some toy projects. I jumped the C++ ship pretty quick after that. - George Perhaps we should suppress the Java talk at this point, since it seems a lot of people on the thread see it as off topic?

To: Phillip C. Lee who wrote (10804)	4/3/1998 4:58:00 PM
From: Alomex	Read Replies (2) \| Respond to of 213177

How can any compiler take care of virtual machine when it runs without interpreter? It works as follows. You download bytecode that is executed initially on an interpreter while the JIT process is under way. A profiler finds out the methods used most often and compiles them into native code. Because of object encapsulation, you can have the methods of an object be executed outside the VM and just plug back the results into the VM. At the same time, agressive memory management impements an LRU policy on objects in memory. Since no user pointers are allowed, you can easily and efficiently rellocate objects in memory. What do you mean level 2 of cache? It seems to me that you are unfamiliar with how data and instructions are loaded from RAM into cache for fast access. Whenever a page of data is accessed, the cache management policy decides if the data will be copied into local cache and who it will displace. Yes, Java has no pointer, but it still needs memory swapping. You can minimize this swapping if you can rearrange data dynamically at run time. Java's lack of pointer and garbage collection abilities allow you to do just that in an efficient way. Actually, pointer is the quickest way and most efficient way to manipulate memory. Java has no pointer, but it still needs memory swapping. Only if you are accessing consecutive memory space. Otherwise, indirect addressing through an LRU policy will beat pointer addressing any time. Implementing such an scheme in C++ is devilishly complicated, because of pointers. In Java you get it (almost) for free with the Garbage Collection. Java is on the average about 20 times slower than c/c++ (stated in Java in a Nutshell book). That is interpreted, non-optimized Java. Here's a quote, from a more upto date source: HotSpot promises to rival native platform performance of C++ with so-called adaptive optimization, permitting Java code to run first in interpreted mode and then be analyzed and optimized to target the parameters of each platform, said Eric Chu, JavaSoft's Java Development Kit (JDK) product manager.