ABOUT BENCH FORUMS PODCAST LOGIN REGISTER
PC Components
Smartphones & tablets
Systems
ENTERPRISE & IT
GUIDES

AMD's dual core Opteron & Athlon 64 X2 - Server/Desktop Performance Preview

 by Anand Lal Shimpi, Jason Clark & Ross Whitehead on April 21, 2005 9:25 AM EST
144 Comments | Add A Comment
144 Comments

SQL Stress Tool Benchmark

Our first benchmark was custom-written in .NET, using ADO.NET to connect to the database. The AnandTech Forums database, which is over 14GB in size at the time of the benchmark, was used as the source database. We'll dub this benchmark tool "SQL Stress Tool" for the purposes of discussing what it does. We have done some updates to the tool since we first used it; it now supports Oracle, and MySQL. We also adjusted the test time for this test and future tests to 20 minutes. The reason for this was to ensure that we used as much memory as possible for future planned 64 bit tests.


Click to enlarge.

SQL Stress allows us to specify the following: an XML based workload file for the test, how long the test should run, and how many threads it should use in which to load the database. The XML workload file contains queries that we want executed against the database, and some random ID generator queries that populate a memory resident array with ID's to be used in conjunction with our workload queries. The purpose of using random ID's is to keep the test as real-world as possible by selecting random data. This test should give us a lot of room for growth, as the workload can be whatever we want in future tests.

Example workload:


    Select1
    select count(iuserid) as usercount from ftdb_forumusers where iforumid = 1


    Select2
    select count(u.iuserid) as currusercount from ftdb_users u,ftdb_forumusers fu where fu.iforumid = 1 and u.iuserid = fu.iuserid and dtlastvisiteddate > '[q]qGetLastVisitDate[/q]'


Example Random ID Generator:


    qGetLastVisitDate
    select dtlastvisiteddate,newid() as ldate from ftdb_users where dtlastvisiteddate is not null order by ldate


The workload used for the test was based on every day use of the Forums, which are running FuseTalk. We took the most popular queries and put them in the workload. Functions, such as reading threads and messages, getting user information, inserting threads and messages, and reading private messages, were in the spotlight. Each reiteration of the test was run for 20 minutes, with the first being from a cold boot. SQL was restarted in-between each test that was run consecutively.

The importance of this test is that it is as real world as you can get; for us, the performance in this test directly influences what upgrade decisions we make for our own IT infrastructure.

Web Tests - FuseTalk .NET SQL Stress Results
PRINT THIS ARTICLE
Comments Locked

144 Comments

View All Comments

  • MDme - Tuesday, April 26, 2005 - link

    #133

    i think what #130 was saying was that: from top to bottom, AMD's offerings are really good...if you want the best "bang for the buck" the 3400+ or whatever, or a 3000+ winnie OC'd will provide you with the best performance per dollar you spend...EVEN against the X2's.

    On the other hand if cost is not an issue, an X2 4400+ provides extremely good performance for people willing to pay the $500 premium.

    Zebo's point is in direct response to your point, which is AMD "STILL" has the best bang for the buck, not intel.

    or maybe YOU missed the logic? LOL

  • MPE - Tuesday, April 26, 2005 - link

    "Intel is just lucky a 3400+ new castle wasn't in that test suite. It's would win the majority of tests over an 830!! and it's still cheaper. Or did you miss this chart? LOL"

    Why not just admit it. AMD's DC is about 10-20% faster while costing 80-100% more.

    Even if the 3400+ is added, that comparison is moot since if you compare the score of that to the price of AMD's own DC - the price performance ratio is stagerrring? Or did you miss that logic?

    Anyways did you miss the part that even AMD DC was being beaten by their own single core.

    Next.

  • nserra - Tuesday, April 26, 2005 - link

    "The Athlon 64 4000+ was the last single core member of the Athlon 64 line.
    The Athlon 64 FX will continue as a single core CPU line, with the FX-57 (2.8GHz) due out later this year."

    Where did you get this info anand, i am not sure if an Athlon64 X2 4400+ could not coexist with a Athlon64 4400+. If this is the last 4000+ than i must say gee thats too bad....

  • Zebo - Tuesday, April 26, 2005 - link

    #125

    Techreports review is better for you. 64-bit OS, 64-bit apps when possible, no mystery unreproducable benchmarks like Anand's database stuff.

  • Zebo - Tuesday, April 26, 2005 - link

    MPE BS, Intel is just lucky a 3400+ new castle wasn't in that test suite. It's would win the majority of tests over an 830!! and it's still cheaper. Or did you miss this chart? LOL
    http://images.anandtech.com/reviews/cpu/amd/athlon...

    Intels DC chips can hardy compete with AMDs single core offerings. Side by side both DC it's a joke.

    So ya, AMD still has the "best bang for the buck" top end to bottom end. And they a far on top of the mountain.

  • MPE - Monday, April 25, 2005 - link

    Isn't the shoe on the other foot?

    For several years now, so many touted AMD's cheaper price and competative pricing.

    Now with Pentium4 D, especially with the 3GHz model, you get half the price of the cheapest X2 while probably at best 20% lower performance?

    What happened here?

    Now P4D 3GHz model is the best bang for the buck and not the AMD offering. This is a complete reversal of what a lot of AMD supporters have been touting?

  • ceefka - Monday, April 25, 2005 - link

    #125 Yeah, good point.

    Compare:
    A. singletreaded 32-bit app on a singlecore
    B. multi-threaded 64-bit app on a dualcore
    Considering that multithreaded apps already see such large gains on dualcores, going 64-bit too could well mean a more than 100% improvement from A to B.

    But of course, NO ONE needs dual core, 64-bit and +4GB memory in the next 5-10 years :P

    The ball now lies with MS and (Linux) app developpers to write more stuff in multithreaded 64-bit code. From what I hear and read it is not so much the 64-bit part as it is the threading that is a real challenge, even for veterans.

  • Ross Whitehead - Sunday, April 24, 2005 - link

    Visual, On P.12 I was referring to the closest Xeon competitor to the 252s which is the Quad Xeon 3.6 GHz 667 MHz FSB.

    Does that make any more sense?

  • Ross Whitehead - Sunday, April 24, 2005 - link

    jvarszegi, the actual stored procs are not prefixed with "sp_", we just used that as part of the "analogy" to the real system.

    One could also argue that we did not prefix the analogy example with the object owner either which also incurs a cache miss.

    Honestly, I have never quantified the expense of the sp_ prefix or the object owner.

  • Binji7 - Sunday, April 24, 2005 - link

    Where are the dual-core Windows x64 and Linux x64 benchmarks?? That's what I really want to see.

Copyright © 2024. All rights reserved.
BENCH
TOPICS
FOLLOW
ABOUT

Log in

Don't have an account? Sign up now