Linux and EM64T; Intel's 64-bit Suggestion

275 Comments

View All Comments

• DerekWilson - Tuesday, August 10, 2004 - link

  #213:
  
  It is much easier for other members of the AnandTech staff to setup Linux boxes comprised of the hardware Kris wants to test than for us to ship everything to him, have him work on it, then ship it back -- the AT staff is global, and the fact that SSH allows us this freedom is invaluable in Linux testing.
  
  A "remote location" will always be with another AT staff member unless very specifically noted (though we would not be comfortable taking someone elses word on the system without having physical access to it).
  
  Derek Wilson

• prd00 - Tuesday, August 10, 2004 - link

  I read all those comments, and some are nasty.. I think Kris is not providing thie valid benchmark suite, perhaps he doesn't know any optimization or anything inside there..
  I suggest, next time you provide benchmark that has proven to take advantage of both sides. Aces' Hardware comparison of server benchmark is a good example. Take a look at that..
  About those fans that asking to compare against Opteron, I guess the figure will not so much difference, looking at some similarities between 3500+ and Opteron 150, or, should I say FX53 and 150, but I guess moving to FX53 will change the result a little. Remember P4 vs P4EE? Nocona is in P4EE position, while 3.6F is in P4 position. There is no way 3.6F is comparable in term of performance to Nocona. You forget about all Xeon having a huge L3 cache which help them tremendously here. But number that much difference are not supposed to change with move to Opteron 150. Granted, it will lessen the pain but Opteron is always on par with Xeon on single CPU config, some better, some worse. And with this new CPU, Opteron is supposed to be a little slower. But where Opteron really shines is when you put them into multi processor config which is normal on server system on which Nocona intended.
  
  Well.. Kris, I'm waiting.. The only valid bench you provide are MySQL, GZip and Lame which is I know that it is 64 bit indeed. I can't consider your review is valid right now.
  I suggest you void this review, and start a new review on real 64 bit vs 64 bit, in server environment vs server environment, and in server configuration vs server configuration. Dual Nocona vs Dual Opt and Quad Nocona vs Quad Opt will be good review. John the ripper is useless on server, and so does lame and SuperPI. We are talking about server CPU, so put server benchmark there. A real time database throughput, a request response, page per second, java performance, and so on. If you need reference, please look at this. This is the way server CPU comparison supposed to be done.
  http://www.aceshardware.com/read.jsp?id=60000275

• JGunther - Tuesday, August 10, 2004 - link

  Kris, could you address comment #135?
  Basically, why is this Nocona located in a server "in a remote location". What does this mean exactly?

• love4ever - Tuesday, August 10, 2004 - link

  KristopherKubicki im sorry for all that coments, that are against you.
  
  i suport you, and your page.
  
  good work.

• thatsright - Tuesday, August 10, 2004 - link

  For all the Bitching everyone here has done (including I), at least we have to give it to AnandTech and Kris for listening to it's audience and bending over backward in an effort to rectify the 'problem.'
  
  At least Kris K is address our complaints. Whens the last time you ever heard of Tom Pabst doing the same with one of his 'articles' on Tom's? While the overall nature of the article I read on AT was deeply troubling for it's incompleteness, its the only time I have really seen on AT. The same can't be said of Tom's Hardware guide.
  
  Now stop whining, you bastards! It's not like were paying for these Articles. Just regard the article as a mistake, and save your whining for the Update.
  
  LONG LIVE AnandTech.com!!!

• tfranzese - Tuesday, August 10, 2004 - link

  Glad to hear it Kris.

• KristopherKubicki - Tuesday, August 10, 2004 - link

  I understand your concern for the other benchmarks, and the conclusions i drew were from those benchmarks. This is why we are doing another review as we speak. I hope the other article with more thorough realworld benchmarks makes more sense (should go live soon).
  
  Thanks,
  
  Kristopher

• tfranzese - Tuesday, August 10, 2004 - link

  I've grown to ignore things like Sandra benchmarks and I guess I find it difficult to ignore these because even though you state these are synthetic the conclusion just puts a lot of weight into the 'victory'.

• tfranzese - Tuesday, August 10, 2004 - link

  Okay, are you confident your other results are just as accurate? I only ask because John the Ripper, primegen, and ubench have also been mentioned in earlier posts. Not only in possible botched compiling, but perhaps their legitimacy as a valid benchmark - synthetic or not.

• KristopherKubicki - Tuesday, August 10, 2004 - link

  TSCP and the incorrectly copied numbers for MySQL have been changed as stated earlier.
  
  Kristopher