Re: Inline assembler reference



I am surprised - you got this correct. You can get a good profile by
repeating the test many times and then interrupts will average out on a
dedicated test system.

"anton bassov" <xxx@xxxxxxx> wrote in message
news:759415ebae2446ab866b1d5d271d99ed@xxxxxxxxxxxxxx
Hi mate

When you write user-mode code (or kernel-mode one that runs below
DISPATCH_LEVEL), it is impossible to do 100%-reliable real-life profiling,
because you depend on the external conditions. To give you an idea, let's
say context switch occurs while your "time-critical loop" runs. It is
understandable that the amount of time that you have to wait before your
code is allowed to continue its execution depends on number of threads in
the system, as well as on their priority levels,events they wait
on,etc,etc,
etc....
Therefore, the only thing that you can profile is execution of your code
in
itself, but it does not necessarily correspond to the real-life conditions
your program runs under.

Let's say that, as a result of using assembly, you got 10-20% performance
improvement. However, if you relate this improvement to the ACTUAL (!!!)
time that elapses in between
the very first instruction of the loop gets executed and the moment the
code
breaks out of the loop, it may well happen that you got just 0.1-0.2% or
even 0.01-0.02% improvement - everything depends on the external
conditions
that you cannot change. In other words, the performance gains may be, for
the practical purposes, just negligible.

This is the reason why it just does not make sense to "improve" your code
by
using assembly, unless you are sure that context switches, page faults,
etc
cannot occur while your code runs. No wonder only small parts of Windows
kernel and HAL are written in pure assembly

Anton Bassov


.



Relevant Pages

  • Re: [Full-disclosure] Facebook script injection vulnerabilities
    ... Escaping JS sandbox with literal String reference ... execution of unrestricted JS on canvas pages or profiles ... (mouseclick required on profile pages) ...
    (Full-Disclosure)
  • Re: Loading an I/O intensive program into memory
    ... explicitly loading the lot into RAM. ... You can lock programs into memory, but that may or may not help. ... It's easier to redo the main loop of code in shell than in C. ... Run your program with real input to gather the profile data. ...
    (comp.os.linux.misc)
  • [Full-disclosure] Facebook script injection vulnerabilities
    ... Most of the issues require the victim user to click on a profile box ... execution of unrestricted JS on canvas pages or profiles ... The JS sandbox denies references to Function.constructor ...
    (Full-Disclosure)
  • Re: Devel::SmallProf claims "return 1" needs much time !?
    ... I often find SmallProf to be unreliable, especially when trying to profile ... code portions which are fast on each execution but are executed very often. ... doubt on the entire reliability of the SmallProf output. ... suppose disc caches work their wonders...). ...
    (comp.lang.perl.misc)
  • Re: [OT] Switch question
    ... >any steps to optimise this loop. ... program and determined that the switch statement in this loop is using ... Profile after each change. ...
    (comp.lang.c)