Re: [tlug] Giving a program priority briefly

["Nguyen Vu Hung" <vuhung16plus@example.com>]

On 6/10/07, Darren Cook <darren@example.com> wrote:
> Thanks for the replies. It sounds like nice -20 is about the best I can
> get, easily. I've been running "w" before running the test, and
> waiting/kill-ing if it is high, which seems to have helped consistency.
You are playing with the system, not the code that is what you are
refactoring...

> Yes (though 2.5 minutes is a long time to run a nice -ve process!).
> However a 10-15 second compile and a 5 second benchmark is very
> appealing; I can refactor just a couple of lines at a time and test to
> see what affect it has.
You can do it less often. What I wanted to said is that the larger
number of samples, the more accuracy execution time will you get.

> P.S. For any C++ programmers out there: I was starting with a
> well-optimized program known as the fastest of its type ("libego" a UCT
> monte-carlo computer go program, C++, available under GPL), and wanted
> to refactor to make it easier to experiment with new algorithms.
> Ironically I've so far made it 5% *quicker*, mainly by replacing a
> function call with a functor class and merging two loops into a single loop.
What is the methodologies ?
Is g++ the compiler?
Have you ever heard of lcov or tools like such?
http://ltp.sourceforge.net/coverage/lcov.php
When you use that, we know exactly what part of code need to be
refactored - not by reading the code.

> I also got some surprises such as calling a function in the same class
> gave no slowdown, but moving the function (marked as inline) to the base
> class (these are classes with no virtual functions) gave nearly over a
> 5% slowdown. So I used a macro.
Ref. above.

--
Best Regards,
Nguyen Hung Vu
vuhung16plus{remove}@example.com
An inquisitive look at Harajuku
http://www.flickr.com/photos/vuhung/sets/72157600109218238/