Announcement

Collapse
No announcement yet.

Intel Hyper Threading Performance With A Core i7 On Ubuntu 18.04 LTS

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

  • #11
    "Tests were done on Ubuntu 18.04 LTS x86_64 with its default Linux 4.15 kernel."

    It would be interesting to see if there is any actual difference between the kernel disabling HT and the bios disabling HT. Difference being, that HT in software has overhead, so if you don't compile the HT software in the kernel, perhaps the kernel can work slightly better since the scheduler has different expectations?


    CONFIG_SCHED_SMT:

    │ SMT scheduler support improves the CPU scheduler's decision making
    │ when dealing with Intel Pentium 4 chips with HyperThreading at a
    │ cost of slightly increased overhead in some places. If unsure say
    │ N here.


    │ Symbol: SCHED_SMT [=n]
    │ Type : bool
    │ Prompt: SMT (Hyperthreading) scheduler support
    │ Location:
    │ -> Processor type and features
    │ Defined at arch/x86/Kconfig:1009
    │ Depends on: SMP [=y]

    Comment


    • #12
      Originally posted by brent View Post
      Nice comparison. And the results were as expected. My bullshit detector was instantly triggered when the OpenBSD developers proclaimed that SMT doesn't offer any performance advantage. If that is the case on OpenBSD, it only shows once more how badly OpenBSD performs with multiple cores.

      It might be interesting to see how SMT speedup is on Ryzen, compared to Intel. Does such a comparison exist yet?
      What he actually said:
      "Note that SMT doesn't necessarily have a positive effect on performance; it highly depends on the workload. In all likelyhood it will actually slow down most workloads if you have a CPU with more than two cores."

      To give context to *your* bullshit.

      There's more to performance then these tests (most of these are similar in how they access cache, and what parts of the cpu they use the most).
      It's probably worst for performance if one of these "hyperthreads" abuses the L2 cache (if it uses memcpy a lot, for example) but the other thread is slowly processing data.

      For business things where security matters, there probably isn't much performance difference.

      Comment


      • #13
        Originally posted by gens View Post
        To give context to *your* bullshit.

        There's more to performance then these tests (most of these are similar in how they access cache, and what parts of the cpu they use the most).
        It's probably worst for performance if one of these "hyperthreads" abuses the L2 cache (if it uses memcpy a lot, for example) but the other thread is slowly processing data.

        For business things where security matters, there probably isn't much performance difference.
        You're being very aggressive for someone whose arguments contain a lot of "probably"...

        Comment


        • #14
          Originally posted by Gusar View Post
          You're being very aggressive for someone whose arguments contain a lot of "probably"...
          It's no worse than the retarded bullshit posted by most of the other posters.

          Comment


          • #15
            Originally posted by gens View Post
            if one of these "hyperthreads" abuses the L2 cache (if it uses memcpy a lot, for example)
            Isn't it possible to bypass the cache with special SSE instructions?

            Comment


            • #16
              Originally posted by _Alex_ View Post
              CONFIG_SCHED_SMT:
              │ SMT scheduler support improves the CPU scheduler's decision making
              │ when dealing with Intel Pentium 4 chips with HyperThreading at a
              │ cost of slightly increased overhead in some places. If unsure say
              │ N here.
              It's really annoying how these description in kernel config never get updates. SMT is relevant for several processors, not only P4. POWER chips have multiway SMT, Zen has, Core2+ CPUs have. They're all different from P4 HT.

              Configuring the kernel is really hard these days. Should you optimize for Core or generic x86-64 (for Gentoo users there are march=native patches)? Does your PCI-E GPU need AGP GART? Does your NVME or SATA drive need generic SCSI support, and so on. Nobody knows. At least nobody who knows this stuff knows how to submit patches.

              Comment


              • #17
                Configuring the kernel was hard 15 years ago. Since then, everyone has used a disto kernel, or a kernel compiled with distro configuration.

                Comment


                • #18
                  Originally posted by eigenlambda View Post
                  Configuring the kernel was hard 15 years ago. Since then, everyone has used a disto kernel, or a kernel compiled with distro configuration.
                  This doesn't really help with the task. On the contrary.

                  Comment


                  • #19
                    Michael Could you run the same benchmark with a Ryzen 7?

                    Comment


                    • #20
                      Originally posted by chuckula View Post
                      The OpenBSD guys being a-holes and spreading FUD for no reason? [Oh wait, there is a reason: Free publicity for an OS that's niche even inside of the BSD niche]
                      That's new!

                      It's also amusing how much they harp on Intel for being the sole source of all security problems when Hyperthreading is just their implementation of SMT that's used by... let's see here...
                      You're making assumptions based on incomplete information, as all these tests were multi-threaded capable. No single thread tests were done, which is the only place you would see possible speedups from disabling HT/SMT... But as with nearly all of the benchmarks done on this site it's very narrow focus is missing useful comparisons. They also did not harp on Intel for being the "sole source" of all security problems, they just said it's more vulnerable than the alternatives which is likely true (Meltdown is Intel only). Their optional changes will eventually be applied to all affected processors while they work on their scheduler. Nobody has as of yet disproved their claim so it's pretty rude of you to assume it's a FUD based publicity stunt especially when the Phoronix article was based off a CVS commit log entry (as are other similar news articles from other sites).



                      Comment

                      Working...
                      X