lkml.org 
[lkml]   [2004]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Semaphore assembly-code bug
    linux-os wrote:

    > You just don't get it. I, too, can make a so-called bench-mark
    > that will "prove" something that's so incredibly invalid that
    > it shouldn't even deserve an answer. However, because you
    > are supposed to know what you are doing, I will give you
    > an answer.
    >
    > It is totally impossible to perform useful work with memory,
    > i.e., poping the value of something from memory into a register,
    > without incurring the cost of that memory access. It doesn't
    > matter if the memory is in cache or if it needs to be read
    > using the memory controller. Time is time and it never runs
    > backwards. I spend most of my days with hardware logic analyzers
    > looking at the memory accesses so I damn-well know what I
    > am taking about. That memory-access takes a time-slot that
    > something else can't use. You never get it back. It is gone
    > forever. This is very important to understand. If you don't
    > understand this, you can fall into the "black-magic" trap.
    >
    > Modern CPUs make it easy for so-called software engineers to
    > perceive so-called facts that are not, in fact, true. Because
    > it is possible for the CPU to perform memory-access independent
    > of instruction sequence (so-called parallel operations), it is
    > possible to make bench-marks that prove nothing, but seem to
    > show that a read from memory is free. It can never be free. It
    > will eventually show up. It was just deferred. Of course, if
    > your computer is just going to run that single bench-mark, then
    > return to a prompt, you can readily become victum of a very
    > common error because there is now plenty of time available to
    > just spin (or wait for an interrupt).
    >
    > So, if you really want to make things fast, you keep your
    > memory accesses to the absolute minimum. Poping something
    > from the stack is the antithesis of what you want to do.
    >
    > It's really amusing. Software development has devolved
    > into some black magic where logic, mathematics, and
    > physical testing no longer thrive.
    >
    > Instead, we must listen to those who profess to know
    > about this magic because of some innate enlightenment
    > imparted to those favored few who are able to perceive
    > the trueness of their intellectual perception without
    > regard for contrary physical observations.
    >
    > It's wonderful to not be bothered by tests, measurements,
    > documentation, or other facts.
    >
    > Wake up and don't be dragged into the black-magic trap.

    The election is over, we can adopt a civil non-confrontational tone
    again... Linus is not always right, but like most people he responds
    better to "let me give you additional information" than "I know more
    than you, take my word for it."

    In this case, I think Dick does have a point on memory to cache use. It
    appears from what little stuff I have here that with HT cache access is
    serialized, and that memory access, even to L1 cache, might under some
    circumstances be delayed. I won't guess if you would ever see that in
    practice.

    Getting information out of noisy measurements is not easy, and while
    Dick is probably right that the lowest time is the "real" time, if the
    average is lower doing something else, isn't that what we want?

    My response test reports low, high, average, median, and 90th percentile
    values, and depending on whether you want the best average, best
    typical, or worst case avoidance you might find any of them useful. Oh,
    and S.D. of the data to hint on how much you trust the results. I don't
    think any of the test programs produce the definitive result, and I see
    that results change depending on the CPU.

    I think there are a lot of things more deserving this level of
    consideration.

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:07    [W:4.125 / U:0.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site