Thanks for the tip--I was not aware of that command. I can see that it would be very useful for all kinds of benchmarking.
Unfortunately, it is not useful for my case, however. Maybe I should have put more details in original posting: I will be benchmarking various random code from within a Java program, and Java already offers APIs for accessing wall clock, system, and user times. So I already have all that functionality--in nice wonderful platform independent form.
I was just wondering if unix had the same idle task issue (and similar solution) as windows does.
Note: I will switch to using the term idle process below, as it looks like idle task in unix refers to a real specific process. (Maybe background process or daemon or something else would be a better term?)
You say:
A non-sequitur is a conclusion that does not follow from its premises--I was not aware that my mere inquiry had either premises or a conclusion!
Maybe what you mean is that my question simply has no meaning in unix. Is that because unix has no concept of idle processes like windows? Or is it because there is no way that idle processes can suddenly come alive in the middle of your benchmark like they can in windows?
The web searching that I did on the time command said nothing about it first committing idle processes, by the way.
Question: why would you "commit" idle processes before benchmarking, when in real life whatever you are benchmarking would probably have to run when these idle process run?
Did you read that Microsoft tech link that I included in my first post?
"Commiting idle tasks" in windows means that idle (usually low priority?) processes, which have not completed yet, are suddenly given priority and run.
You want to do this before a benchmark so that no such idle task suddenly comes alive in the middle of your benchmark for whatever reason and contaminates your benchmark.
The web research that I did just now does not seem to say anything about init being able to cause idle processes to be forced to run, but maybe I missed something.
Generally, when you publish benchmarks, you do so running no other programs. You may also try to turn off many background services/processes/whatever.
You do this so that other people running your benchmark on the same hardware are more likely to get the same result as you.
The more stuff besides your actual benchmark that can possibly be running during benchmarking, the less reproducible your results become.
The exception to these comments are when you specifically want to see how your task runs on a loaded system of some kind, but this is less common.
If unix simply lacks the functionality that windows has in this area--fine. Idle tasks suddenly running in the middle of your benchmark is usually a rare event. Its certainly more important that you do obvious simple things like make sure that no other non-idle tasks are running. But having an api for committing idle tasks like windows does certainly is icing on the cake, as it can eliminate the rare possibility.
>If unix simply lacks the functionality that windows has in this area--fine. Idle tasks suddenly running in the middle of your benchmark is usually a rare event. Its certainly more important that you do obvious simple things like make sure that no other non-idle tasks are running. But having an api for committing idle tasks like windows does certainly is icing on the cake, as it can eliminate the rare possibility.
Well the point is: This is the true difference between a true preemptive multitask/multiprocessing OS (like ***x) and almost and not quite yet (still has some cooperative behaviour) OS like Win...
E.G. when Windows has decided to scan your drives, you cannot work till it gives you back the hand (cooperative...), at this point it never happens on a normally tuned unix... the time sharing is efficient under unix, not all that under windows... So you cant talk of lack of functionality that windows has... windows has added something to cure some insane behaviour...
While, like any good person, I share your dislike of Microsoft, I am pretty sure that you are wrong for WinNT and successors: I was under the impression that they have always been fully preemptive; see Preemption (computing) - Wikipedia, the free encyclopedia
People sometimes complain about the scheduler in NT, just as they do in, say, Linux, but I have never seen anyone claim that the NT kernel partly operates in cooperative multitasking mode. Find a good reference that proves otherwise, and I will be grateful for the enlightenment.
What usually happens in windows if an idle task kicks in during benchmarking is that both run concurrently (on a multi cpu box) and/or apparently concurrently (i.e. time sliced, especially if there is just a single cpu) and the presence of that now active idle task distorts your results to some extent.
I imagine that unix is just as vulnerable, at least in principle, tho perhaps not in practice (e.g. maybe typical unix boxes just don't have idle tasks that can suddenly become active; then again, they usually seem to have all sorts of background daemons...).
Ok. I don't want to speak for the entire Unix world , but I guess we are more concerned with performance under regular load, rather than matching numbers within platforms...
One method that you could use to achieve something vaguely similar would be to run your unix test on single user mode; only a portion of services run when the box is running on single user mode. Any service that your particular application may need can be started, and you could kill whatever service may pop up during your benchmark (mostly killing the cron daemon would do).
, but I guess we are more concerned with performance under regular load, rather than matching numbers within platforms...