How fast is AmigaOS at executing programs?

At work we had a kind of special problem with our build system that runs in Cygwin and Linux. On Linux the dependency generation is probably 20 times as fast as on windows+cygwin.

It turned out to be completely related to how fast a proces can be created in cygwin vs. Linux.

We tried a simple experiment:
while true; do date; done | uniq -c

This will execute 'date' as fast as possible and uniq will print a line everytime date prints something different, i.e. once a second.

On my WinXP Core i7 @ 2.66GHz uniq says that date was executed about 64 times/second. That's pretty slow, but we knew that already. On another much slower Linux machine the same number was 1400! Hugely much faster but still what you might expect. Surprizingly a Win7 machine with Core i7 could only manage 14 executions of date per second in cygwin. Strange, but it could be related to antivirus and stuff maybe.

Anyway, I decided to test this on OS4 (G4 @ 866MHz) and I expected high values due to the light-weight processes of Amiga OS. Unfortunately the while loop could not be used with uniq because uniq would not print anything while the loop was running and the loop could not be ended with Ctrl+C in abc-shell. So I had to let date print live instead which probably affected the result a bit due to our ultra slow console printing on Amiga OS.

This is the result of "while true; do date; done": 62 printouts/second. Executing with explicit path I could get 70.

I also tried this in an AmigaDOS script:
lab upp
version
skip upp back

Result: 180 executions/second.

Of course this machine is slower than the Linux machine and much slower than the Core i7, but I still expected higher values.

Comments?

@Deniil

This kind of bench mark is even more meaningless than most benchmarks. DOS scripts aren't designed for speed.

@xeron

Since the scripts are so rediculously small their execution time is negligable compared to loading an executable and run it. But feel free to make a loop around SystemTags instead if you wish.

But DOS scripts are better for real life tests since a lot of them, as small one-liners, are often used inside makefiles. Specially crafted benchmark batch executables are not.

@Deniil

In a *nix script, are the individual commands (date, uniq) interpreted or JITed? Do the commands remain resident after each use or is each command recalled from disk again each time? The way the script is executed will change the perceived time drastically.

I'm not surprised by the ratio of Windows to Linux speeds, but it could be aggravated by a number of factors, as you have said.

I'd like to see if the script could be made to work under AmigaOS - even under abc-shell. If the "date" and "uniq" commands are made resident before the test, that would speed things up a lot. But would it be fair?

@Deniil

For what it's worth, MSYS/MinGW is *much* faster than Cygwin. Use it if you can. There's something about Cygwin's implementation of fork, spawn, et al that causes huge delays. EDIT: I.e. The delays are caused by Cygwin, not Windows.

@Deniil

FYI: I used to process a lot of web server log files. Windows 2000 servers at twice the MHZ, using Perl, or Visual Basic, or shell scripts could not keep up with a slower processor reduced RAM NetBSD Unix box using Perl or Shell scripts. The processes would take about 30 minutes in Unix, while Windows would take hours.

@Deniil
The results may be meaningless since you didn't do an apples-to-apples comparison.

@Deniil

Quote:

For an even more pointless test but probably a better speed try:

lab upp
version >>ram:data
skip upp back

with a very rough 10 secondish test I got 136 on my 733mhz sam.

We also concluded that it must be the cygwin implementation, not windows. Also duscussed MinGW but we think it might be difficult moving our huge build system.

Comparing different things is exactly the point here. Linux does it one way, which is obviously faster, windows+cygwin does it one way which turns out to be extremely slow and Amiga (D)OS does it one way which seems less than optimal too.

Doing all tests in exactly the same way is not realistic and therefore even more pointless.

@severin
I also tried version >>ram:data but reopening and seeking the output stream turned out to be a quite slow process. 136/10 seconds is like 14/second. Very slow. I got something similar when tested this too.

@Deniil
Quote:
So exactly how small is it? If you don't know the precise answers then you do not have a valid experiment.

@Deniil

I can tell you that under MSYS/MinGW, your loop produces unique output every ~56 occurrences, which corresponds to a Windows (PC clock) tick of ~18 ms. Without further evidence to the contrary, I would say the Bash while loop executes every tick, regardless of system speed. Variations would be caused by outside factors. So, ignore my comments about Cygwin as they don't apply in this case. (Cygwin is in fact slower than MinGW and other Windows-native APIs, which is particularly noticeable when making large projects like GCC.)

Linux should have a default tick of 1 ms (1000 Hz). You may have changed the tick rate in your kernel, or Bash (or whatever shell you're using) may behave differently on your system.

EDIT: My point here is the question you're actually answering with your experiment is, "What is the iteration rate of a Bash while-loop?"

EDIT2: I'm beginning to sound like a Windows pundit (and really, I am), but a similar construct using a batch file, a custom date command, and a port of BSD's uniq produces unique output ~420 times per second. Another similar construct using JScript produces unique output ~520 times per second. Again, it's entirely dependent on how quickly your host environment, i.e. your shell, can spawn processes, not your operating system.

@Deniil

Quote:

I got 136 PER SECOND, over the 10 seconds I got 1364 executions.