Professional Web Applications Themes

hyper threading. - FreeBSD

I have 3,4ghz ht processor and freebsd shows up only one processors. I suppose it should show two in ht models? so, GENERIC kernel doesn't support it? but should I add to kernel config to enable it? by reading config examples I think this should be enough: options SMP but is it all I need? -- kpn IRCnet...

  1. #1

    Default hyper threading.

    I have 3,4ghz ht processor and freebsd shows up only one processors. I
    suppose it should show two in ht models? so, GENERIC kernel doesn't
    support it? but should I add to kernel config to enable it? by reading
    config examples I think this should be enough:

    options SMP

    but is it all I need?


    --
    kpn IRCnet
    Perttu Guest

  2. #2

    Default Re: hyper threading.

    Perttu Laine writes:
     

    Yes, that's all you need. Just add that line, rebuild and reinstall the
    kernel, and you're all set. Works great. Hyperthreading doesn't buy
    you as much as truly separate processors, but it helps you get more bang
    for the buck out of your single processor (depending on the type of
    workload you run).

    --
    Anthony


    Anthony Guest

  3. #3

    Default Re: hyper threading.

    This is the kind of disinformation I have been
    referring to....

    You'll get much better performance with 1 processor in
    UP mode. I suggest you do some testing.

    -----Original Message-----
    From: Anthony Atkielski <fr>
    To: org
    Sent: Sat, 26 Mar 2005 19:28:11 +0100
    Subject: Re: hyper threading.

    Perttu Laine writes:
     

    Yes, that's all you need. Just add that line, rebuild and reinstall the
    kernel, and you're all set. Works great. Hyperthreading doesn't buy
    you as much as truly separate processors, but it helps you get more bang
    for the buck out of your single processor (depending on the type of
    workload you run).




    em1897@aol.com Guest

  4. #4

    Default Re: hyper threading.

    com wrote: 
    >
    >
    > Yes, that's all you need. Just add that line, rebuild and reinstall the
    > kernel, and you're all set. Works great. Hyperthreading doesn't buy
    > you as much as truly separate processors, but it helps you get more bang
    > for the buck out of your single processor (depending on the type of
    > workload you run).
    >[/ref]

    If you feel someone is in error - feel free to jump in and offer what
    you feel to be correct information.

    Sometimes sitting back and not correcting someone is far worse then
    someone offering information based on what they know, experience, or
    what have you.

    In this case, by NOT offering the correct information, YOU are just as
    much to blame for what you say is going on.

    For those of us that don't answer, we either don't know (as is the case
    wit myself) OR, they have not had a chance to read the thread.

    --
    Best regards,
    Chris

    It is a simple task to make things complex, but a complex
    task to make them simple.
    Chris Guest

  5. #5

    Default Re: hyper threading.

    I am offerring the correct information. Turning on SMP on
    an HT machine will kill the systems performance much
    more than hyperthreading will gain. I told him to test.
    The degradation is easily measurable.

    -----Original Message-----
    From: Chris <com>
    To: com
    Cc: org
    Sent: Sat, 26 Mar 2005 13:49:53 -0600
    Subject: Re: hyper threading.

    com wrote: [/ref]
    I [/ref]
    reading 
    >
    >
    > Yes, that's all you need. Just add that line, rebuild and reinstall[/ref]
    the 
    bang 

    If you feel someone is in error - feel free to jump in and offer what
    you feel to be correct information.

    Sometimes sitting back and not correcting someone is far worse then
    someone offering information based on what they know, experience, or
    what have you.

    In this case, by NOT offering the correct information, YOU are just as
    much to blame for what you say is going on.

    For those of us that don't answer, we either don't know (as is the case
    wit myself) OR, they have not had a chance to read the thread.

    --
    Best regards,
    Chris

    It is a simple task to make things complex, but a complex
    task to make them simple.

    em1897@aol.com Guest

  6. #6

    Default Re: hyper threading.

    com writes:
     

    Where can I see the results of your own exhaustive tests?

    The purpose of hyperthreading is to keep all hardware on the
    microprocessor working. Many instructions use only certain parts of the
    chip, leaving other parts idle. By allowing two execution contexts to
    be maintained simultaneously, hyperthreading makes it possible to better
    utilize hardware that might otherwise sit idle. The ideal case would be
    two threads executing completely different instruction sequences that
    use very different parts of this chip. I don't have exact figures but
    I'd guess that in ideal situations you might get 20%-30% extra out of a
    single processor in this way--enough to negate the greater overhead of
    the SMP logic.

    A situation in which hyperthreading would _not_ help would be any type
    of parallel processing, in which multiple threads execute very similar
    instructions. These instructions are likely to require the same parts
    of the microprocessor at the same time, so it's unlikely that they will
    be able to execute in parallel--one will have to wait for the other
    (because the microprocessor has logic areas that can function
    independently and simultaneously, but these areas don't do the same
    things, so they are not redundant logic).

    --
    Anthony


    Anthony Guest

  7. #7

    Default Re: hyper threading.

    com writes:
     

    Why?

    I've explained why hyperthreading can provide a modest gain in
    performance. Now explain to me why it would not.
     

    If you can say with certainty that a degradation occurs, then you've
    already tested, in which case you can show your work. If you haven't
    tested, then you can't say anything with certainty, in which case your
    opinions are pure conjecture.

    A quick look at actual research done by various parties on the Web
    reveals that HT does provide the modest improvements to which I've
    alluded. It's not as impressive as two processors, but then again,
    nobody claimed it would be. It just makes better use of one processor
    and allows you to get more for your money from that processor.

    One advantage that I had not previous mentioned is that the availability
    of a logical processor for dispatch can improve response time in certain
    scenarios, even if the overall processor power doesn't increase that
    much. When compute-bound processes monopolize a single processor, the
    response time of the entire system can suffer; but if you have a second
    processor waiting for dispatch (even a logical HT processor), you can
    immediately attend to other tasks even as the compute-bound process
    runs, as long as it isn't launching multiple threads (which most such
    processes won't do).

    --
    Anthony


    Anthony Guest

  8. #8

    Default Re: hyper threading.

    Well you've proven than if you pick your benchmark you can get the
    result you want.

    So what that says it that the kernel network code doesn't get any
    benefit from HT - given that HT is supposed to benefit diverse user
    tasks and no multiple copies of the same code this is not big news -
    since you have a HT box how about running a less system code intensive
    and more diverse test?

    John


    com wrote:
     
    >
    > it's

    >
    >
    > this shows that you really are a bit foggy. Did you miss the part
    > where with 2 processors you actually do have 2 processors?
    >
    > I can make an argument that networking with 1 processor on 5.4 is
    > better than with 2. For example, with a test similar to the above, with
    > 2 phyiscal processors FreeBSD 5.4 will start dropping packets way before
    > it hits 500Kpps unless you increase the interrrupts/second, which of
    > course increases the system load. And even with the dropped packets
    > (which should reduce the load because it doesnt have to receive
    > and transmit the packet), the load is still higher than for 4.x with
    > a single processor.
    >
    > You and many others regulary say things like "SMP is obviously faster",
    > or "Opterons are noticably faster", but those statements are only true
    > for certain applications. I've tested an Opteron 2.0Ghz against a 3.4Ghz
    > P4, and the results are pretty interesting. For raw performance, ie
    > interrupts/second handling, the P4 wins easily. The P4 wins out of the
    > cache. But once you grow out of the cache and get more memory
    > intensive, the Opteron beats it handily. So which is really faster? You
    > could argue both depending on what benchmark you use. You
    > have to test it in the environment where you plan to use it. Because
    > the answer is almost never black and white.
    >
    >
    >
    > -----Original Message-----
    > From: Anthony Atkielski <fr>
    > To: org
    > Sent: Sat, 26 Mar 2005 23:45:21 +0100
    > Subject: Re: hyper threading.
    >
    > com writes:

    >
    >
    > I haven't read their marketing materials. I'm simply going by the
    > technical descriptions I've read of the architecture.

    >
    >
    > If that were true, then it would be equally true of systems with actual
    > multiple physical processors. In practice, multiple processors provide
    > an obvious performance gain, and hyperthreading does, too, although it's
    > much more modest than the gain obtained from physically independent
    > processors.

    >
    >
    > Nothing needs to be specially optimized for hyperthreading. All you
    > need is at least two threads available for dispatch, with reasonably
    > heterogenous instruction mixes that can use different parts of the
    > processor hardware at the same time. Real-world instruction mixes are
    > often in this category in general-purpose operating systems.

    >
    >
    > Heavily math-oriented applications (or any group of applications that
    > contains similar instruction mixes) are among the least likely to
    > benefit from hyperthreading, because they will tend to use the same
    > processor logic at the same time, effectively rendering hyperthreading
    > moot.

    >
    >
    > Unless FreeBSD is very poorly written indeed, the gain from
    > hyperthreading should still exceed the slight increase in overhead
    > incurred by multiprocessing logic.

    >
    >
    > Where can I see this loss of performance doented?

    >
    >
    > How much is "so substantial"? Where can I see this doented?

    >
    >
    > Then you can show me the measurements. Where are they?
    >
    > A 40% increase in system load just because of multiprocessing is
    > enormous. Where did you get this figure?

    >
    >
    > But the kernel is only a small fraction of overall processor
    > utilization.

    >
    >
    > It doesn't matter whether the machine is a server or a desktop. What
    > matters is the specific mix and nature of applications.

    >
    >
    > Here again, I need to see this doented.

    >
    >
    > Where can I see the measurements?
    >
    > --
    > Anthony
    >
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >[/ref]
    John Guest

  9. #9

    Default Re: hyper threading.

    When you get your machine running without a kernel
    let me know. The kernel is the key to the O/S. If you
    don't need networking and don't have many interrupts,
    then it probably doesnt matter that much.



    -----Original Message-----
    From: John Pettitt <com>
    To: com
    Cc: org
    Sent: Sat, 26 Mar 2005 17:23:40 -0800
    Subject: Re: hyper threading.

    Well you've proven than if you pick your benchmark you can get the
    result you want.

    So what that says it that the kernel network code doesn't get any
    benefit from HT - given that HT is supposed to benefit diverse user
    tasks and no multiple copies of the same code this is not big news -
    since you have a HT box how about running a less system code intensive
    and more diverse test?

    John


    com wrote:
     [/ref]
    actual [/ref]
    provide 
    >
    > it's

    >
    >
    > this shows that you really are a bit foggy. Did you miss the part
    > where with 2 processors you actually do have 2 processors?
    >
    > I can make an argument that networking with 1 processor on 5.4 is
    > better than with 2. For example, with a test similar to the above,[/ref]
    with 
    before 
    faster", 
    3.4Ghz 
    You 
    >
    >
    > I haven't read their marketing materials. I'm simply going by the
    > technical descriptions I've read of the architecture.
    > [/ref]
    more 
    >
    >
    > If that were true, then it would be equally true of systems with[/ref]
    actual 
    provide 
    it's 
    >
    >
    > Nothing needs to be specially optimized for hyperthreading. All you
    > need is at least two threads available for dispatch, with reasonably
    > heterogenous instruction mixes that can use different parts of the
    > processor hardware at the same time. Real-world instruction mixes are
    > often in this category in general-purpose operating systems.

    >
    >
    > Heavily math-oriented applications (or any group of applications that
    > contains similar instruction mixes) are among the least likely to
    > benefit from hyperthreading, because they will tend to use the same
    > processor logic at the same time, effectively rendering hyperthreading
    > moot.

    >
    >
    > Unless FreeBSD is very poorly written indeed, the gain from
    > hyperthreading should still exceed the slight increase in overhead
    > incurred by multiprocessing logic.

    >
    >
    > Where can I see this loss of performance doented?

    >
    >
    > How much is "so substantial"? Where can I see this doented?

    >
    >
    > Then you can show me the measurements. Where are they?
    >
    > A 40% increase in system load just because of multiprocessing is
    > enormous. Where did you get this figure?

    >
    >
    > But the kernel is only a small fraction of overall processor
    > utilization.

    >
    >
    > It doesn't matter whether the machine is a server or a desktop. What
    > matters is the specific mix and nature of applications.

    >
    >
    > Here again, I need to see this doented.

    >
    >
    > Where can I see the measurements?
    >
    > --
    > Anthony
    >
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >[/ref]

    em1897@aol.com Guest

  10. #10

    Default Re: hyper threading.

    Hmm on my boxes the combined sys and intr cpu rarely goes over 20% -
    most of the load is user space. I'd venture that most people running
    user space appllications will see similar numbers. I agree tat a box
    running as a router is not a good candidate for HT - that wasn't the
    question.

    John

    com wrote:
     
    >>[/ref]
    > actual

    >>[/ref]
    > provide

    >>
    >>
    >> it's
    >> 
    >>
    >>
    >>
    >> this shows that you really are a bit foggy. Did you miss the part
    >> where with 2 processors you actually do have 2 processors?
    >>
    >> I can make an argument that networking with 1 processor on 5.4 is
    >> better than with 2. For example, with a test similar to the above,[/ref]
    >
    > with

    >
    > before

    >
    > faster",

    >
    > 3.4Ghz

    >
    > You

    >>
    >>
    >>
    >> I haven't read their marketing materials. I'm simply going by the
    >> technical descriptions I've read of the architecture.
    >> 
    >>[/ref]
    > more

    >>
    >>
    >>
    >> If that were true, then it would be equally true of systems with[/ref]
    >
    > actual

    >
    > provide

    >
    > it's

    >>
    >>
    >>
    >> Nothing needs to be specially optimized for hyperthreading. All you
    >> need is at least two threads available for dispatch, with reasonably
    >> heterogenous instruction mixes that can use different parts of the
    >> processor hardware at the same time. Real-world instruction mixes are
    >> often in this category in general-purpose operating systems.
    >> 
    >>
    >>
    >>
    >> Heavily math-oriented applications (or any group of applications that
    >> contains similar instruction mixes) are among the least likely to
    >> benefit from hyperthreading, because they will tend to use the same
    >> processor logic at the same time, effectively rendering hyperthreading
    >> moot.
    >> 
    >>
    >>
    >>
    >> Unless FreeBSD is very poorly written indeed, the gain from
    >> hyperthreading should still exceed the slight increase in overhead
    >> incurred by multiprocessing logic.
    >> 
    >>
    >>
    >>
    >> Where can I see this loss of performance doented?
    >> 
    >>
    >>
    >>
    >> How much is "so substantial"? Where can I see this doented?
    >> 
    >>
    >>
    >>
    >> Then you can show me the measurements. Where are they?
    >>
    >> A 40% increase in system load just because of multiprocessing is
    >> enormous. Where did you get this figure?
    >> 
    >>
    >>
    >>
    >> But the kernel is only a small fraction of overall processor
    >> utilization.
    >> 
    >>
    >>
    >>
    >> It doesn't matter whether the machine is a server or a desktop. What
    >> matters is the specific mix and nature of applications.
    >> 
    >>
    >>
    >>
    >> Here again, I need to see this doented.
    >> 
    >>
    >>
    >>
    >> Where can I see the measurements?
    >>
    >> --
    >> Anthony
    >>
    >>
    >> _______________________________________________
    >> org mailing list
    >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    >> To unsubscribe, send any mail to
    >> "org"
    >>
    >> _______________________________________________
    >> org mailing list
    >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    >> To unsubscribe, send any mail to
    >> "org"
    >>[/ref]
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >[/ref]
    John Guest

  11. #11

    Default Re: hyper threading.

    Paul A. Hoadley writes:
     

    It's not clear to what extent these measurements represent simultaneous
    processing.

    The presumed advantage of hyperthreading resides in the ability to make
    better use of the processor hardware when you have more than one
    execution thread running AND the threads are doing entirely different
    things. Intel has demonstrated this by running completely different
    tasks at the same time on HT and non-HT systems; the HT systems
    consistently perform better. Both desktop and server systems can
    benefit from this.

    However, if you run measurements that consist of a single execution
    thread, or several execution threads performing the same type of work,
    HT will probably be slower than a UP environment. In this case, HT
    contributes nothing because the various threads are competing for the
    same processor hardware at the same time, so the global instruction rate
    does not improve with HT--and since SMP has higher OS overhead than a
    uniprocessor environment, the net result is a loss of performance.

    In order to profit from HT, then, you must have a mix of different tasks
    running on the system at the same time. This should be the normal case
    for most desktop and server systems, but it is never seen in benchmarks
    unless they are specifically designed to simulate this. Thus, while HT
    may help in real-world applications of servers and desktops, the only
    way to see this in measurements is to make sure they duplicate the type
    of instruction mix seen on these systems in real life.

    The actual architecture of hyperthreading is pretty straightforward, and
    it's pretty clear that it cannot result in degraded performance: either
    it improves performance, or it makes no difference. So the only
    question is whether or not HT improves performance enough in a
    real-world environment to offset the greater OS overhead of managing
    multiple processors. I think that with a heterogenous instruction mix
    of the type likely to be seen in real-world systems, it does (admittedly
    not by much). In some systems that are doing a lot of homogenous
    number-crunching, performance might go down, but it's difficult to
    imagine such a scenario for a server. Some desktops might be in that
    situation, if they are dedicated to single tasks (games, Mathematica,
    CAD, etc.).

    --
    Anthony


    Anthony Guest

  12. #12

    Default Re: hyper threading.

    com writes:
     

    You have to ensure that you're doing the right measurements.
     

    You'll find that the total CPU time required from start to finish for a
    single thread is ALWAYS higher for SMP than for a UP environment, even
    if you have separate physical processors.

    Several things happen when you move from a uniprocessor environment to
    an environment with two or more processors:

    - The total CPU time for each thread increases.

    - The total system load on a per process basis increases.

    - The total throughput of the system improves if there is more than one
    independent process running in the system.

    - Each of the processors runs more slowly than it would if it were the
    only processor running in a UP environment.

    If you run a single-thread benchmark on a MP system, you'll find that it
    runs more slowly than it does on a UP system. If you run multiple
    single-thread independent benchmarks on a MP system, you'll find that
    total CPU time for each benchmark increases over that required in a UP
    system--but the elapsed time required to complete all benchmarks
    substantially diminishes.

    To properly gauge the performance of a multiprocessor system, you must
    run a realistic mix of tasks on the system and measure overall
    throughput. If you do this, you'll find that you always come out ahead
    with multiple processors, even HT processors.

    Hyperthreading is just a special case of multiprocessing that imposes
    some additional restrictions. HT is much more sensitive to similarities
    in instruction mix across processes, because the actual processor
    hardware is being shared. With a sufficiently heterogenous instruction
    mix across multiple execution threads, this isn't a problem; but if you
    are running a single-threaded benchmark, or a series of identical
    single-threaded benchmarks, it can seriously distort your measurements.

    Although adding physical processors diminishes the performance of each
    processor, it still adds overall processing power, up to a certain
    point. The increment is never equal to the actual number of processors
    added, though; that is, if you go from one to two processors, you never
    get a doubling of effective processor power--it's more like 70-80%. The
    percentage increment gets worse with each additional processor, until
    you reach a point at which performance actually starts to decline (the
    point at which this happens is extremely hardware dependent, but it's
    always well beyond two processors).

    Hyperthreaded processors should not diminish in performance just because
    HT is turned on, because the hardware contention that diminishes
    performance in conventional MP systems is largely absent in a HT
    microprocessor. However, since you are really still only sharing a
    single processor with HT, the overall increment is much lower than it
    would be with two physical processors, and it is very sensitive to the
    instruction mix.
     

    I actually read what Intel had to say on how the architecture works, and
    I spent years measuring systems the hard way (with hardware monitors and
    probes), so I know somewhat whereof I speak. Multiprocessing was always
    a significant hot-button issue with customers, as they always wanted to
    know how much they really gained with multiple processors (as opposed to
    what they had been promised).
     

    Load is not a problem, as long as it's below 100%. Since individual
    processors slow down in MP configurations, anything that depends on raw
    processor speed will suffer in an MP configuration. However, overall
    system throughput is greatly enhanced by running with several
    processors. At the same time, the total processor time required to
    complete all tasks is greater in an MP environment than it would be in a
    UP environment--it's the fact that things can run in parallel that
    improves the throughput.

    Moral: if you want to avoid dropping packets in the situation you
    describe, increase the interrupt rate. The additional processing power
    of the system will make this practical.
     

    True, but those "certain applications" are the kind normally executed in
    real-world desktop and server systems. If this were not the case,
    multiprocessing systems would have been abandoned long ago.

    It's almost always better to have a single processor at 2 GFLOPS than it
    is to have two processors at 1 GFLOPS, but if you can't get 2 GFLOPS
    processors, having two 1 GFLOPS processors is the next best thing.

    --
    Anthony


    Anthony Guest

  13. #13

    Default Re: hyper threading.

    com writes:
     

    The kernel represents only a small part of total system utilization and
    throughput. Even if everything is single-threaded through the kernel,
    you can still get performance benefits from multiple processors, because
    they can run userland processes in parallel.

    If total system load is 5% kernel and 80% userland in a UP environment,
    and moving to a MP environment doubles kernel overhead, total system
    load has still increased by only 5%.

    In general, many things must be single-threaded through the kernel
    because of the need for proper synchronization. Thus, the kernel always
    shows more negative effects from MP than the system as a whole, but
    since it is so small in the overall picture, MP still improves global
    performance.

    --
    Anthony


    Anthony Guest

  14. #14

    Default Re: hyper threading.

    Right. Thats what I said. You'll killl your networking.
    So you don't want HT or SMP on a Server. Thats
    what most MP machines are used for.

    -----Original Message-----
    From: Anthony Atkielski <fr>
    To: org
    Sent: Sun, 27 Mar 2005 12:33:36 +0200
    Subject: Re: hyper threading.

    com writes:
     

    You have to ensure that you're doing the right measurements.
     

    You'll find that the total CPU time required from start to finish for a
    single thread is ALWAYS higher for SMP than for a UP environment, even
    if you have separate physical processors.

    Several things happen when you move from a uniprocessor environment to
    an environment with two or more processors:

    - The total CPU time for each thread increases.

    - The total system load on a per process basis increases.

    - The total throughput of the system improves if there is more than one
    independent process running in the system.

    - Each of the processors runs more slowly than it would if it were the
    only processor running in a UP environment.

    If you run a single-thread benchmark on a MP system, you'll find that it
    runs more slowly than it does on a UP system. If you run multiple
    single-thread independent benchmarks on a MP system, you'll find that
    total CPU time for each benchmark increases over that required in a UP
    system--but the elapsed time required to complete all benchmarks
    substantially diminishes.

    To properly gauge the performance of a multiprocessor system, you must
    run a realistic mix of tasks on the system and measure overall
    throughput. If you do this, you'll find that you always come out ahead
    with multiple processors, even HT processors.

    Hyperthreading is just a special case of multiprocessing that imposes
    some additional restrictions. HT is much more sensitive to similarities
    in instruction mix across processes, because the actual processor
    hardware is being shared. With a sufficiently heterogenous instruction
    mix across multiple execution threads, this isn't a problem; but if you
    are running a single-threaded benchmark, or a series of identical
    single-threaded benchmarks, it can seriously distort your measurements.

    Although adding physical processors diminishes the performance of each
    processor, it still adds overall processing power, up to a certain
    point. The increment is never equal to the actual number of processors
    added, though; that is, if you go from one to two processors, you never
    get a doubling of effective processor power--it's more like 70-80%. The
    percentage increment gets worse with each additional processor, until
    you reach a point at which performance actually starts to decline (the
    point at which this happens is extremely hardware dependent, but it's
    always well beyond two processors).

    Hyperthreaded processors should not diminish in performance just because
    HT is turned on, because the hardware contention that diminishes
    performance in conventional MP systems is largely absent in a HT
    microprocessor. However, since you are really still only sharing a
    single processor with HT, the overall increment is much lower than it
    would be with two physical processors, and it is very sensitive to the
    instruction mix.
     

    I actually read what Intel had to say on how the architecture works, and
    I spent years measuring systems the hard way (with hardware monitors and
    probes), so I know somewhat whereof I speak. Multiprocessing was always
    a significant hot-button issue with customers, as they always wanted to
    know how much they really gained with multiple processors (as opposed to
    what they had been promised).
     
    with 
    before 

    Load is not a problem, as long as it's below 100%. Since individual
    processors slow down in MP configurations, anything that depends on raw
    processor speed will suffer in an MP configuration. However, overall
    system throughput is greatly enhanced by running with several
    processors. At the same time, the total processor time required to
    complete all tasks is greater in an MP environment than it would be in a
    UP environment--it's the fact that things can run in parallel that
    improves the throughput.

    Moral: if you want to avoid dropping packets in the situation you
    describe, increase the interrupt rate. The additional processing power
    of the system will make this practical.
     
    faster", 

    True, but those "certain applications" are the kind normally executed in
    real-world desktop and server systems. If this were not the case,
    multiprocessing systems would have been abandoned long ago.

    It's almost always better to have a single processor at 2 GFLOPS than it
    is to have two processors at 1 GFLOPS, but if you can't get 2 GFLOPS
    processors, having two 1 GFLOPS processors is the next best thing.

    --
    Anthony


    _______________________________________________
    org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to
    "org"

    em1897@aol.com Guest

  15. #15

    Default Re: hyper threading.

    Test it yourself. I made a comment about making sure
    you test before you assume that HT is helpful. I don't
    feel compelled to convince you. Do what you want.

    -----Original Message-----
    From: John Pettitt <com>
    To: com
    Cc: org
    Sent: Sat, 26 Mar 2005 17:23:40 -0800
    Subject: Re: hyper threading.

    Well you've proven than if you pick your benchmark you can get the
    result you want.

    So what that says it that the kernel network code doesn't get any
    benefit from HT - given that HT is supposed to benefit diverse user
    tasks and no multiple copies of the same code this is not big news -
    since you have a HT box how about running a less system code intensive
    and more diverse test?

    John


    com wrote:
     [/ref]
    actual [/ref]
    provide 
    >
    > it's

    >
    >
    > this shows that you really are a bit foggy. Did you miss the part
    > where with 2 processors you actually do have 2 processors?
    >
    > I can make an argument that networking with 1 processor on 5.4 is
    > better than with 2. For example, with a test similar to the above,[/ref]
    with 
    before 
    faster", 
    3.4Ghz 
    You 
    >
    >
    > I haven't read their marketing materials. I'm simply going by the
    > technical descriptions I've read of the architecture.
    > [/ref]
    more 
    >
    >
    > If that were true, then it would be equally true of systems with[/ref]
    actual 
    provide 
    it's 
    >
    >
    > Nothing needs to be specially optimized for hyperthreading. All you
    > need is at least two threads available for dispatch, with reasonably
    > heterogenous instruction mixes that can use different parts of the
    > processor hardware at the same time. Real-world instruction mixes are
    > often in this category in general-purpose operating systems.

    >
    >
    > Heavily math-oriented applications (or any group of applications that
    > contains similar instruction mixes) are among the least likely to
    > benefit from hyperthreading, because they will tend to use the same
    > processor logic at the same time, effectively rendering hyperthreading
    > moot.

    >
    >
    > Unless FreeBSD is very poorly written indeed, the gain from
    > hyperthreading should still exceed the slight increase in overhead
    > incurred by multiprocessing logic.

    >
    >
    > Where can I see this loss of performance doented?

    >
    >
    > How much is "so substantial"? Where can I see this doented?

    >
    >
    > Then you can show me the measurements. Where are they?
    >
    > A 40% increase in system load just because of multiprocessing is
    > enormous. Where did you get this figure?

    >
    >
    > But the kernel is only a small fraction of overall processor
    > utilization.

    >
    >
    > It doesn't matter whether the machine is a server or a desktop. What
    > matters is the specific mix and nature of applications.

    >
    >
    > Here again, I need to see this doented.

    >
    >
    > Where can I see the measurements?
    >
    > --
    > Anthony
    >
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >
    > _______________________________________________
    > org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to
    > "org"
    >[/ref]

    em1897@aol.com Guest

  16. #16

    Default Re: hyper threading.

    You know, you spout all of this wonderful theory without considering
    the quality of the implementation. Everything is implementation.
    And a key point that you consistently overlook is that
    FreeBSD 5.x is a particularly poor implementation of SMP.
    Linux and Dragonfly get 80% improvement in performance
    with a 2nd processor, and FreeBSD doesn't. Theory is
    meaningless if the implementation s, which is more
    than just part of the point. The concept that the kernel
    is poorly implemented by userland is well done is just not
    an assumption that you can make.

    -----Original Message-----
    From: Anthony Atkielski <fr>
    To: org
    Sent: Sun, 27 Mar 2005 12:33:36 +0200
    Subject: Re: hyper threading.

    com writes:
     

    You have to ensure that you're doing the right measurements.
     

    You'll find that the total CPU time required from start to finish for a
    single thread is ALWAYS higher for SMP than for a UP environment, even
    if you have separate physical processors.

    Several things happen when you move from a uniprocessor environment to
    an environment with two or more processors:

    - The total CPU time for each thread increases.

    - The total system load on a per process basis increases.

    - The total throughput of the system improves if there is more than one
    independent process running in the system.

    - Each of the processors runs more slowly than it would if it were the
    only processor running in a UP environment.

    If you run a single-thread benchmark on a MP system, you'll find that it
    runs more slowly than it does on a UP system. If you run multiple
    single-thread independent benchmarks on a MP system, you'll find that
    total CPU time for each benchmark increases over that required in a UP
    system--but the elapsed time required to complete all benchmarks
    substantially diminishes.

    To properly gauge the performance of a multiprocessor system, you must
    run a realistic mix of tasks on the system and measure overall
    throughput. If you do this, you'll find that you always come out ahead
    with multiple processors, even HT processors.

    Hyperthreading is just a special case of multiprocessing that imposes
    some additional restrictions. HT is much more sensitive to similarities
    in instruction mix across processes, because the actual processor
    hardware is being shared. With a sufficiently heterogenous instruction
    mix across multiple execution threads, this isn't a problem; but if you
    are running a single-threaded benchmark, or a series of identical
    single-threaded benchmarks, it can seriously distort your measurements.

    Although adding physical processors diminishes the performance of each
    processor, it still adds overall processing power, up to a certain
    point. The increment is never equal to the actual number of processors
    added, though; that is, if you go from one to two processors, you never
    get a doubling of effective processor power--it's more like 70-80%. The
    percentage increment gets worse with each additional processor, until
    you reach a point at which performance actually starts to decline (the
    point at which this happens is extremely hardware dependent, but it's
    always well beyond two processors).

    Hyperthreaded processors should not diminish in performance just because
    HT is turned on, because the hardware contention that diminishes
    performance in conventional MP systems is largely absent in a HT
    microprocessor. However, since you are really still only sharing a
    single processor with HT, the overall increment is much lower than it
    would be with two physical processors, and it is very sensitive to the
    instruction mix.
     

    I actually read what Intel had to say on how the architecture works, and
    I spent years measuring systems the hard way (with hardware monitors and
    probes), so I know somewhat whereof I speak. Multiprocessing was always
    a significant hot-button issue with customers, as they always wanted to
    know how much they really gained with multiple processors (as opposed to
    what they had been promised).
     
    with 
    before 

    Load is not a problem, as long as it's below 100%. Since individual
    processors slow down in MP configurations, anything that depends on raw
    processor speed will suffer in an MP configuration. However, overall
    system throughput is greatly enhanced by running with several
    processors. At the same time, the total processor time required to
    complete all tasks is greater in an MP environment than it would be in a
    UP environment--it's the fact that things can run in parallel that
    improves the throughput.

    Moral: if you want to avoid dropping packets in the situation you
    describe, increase the interrupt rate. The additional processing power
    of the system will make this practical.
     
    faster", 

    True, but those "certain applications" are the kind normally executed in
    real-world desktop and server systems. If this were not the case,
    multiprocessing systems would have been abandoned long ago.

    It's almost always better to have a single processor at 2 GFLOPS than it
    is to have two processors at 1 GFLOPS, but if you can't get 2 GFLOPS
    processors, having two 1 GFLOPS processors is the next best thing.

    --
    Anthony


    _______________________________________________
    org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to
    "org"

    em1897@aol.com Guest

  17. #17

    Default Re: hyper threading.

    com writes:
     

    Somethings can be derived directly from theory. If you know the design
    of the hardware, you can predict that two processors will provide x%
    increment of throughput over a single processor, even if you don't
    actually measure them.

    In my case, I cite both theory and my own experience in measuring actual
    systems. The general principles of behavior of multiprocessor systems
    are well understood, although specific implementations vary. It is
    clear, based even on design data alone, that hyperthreading will
    generally improve throughput and should never diminish it (disregarding
    OS overhead). It is equally clear that the gain won't be as great as
    having physically independent processors, but the idea of putting more
    of the idle processor logic to work is a good one.
     

    I'd need to see measurements to substantiate this.

    In general, when it comes to optimization, it's best not to fret too
    much over how many percentage points of processor power or throughput
    you gain or lose with specific configuration or implementation choices.
    If your system is running so close to the wire that five percent makes
    the difference between 100% busy and less than 100% busy, you need more
    hardware in any case.
     

    Actually, it's not something that I spend a lot of time thinking about.
    Right now, my production system is never more than 0.4% busy. And if it
    were 99% busy, I'd be looking at faster hardware, no matter what OS or
    HT/MP options I might have implemented.

    --
    Anthony


    Anthony Guest

  18. #18

    Default Re: hyper threading.

    com writes:
     

    Beyond a certain network load, you have to increase the number of timer
    interrupts per second no matter how fast your processors are or how many
    of them you have, if you are polling your I/O interfaces instead of
    being driven from interrupts.

    I don't like the idea of routinely running 1000 timer interrupts per
    second, but I note that FreeBSD 6.x apparently is moving to this number
    (?). I'd prefer that it be readily configurable.

    There are other options but I'm not sure how well x86 hardware supports
    them. Having a very accurate, very high resolution elapsed-time counter
    on the processor(s) can help lower overhead by allowing the OS to get
    accurate time information without waiting for an interrupt and with
    execution of only a single instruction. Having programmable, very high
    resolution timers would help, too.

    --
    Anthony


    Anthony Guest

  19. #19

    Default Re: hyper threading.

    On Saturday 26 March 2005 22:45, Anthony Atkielski wrote: 
    >
    > I haven't read their marketing materials. I'm simply going by the
    > technical descriptions I've read of the architecture.

    >
    > If that were true, then it would be equally true of systems with actual
    > multiple physical processors. In practice, multiple processors provide
    > an obvious performance gain, and hyperthreading does, too, although it's
    > much more modest than the gain obtained from physically independent
    > processors.[/ref]

    The situation is very different.

    Multiple processors can run multiple processes at the same time. A HT
    processor can only run two threads from the same process. And most software
    isn't multithreaded.
    RW Guest

  20. #20

    Default Re: hyper threading.

    RW writes:
     

    This is incorrect. HT processors don't care where the threads come
    from; it is possible to run threads from two completely different
    processes on the same HT processor. The threads have completely
    independent architectural states and can come from anywhere in the
    system.

    However, the design of hyperthreading favors a certain amount of
    commonality between the contexts of each thread. While it's best to
    have different instruction mixes, it helps if both threads are executing
    in the same memory spaces, since resources such as on-device cache are
    shared between the threads in the HT processor. Completely different
    threads in different processes executing out of different areas of
    memory might cause more contention for cache and similar resources (TLB,
    etc.), diminishing the advantage of hyperthreading.

    Also, spin waits need special consideration on HT processors. If one
    thread spins on a gate or semaphore held by the other thread, it
    effectively slows the other thread down, keeping both threads moving
    more slowly than they might if they were in completely separate
    processors. A solution for this suggested by Intel is the PAUSE
    instruction, which forces complete execution of a spin-wait instruction
    before the next execution can begin, thus freeing resources for the
    other thread in the processor. Intel recommends the use of PAUSE even
    when HT processors are not being used.

    Still another recommendation is to schedule first physically independent
    processors, then HT logical processors. This requires that the OS be
    aware of the difference between the two. This usually makes more
    efficient use of processor resources, except for some very specific
    cases where running two threads on the same HT processor might run as
    fast or faster than running them separately (if they are referencing a
    lot of the same shared resources, such as cache).

    Intel claims up to a 30% improvement in throughput for an HT processor
    as compared to a normal processor. For truly separate physical
    processors, the improvement is more like 60%, and possibly much more.

    Hyperthreading should not be seen as a substitute for multiple
    processors. It's more like a way to make better use of each processor.

    Hyperthreading is especially useful when multiple execution threads
    exist in a common context, such as multithreaded daemons or
    multithreaded desktop applications. In these situations, the HT
    architecture is used to the fullest, with corresponding improvements in
    performance.

    Recent changes in FreeBSD architecture to allow a multithreaded kernel
    are among the situations in which hyperthreading can be put to good use.
    The new multithreaded architecture of Apache 2.x should also be able to
    put HT to good use.

    --
    Anthony


    Anthony Guest

Page 1 of 3 123 LastLast

Similar Threads

  1. CSS Hyper Text Problem
    By Poinkster in forum Dreamweaver AppDev
    Replies: 1
    Last Post: April 22nd, 11:29 AM
  2. how to use hyper columns in datagrid
    By man in forum ASP.NET Data Grid Control
    Replies: 1
    Last Post: April 21st, 09:01 PM
  3. Hyper Link Problem
    By scott11 in forum Macromedia Dynamic HTML
    Replies: 1
    Last Post: March 21st, 06:49 PM
  4. Hyper Help
    By Hypetension in forum Macromedia Director Basics
    Replies: 2
    Last Post: September 20th, 08:53 PM
  5. Intel Hyper Threading on Linux..
    By Louie Miranda in forum Debian
    Replies: 6
    Last Post: July 29th, 12:00 AM

Bookmarks

Posting Permissions

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139