Announcement

Collapse
No announcement yet.

Building The Linux Kernel In 60 Seconds

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by leeenux View Post
    I think it's safe to say that Phoronix has sold out just like the other sites, as Michael has declined to be "open" and provide his kernel compiling parameters....
    Huh? It's all open-source and there as part of the Phoronix Test Suite. Fetch the Phoronix Test Suite and run "phoronix-test-suite benchmark build-linux-kernel" and it will download, setup, and run the build test just like I do and then spit out your times.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #22
      AMD has been a fscking loser for a long time, just like Mr Q

      Comment


      • #23
        Learning curve

        I agree the learning curve for the openbenchmarking.org site is difficult. I gave up when I first tried to understand the site. However, I think I will pick it up on second review. I was able to find some of the results in question - Intel Core i7 3960X kernel comp. It did take me one search, then 4 clicks to find, which is very acceptable, since I still don't have a firm grasp on how to use the site. I haven't been able to get PTS working on my machine (gentoo amd64) but I'ma try again on that.

        Comment


        • #24
          much like intel fanboys.. just as bad as apple fanboys. just stfu and admit that while neither are perfect they both (brands) can do any job wonderfully

          Comment


          • #25
            Nice. I see the so called "fail of the century" Bulldozer doing extremely well, beating the comparably priced Intel CPUs in every benchmark. If you toss in the $1000 Operton 6282 SE into the mix(16 cores, 2.6ghz), and extrapolate the results assuming that these benchmarks will scale approximately linearly with clockspeed and core count vs. the FX8150, then it's pretty much going to tie the 3960X in every benchmark. The only important measures of performance are performance per dollar, and performance per socket, and AMD is doing as well or better than Intel in both.

            Comment


            • #26
              Originally posted by Qaridarium
              many windows7 tests but the windows7 scheduler can't handle the bulldozer correctly
              I wonder: if AMD were to present the cores to the OS as SMT (hyperthreading), rather than as full cores... would that help the performance?

              Comment


              • #27
                Originally posted by DanaG View Post
                I wonder: if AMD were to present the cores to the OS as SMT (hyperthreading), rather than as full cores... would that help the performance?
                That is highly unlikely, AMD's SMP variant of SMT is theoretically going to be improved more by thread pairing to CPUs while Intel's is going to be better improved by spreading threads across each of the true cores, and then adding into the stalling spots.

                AMDs variant actually has real computational assets and so can not only do actual processing but will appreciate shared information and ability to turbo-core.

                the more typical SMT (Intel) thing however is having multiple threads per core processing one at a time and waiting for a thread to stall out to compute on the other. Obviously you can only run one thread at a time in this configuration and thus it helps for the threads to be spread across the actual computational assets.

                Of course the AMD design can also in some situations where lots of cache is needed by a particular thread be improved by singly assigned a tread to a module

                So no... Intel's "Hyperthreading" software stuff would likely not help AMD that much..

                Comment


                • #28
                  So just for fun, I ran this kernel compile test on an Opteron 6128. For the record, thats an 8 core 2.0 GHz part, TDP 115 watt. Its a magny-cours, NOT a bulldozer.
                  Came to 1m49.265s. I did 3 runs, they all came to within about 0.150 seconds.


                  Now, obviously that isn't directly comparable, so lets try to adjust.
                  109.265 seconds
                  Apparently, a reasonable scaling factor for magny-cours to bulldozer is 1.3x
                  So w/bulldozer 8 core @ 2.0 GHz, we would be looking at 84.05 seconds.
                  Now we scale number of cores,
                  84.05x8/6=112.1s with a 6 core 2.0 GHz bulldozer.
                  Now bump up the clock rate....
                  3.0 GHz: 74.73s
                  3.3 GHz: 67.94s
                  3.9 GHz: 57.48s
                  4.0 GHz: 56.05s

                  Yeah yeah, I know... there's more than just CPU time involved.
                  For reference, the system has 2 Seagate Constellation ST32000444SS running in RAID 0 (hardware), 32 GB ECC/REG in 4-channel, I forget how fast.

                  Anyway, to make a little more sense.... bulldozer FX-8150 is an 8-core 3.6 GHz....
                  109.25/1.3=84.03s
                  And at 3.6 GHz...
                  84.03*2/3.6=46.69s <--- hmm, when you're doing something like this, it tends to scale fairly linearly, doesn't it? Right... the disk part doesn't scale at all. Well I'm running magnetic disks, which are obviously at a tremendous disadvantage here. I think the bulldozer will do fine.

                  Comment


                  • #29
                    @droidhacker, see the link above.

                    It gave 89.17s for the FX-8150 kernel compile.

                    Comment


                    • #30
                      Originally posted by droidhacker View Post
                      Anyway, to make a little more sense.... bulldozer FX-8150 is an 8-core 3.6 GHz....
                      109.25/1.3=84.03s
                      And at 3.6 GHz...
                      84.03*2/3.6=46.69s <--- hmm, when you're doing something like this, it tends to scale fairly linearly, doesn't it? Right... the disk part doesn't scale at all. Well I'm running magnetic disks, which are obviously at a tremendous disadvantage here. I think the bulldozer will do fine.
                      I'm pretty sure that compiling the Linux kernel is pretty CPU limited, disk bandwidth isn't important because it's not reading large contiguous files, but many small ones, which is much slower and varies by which filesystem you are using. Even though the ability to read small files may be important, the compiler should be able to buffer them in memory before the CPU actually needs them, so memory bandwidth and parallelism is probably more important. I think if you were compiling the kernel in sub-30 second time with a 4 x 16-core Interlagos system, that you might hit a disk bottleneck.

                      Comment

                      Working...
                      X