Results 1 to 19 of 19

Thread: Linux vs. Windows: client speed

  1. #1
    Junior Member
    Join Date
    Dec 2002
    Location
    Germany
    Posts
    17

    Linux vs. Windows: client speed

    Hi,

    one of my boxes running SoB is a AMD Duron 1200 / 256MB / Win98SE, another is a dual P3 1,13 / 512MB / Linux 2.4.16, running 2 clients.

    I'd expect the Linux box to bee about twice as productive as the Windows box, but the Windows box is running at ca. 85 kcEMs/sec, while the Linux box is running at only ca. 75 kcEMs/sec (both clients together). Why?

    You can take a look at my stats:

    http://www.seventeenorbust.com/stats...tml?userID=773

    The peak around 01/09 was achieved during an 48h burn in for the new processor on the Windows box, which is now offline.

    cu,
    othello

  2. #2
    Junior Member
    Join Date
    Jan 2003
    Location
    Netherlands
    Posts
    14

    Re: Linux vs. Windows: client speed

    Originally posted by othello
    Hi,

    one of my boxes running SoB is a AMD Duron 1200 / 256MB / Win98SE, another is a dual P3 1,13 / 512MB / Linux 2.4.16, running 2 clients.

    I'd expect the Linux box to bee about twice as productive as the Windows box, but the Windows box is running at ca. 85 kcEMs/sec, while the Linux box is running at only ca. 75 kcEMs/sec (both clients together). Why?
    I have a Duron 600 running Linux. It usually does about 45-50 kcEM/s, and the stats say "Equivalent power (est): 1.27 Ghz".

    A friend's Athlon 1700 (Windows) has "Equivalent power (est): 3.18 Ghz".

    It seems to me that AMD simply annihilates Intel for this particular application.

    Kernel might matter though. My stats were around 38 kcEM/s with a 2.2 kernel, now I upgraded to 2.4.19 with Gentoo patches. But I have no idea about SMP.

  3. #3
    Junior Member
    Join Date
    Dec 2002
    Location
    Germany
    Posts
    17
    Is there a way to calculate the cEMs/sec from the logfile of the Linux client?

    I have an old P200 notebook running both Win98SE and Linux 2.4.16, so I could compare both OS on the same hardware...

  4. #4
    Junior Member
    Join Date
    Dec 2002
    Location
    Germany
    Posts
    17
    I just did some fast math on the logs of my P200 / 96MB notebook, using the longest periods without interuption i could find:

    Linux: ca. 9h / block (62:55:24 / 7 blocks)
    Win98SE: ca 6:15 / block (56:16:11 / 9 blocks)

    Looks like the clients are optimized for AMD / Windows. Perhaps that's what the developer of the client is running on his box? :-)

    If I'm not mistaken, the project could gain lots of additional power just from optimizing the client for diffrent hard- & software...

    cu,
    othello

  5. #5
    All archs are optimized. AMDs run faster than P3s because their FSB is higher and their memory arch is better. P4s smoke even Atlons because their bus is faster yet and there are SSE2 optimizations. There are optimizations for all instructions though (3dnow, mmx, sse, sse2). If your proc supports it... it uses it.

    As far as OS goes, I would be surprised if the windows client was faster. I've always assumed the linux client would be slightly faster. It amazes me to this day that no one has done a test on a dual boot machine with both linux and windows clients just to settle it. I would, but I don't have such a system.

    -Louie

  6. #6
    Junior Member
    Join Date
    Dec 2002
    Location
    Germany
    Posts
    17
    Originally posted by jjjjL
    As far as OS goes, I would be surprised if the windows client was faster. I've always assumed the linux client would be slightly faster. It amazes me to this day that no one has done a test on a dual boot machine with both linux and windows clients just to settle it. I would, but I don't have such a system.

    -Louie
    I could do this test on my notebook, but to get adequate results i'd have to use the same k and n on both clients, right?

    cu,
    othello

  7. #7
    Member
    Join Date
    Oct 2002
    Location
    Copenhagen.
    Posts
    43
    It amazes me to this day that no one has done a test on a dual boot machine with both linux and windows clients just to settle it. I would, but I don't have such a system.
    well... in the Linux client, there is really no easy way to calculate the cems/sec. Or is there?

  8. #8
    Senior Member
    Join Date
    Apr 2002
    Location
    Near Frankfurt, Germany
    Posts
    106
    Originally posted by jjjjL
    ..
    As far as OS goes, I would be surprised if the windows client was faster. I've always assumed the linux client would be slightly faster. It amazes me to this day that no one has done a test on a dual boot machine with both linux and windows clients just to settle it. I would, but I don't have such a system.

    -Louie [/B]
    I could test this on my machine (Athlon 1.2 GC/s, Thunderbird C), if you want.
    I have installed Windows XP and SuSE Linux version 8.1 (Kernel 2.4.19)

    Just tell me ;-)

  9. #9
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    Assuming that the Linux version also uses 250M cEMs for 1 block, it should be no problem to calculate the average speed.

    Pascal: Just do it. I think there's enough interest here.


    BTW:
    I'm using a Duron @ 900 MHz and a mobile P3-m @ 1 GHz respectively 733 MHz in SpeedStep.

    At 1 GHz, the P3 is slightly faster than the Duron. When it's running @ 733 MHz, it doesn't loose 26,7%, though, but considerably less - maybe 10-15%.

    Seems like L2 cache (and/or SSE) is used intensely.
    A direct comparison Athlon <--> Duron should provide an answer to this guess...

  10. #10
    Junior Member
    Join Date
    Dec 2002
    Location
    Germany
    Posts
    17
    Originally posted by Mystwalker
    Assuming that the Linux version also uses 250M cEMs for 1 block, it should be no problem to calculate the average speed.
    With the figures I posted earlier this would mean:

    On my P200MMX / 96MB notebook the performance is

    7725 cEMs/sec for Linux 2.4.16

    and

    11140 cEMs/sec for Win98SE

    which means factor 1,44 for Windows / Linux.

    Can someone please check this out on other Hardware?

    cu,
    othello

  11. #11
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    When someone could tell me how to insert the block the Linux client should use into the config file, I could make that test, too.

  12. #12
    Member
    Join Date
    Oct 2002
    Location
    Copenhagen.
    Posts
    43
    For Linux - what flags was the compiler given when compiling the client; and in what compiler + version was it done?

  13. #13
    Junior Member
    Join Date
    Dec 2002
    Location
    Germany
    Posts
    17
    Originally posted by Mystwalker
    When someone could tell me how to insert the block the Linux client should use into the config file, I could make that test, too.

    For the calculations above I used the logs for different tests:

    Linux: k=22699 n=1438174
    Windows: k=21181 n=2041580

    If this matters in any way, I may be totaly wrong!

    I just didn't expect such a big difference...

    cu,
    othello

  14. #14
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    Linux: k=22699 n=1438174
    Windows: k=21181 n=2041580
    Yikes, that explains a lot.

    Although cEM already is a corrected value (indicated by the "c"), it's doesn't even out the increasing effort of higher n's completely. To be specific, it's too strong as on the same system, cEMs/sec is usually higher the bigger the n. This usually isn't a big problem as the difference between the n's of successive computed work units is generally not very big. But a difference of 600,000 does indeed make a noticable change.

    AFAIK there will be another measuring unit soon.

  15. #15
    Any comparison test run using different k and/or n values is going to be highly, highly suspect for performance comparison purposes.

    On windows you could probably force a specific k/n pair by hacking the registry files (I haven't tried this, but I think it might work) and on Linux I am not sure which files you would need to edit to force a specific k/n pair to be tested.

    Rather than worry about cEMs, why not just run a test with a smaller n value and let it complete the test?

  16. #16
    Senior Member
    Join Date
    Dec 2002
    Location
    Madrid, Spain
    Posts
    132
    Originally posted by jjjjL
    All archs are optimized. AMDs run faster than P3s because their FSB is higher and their memory arch is better. P4s smoke even Atlons because their bus is faster yet and there are SSE2 optimizations. There are optimizations for all instructions though (3dnow, mmx, sse, sse2). If your proc supports it... it uses it.
    Does it use prefecth instructions?
    I would like to able to see somewhere in the client something like "Detected XXX processor" "Using YYY, ZZZ optimizations".

  17. #17
    Originally posted by Firebirth
    For Linux - what flags was the compiler given when compiling the client; and in what compiler + version was it done?
    This doesn't matter as the program spends almost all the execution time in the assembler core.

  18. #18
    yes prefetch instructions are used.

    -Louie

  19. #19
    I posted about this in the OTHER SB forum (don't know how I ended up there instead of this one), but I'm copying a bit of it here...

    On a side note, I seem to have lost the Windows vrs Linux thread, but I have some evidence to contribute:


    As you can see, while running Linux (L) I was consistantly below the Windows (W) production levels. I have no idea why, but there's the proof. This is one 1gHz Athlon Thunderbird with 512 RAM (if RAM matters). On the good side the user statistics is telling me I have a 1.66-2 gHz computer Unfortunately I don't have a massive computer farm to throw into the project or else I would.

    EDIT: Of course these were with different values (see my post on the other board for info), but I think a difference of that much HAS to be based on more than just increasing complexity.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •