On Thursday 30 June 2005 17:52, Bryan J. Smith b.j.smith@ieee.org wrote:
From: Peter Arremann loony@loonybin.org
*rofl* either you forgot how damned slow a E4500 is or you never worked with them... There is _nothing_ fast about them (see, I learned how to use the underscore from you, aren't you happy?)...
Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow. But there are a lot of UltraSPARC II options that are still quite viable solutions.
Yeah - for a boat anchor or a door stop... Other than that, a US-II isn't worth the power it would take to run it... That's why you see so many of them on ebay now - cause no one wants it anymore :-)
Oh - misquote to omit my acknowledgment of the inadequacy of my comparison. What was the reason for you leaving off where I said "compilers aren't a good benchmark"? :-) Are you that desperate to win an agrument that you have to misquote me to infer that I'm saying something else?
Dude, this is _not_ about "winning an argument."
It's about reminding you that "build times" are _not_ a good indictator of _server_ benchmark (please note that I said _server_).
That is exactly what I said before you trimmed it off :-)
I mean, if you want to see one benchmark that Intel has _always_ lost to AMD -- and handily -- build times are it. ;->
But thanks for not acknowledging that you purposefully trimmed off a sentence that was essential for the statement I made.
That's why I made the comment that you so nicely cut out :-) Performance tuning of provisioning apps is another thing I do :-) Working for a fortune 5 and dealing with the biggest systems that company has can be fun...
Dude, stop with the resume. The problem with pulling credentials is that someone else _always_ has more. Now stop while you _think_ you are "ahead." ;->
Oh - but its ok if you do the same, right? :-)
4TB databases, used by Java and C++ programs, 48way 96GB ram... that a better example or still too small for you to accept that I might not just do little things?
Once again, I will re-iterate, there are _other_ performance considerations than computational. And even then, "build" times are _not_ very representative of performance in even some computational
I wasn't talking about builds - This is 100% transaction load. Very heavy on the DB.. (just so you know what I mean with heavy - so heavy that Informix had to produce a specific release just for us otherwise no commercial DB was able to handle the load at the time)...
An Athlon64 3200+/4GB running on a 3ware controller with mirrored disks beats an 8way E4500/4GB running a 400GB oracle database... give the sun box 8GB and the performance is roughly equal...
Depends on if you are computationally limited, and also what is your I/O -- let alone the number of sessions you are serving. In raw, unthreaded, linear aspects -- hell yes, the E4500 is a _dog_.
Yep - and for threaded apps its hmmm... a _dog_ :-) 14 CPU E4500 is 67103 TPC-C ... a 16CPU p5 570 is 809144... But I guess that doesn't count either for you :-)
Point being a E4500 for todays standards is slow no matter what you use it for.
Yes, and one of the limitations on the E4500 is throughput... A 3510 on a v490 does 61MB/sec - same lun, just connected into the SUNW,socal of a E4500 IO board does about 20MB/sec...
It all depends on how distributed your environment works, as well as the application.
I'm not saying an old UltraSPARC II platform is always going to be faster. But man, you are like a single track that thinks there are _no_ other considerations.
???? What does a distributed app have to do with an inheret IO limit of the hardware????
Peter.