Welcome to the MacNN Forums.

cmoney · Jun 18, 2002, 02:59 PM

Posted this on the Powerbook forum, but maybe I'll get more responses here:

Okay, it's down to the wire now. I have a 20% ADC hardware discount that expires on June 20! and I need to decide whether to buy the 700MHz iBook or the new PB 667. I'm currently leaning towards the iBook for its cost, size and durability.
I do web applications work, so much of my work is spent writing Java servlets, JSP, testing code fragments, etc. I spend alot of time in JBuilder so screen real estate is important, but JBuilder's performance has been anything but quick on any Mac I've ever seen it run, which has kept me on the Windows version anyway.
What I ask from y'all is simple. Which will have better Java performance as far as compile and execution times? I'm not talking about applets or Swing applications, simply faceless Java servlets, JSPs, Javabeans, etc. and testing code fragments at the command line. I currently have an iBook 500, so if anybody would compare Java performance on those faster machines with my older machine, I'd really appreciate it!
My guess is that since it's memory and bus bandwidth intensive, the 667 will have the edge because of its 133MHz bus and larger cache.
Thanks alot!

V0ID · Jun 21, 2002, 05:30 AM

...and G4 processor.

Kristoff · Jun 21, 2002, 09:26 AM

<blockquote>quote:<hr />Originally posted by V0ID:
...and G4 processor.<hr /></blockquote>G4 wont help server-side java performance.

Perhaps it may help swing performance, but that's a stretch.

absmiths · Jun 21, 2002, 11:07 AM

<blockquote>quote:<hr />Originally posted by Kristoff:
 <blockquote>quote:<hr />Originally posted by V0ID:
...and G4 processor.<hr /></blockquote>G4 wont help server-side java performance.

Perhaps it may help swing performance, but that's a stretch.<hr /></blockquote>You're saying that a G3 and a G4 at the same clock speed will execute instructions at the same rate? That seems hard to believe. At any rate, since the AltiVec can handle a lot of the GUI code there will be more CPU available for CL stuff. I compared an iBook to a TiBook for command-line compiles and bought the TiBook instead.

The point is really moot, since the June 20th deadline has passed. What did you buy?

cmoney · Jun 21, 2002, 04:37 PM

<blockquote>quote:<hr />Originally posted by absmiths:
 <blockquote>quote:<hr />Originally posted by Kristoff:
 <blockquote>quote:<hr />Originally posted by V0ID:
...and G4 processor.<hr /></blockquote>G4 wont help server-side java performance.

Perhaps it may help swing performance, but that's a stretch.<hr /></blockquote>You're saying that a G3 and a G4 at the same clock speed will execute instructions at the same rate? That seems hard to believe. At any rate, since the AltiVec can handle a lot of the GUI code there will be more CPU available for CL stuff. I compared an iBook to a TiBook for command-line compiles and bought the TiBook instead.

The point is really moot, since the June 20th deadline has passed. What did you buy?<hr /></blockquote>Sorry, I originally posted this on the PowerBook forum and we started doing some benchmarks. Using the Xerces 1.4.4 library and the SAX sample (command line app, so it's pure Java processing, not dealing with Aqua's performance problems), a few people compiled the following results:

Cube 450/10.1.5: 500ms
Cube 450/Jaguar (JDK 1.4 pre-release): 410ms
iBook 500/10.1.5: 800ms
iBook 500/Jaguar (1.4): 590ms
Pismo 500: 570ms
TiBook 667: 493ms (and a second report of 415ms)
QS Dual G4 800: 314ms
iBook 700: 385ms

Non Macs:
Dell GX1 P3 1.2GHz: 290ms
Compaq P3/1GHz: 310ms
Sun E450/Dual 300MHz: 720ms

In the end, I ordered a PB 800, figuring it would be faster than either the iBook 700 or the PB667. The iBook 700 looked to be a little quicker than the PB667 so perhaps processor speed plays a bigger role in Java. (The sample app parsed through a 1k XML file, so I doubt memory or bus speed played a huge role.) Looks like Jaguar and JDK 1.4 help out quite alot too.

Besides, I didn't want to wait the 6 extra days to have a custom ordered iBook or PB667. :-) At $2559 for the PB800, it wasn't too bad anyway.

V0ID · Jun 21, 2002, 09:48 PM

Interesting. Could I get a look at that code, cmoney? Just out of curiosity.

<blockquote>quote:<hr />Originally posted by Kristoff:
G4 wont help server-side java performance.

Perhaps it may help swing performance, but that's a stretch.<hr /></blockquote>The difference between a G4 and G3 isn't just alitvec.

cmoney · Jun 21, 2002, 10:25 PM

