Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Fwd: Going Faster...!

OSR_Community_UserOSR_Community_User Member Posts: 110,217
>"McDonald, Pete" wrote:
>> you are running in memory entirely, is it large enough to exceed the cache?
>> If not, that would explain why you don't see any benefit to faster bus
>> speed.

Yes, we are probably exceeding the L2/L1 cache capacity, which is why I
expected bus speed to make a difference.

>> As for core speed differences. I am curious to know exactly what you are
>> trying to measure here. While you may have successfully isolated the core
>> speed as a factor, I am not at all comfortable that this has any direct
>> bearinng on overal system performance (at the CPU/Memory layer). For
>> example, FP instructions are handled very differently by different
>> processors, why is it reasonable to exclude them?

We're not trying to develop a "benchmark", we're simply trying to optimize
the performance of a specific set of software. It happens that this code
doesn't need to do much, if any, floating point.

>> My suggestion would be to use the standard benchmarks, because they are the
>> only things that have any real meaning.

See above... we're not trying to find the fastest platform on which to run a
benchmark, but the fastest platform on which to run our in-house developed code.

RLH

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    ----- Original Message -----
    From: "Richard Hartman" <[email protected]>
    To: "NT Developers Interest List" <[email protected]>
    Sent: Tuesday, May 30, 2000 11:29 AM
    Subject: [ntdev] Fwd: Going Faster...!


    > >"McDonald, Pete" wrote:
    > >> you are running in memory entirely, is it large enough to exceed the cache?
    > >> If not, that would explain why you don't see any benefit to faster bus
    > >> speed.
    >
    > Yes, we are probably exceeding the L2/L1 cache capacity, which is why I
    > expected bus speed to make a difference.

    One thing I've found in performance work that that if you turn a knob, and
    nothing happens, then perhaps the knob is disconnected, i.e., did you do anything
    that confirmed that the bus was actually clocking at the faster rate? Similarly,
    did you verify that the core speed was actually faster? You can write simple
    benchmarks for these (i.e.,
    // Thrash the cache to verify bus is faster.
    char a[1024*1024*4]; for (k=0; k < n; k++) for(i=0; i < sizeof(a); i+=128*1024) { a[i] ++; }
    // Is core speed faster?
    for(i= 0; i < n; i++) {}
    )

    -DH


    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online