<blockquote>quote:<hr />Originally posted by V0ID:
Interesting. Could I get a look at that code, cmoney? Just out of curiosity.
<hr /></blockquote>Sure. You can actually download it directly from <a href="http://xml.apache.org/dist/xerces-j/Xerces-J-bin.1.4.4.zip" target="_blank">http://xml.apache.org/dist/xerces-j/Xerces-J-bin.1.4.4.zip</a> .

The instructions we were benchmarking were:

<blockquote>quote:<hr />Go into the directory with these files (should be xerces-1_4_4), and type in:
java -classpath ./xerces.jar:./xercesSamples.jar sax.SAXCount data/personal.xml
It gives a time in milliseconds which is the time it took to parse the sample XML file. <hr /></blockquote>You can see the source code directly in /xerces-1_4_4/samples/sax/SAXCount.java.

V0ID · Jun 22, 2002, 01:04 AM

Cool, thanks!

absmiths · Jun 24, 2002, 09:29 AM

<blockquote>quote:<hr />Originally posted by cmoney:
Sorry, I originally posted this on the PowerBook forum and we started doing some benchmarks. Using the Xerces 1.4.4 library and the SAX sample (command line app, so it's pure Java processing, not dealing with Aqua's performance problems), a few people compiled the following results:
<hr /></blockquote>Not to dispute your methods (but I will), that wasn't a very good test. XLM parsing is extremely simple in it's utilization of the CPU - essentially you are measuring string manipulations, hashtable lookups, and file reading. But, you say that you run JBuilder all day, so why is it reasonable to eliminate the "performance problems" in Aqua if you use an Aqua java app all day? Also, since you do JSP's and work in a Java IDE, I would have thought that compile times would have been a big benchmark. Not to mention Tomcat. I would have devised a test suite more like this:

1 - Download Ant and make it using it's bootstrap scripts.
2 - Download Tomcat and make it using Ant.
3 - Startup Tomcat with a non-trivial webapp.
4 - Time how long jsp's take to compile.
5 - Hit Tomcat with 100,000 hits from another Java app running on the same machine and time how long it all takes.
6 - Time how long before JBuilder UI is onscreen and useable (from initial click).

The ant compile is exactly the benchmark I used for determining which machine to buy, and to determine if a portable could be comparable to a desktop. The Tomcat test was beyond me because I was doing all of this at an Apple retailer.

Your tests are valid to a point, but you didn't really benchmark what you will be using the machine for so they may be a little skewed.

cmoney · Jun 24, 2002, 09:35 PM

<blockquote>quote:<hr />Originally posted by absmiths:
 <blockquote>quote:<hr />Originally posted by cmoney:
Sorry, I originally posted this on the PowerBook forum and we started doing some benchmarks. Using the Xerces 1.4.4 library and the SAX sample (command line app, so it's pure Java processing, not dealing with Aqua's performance problems), a few people compiled the following results:
<hr /></blockquote>Not to dispute your methods (but I will), that wasn't a very good test. XLM parsing is extremely simple in it's utilization of the CPU - essentially you are measuring string manipulations, hashtable lookups, and file reading. But, you say that you run JBuilder all day, so why is it reasonable to eliminate the "performance problems" in Aqua if you use an Aqua java app all day? Also, since you do JSP's and work in a Java IDE, I would have thought that compile times would have been a big benchmark. Not to mention Tomcat. I would have devised a test suite more like this:

1 - Download Ant and make it using it's bootstrap scripts.
2 - Download Tomcat and make it using Ant.
3 - Startup Tomcat with a non-trivial webapp.
4 - Time how long jsp's take to compile.
5 - Hit Tomcat with 100,000 hits from another Java app running on the same machine and time how long it all takes.
6 - Time how long before JBuilder UI is onscreen and useable (from initial click).

The ant compile is exactly the benchmark I used for determining which machine to buy, and to determine if a portable could be comparable to a desktop. The Tomcat test was beyond me because I was doing all of this at an Apple retailer.

Your tests are valid to a point, but you didn't really benchmark what you will be using the machine for so they may be a little skewed.<hr /></blockquote>True enough and your benchmarks are more thorough (and definitely more applicable to the kind of work I need to do). That said, I asked everyone to do a simple benchmark about 24 hours before my ADC hardware discount expired. It was simply to make a quick comparison between the TiBook 667 and iBook 700. I chose this particular benchmark because I happened to be downloading the library at the time. One interesting thing I found when running it was that my iBook was significantly slower than the similarly clocked PC desktop I compared it to.

BTW, just for comparison's sake, the PB 800 gets 326ms on the test I ran originally.