Old 486 computer & external CD reader advice needed

[Mike McCarty]

Les Mikesell wrote:
> On Wed, 2006-02-01 at 14:34, Mike McCarty wrote:
> 
>>>>So do many other apps, like my web browsers. I think this
>>>>qualifies as "creating a new process".
>>>
>>>
>>>No, it has next to nothing to do with process creation.
>>>'cat' would be closer.
>>
>>I know what I'm talking about, we're just talking about
>>different things, using the same words, I suppose.
> 
> 
> "Process" means something very specific in unix-like

More precisely and accurately, it means an instance
of a running program.

> systems.  It's what you get when the fork() system
> call completes successfully, and you can benchmark
> it by measuring forks/second.

This is the usual means of process creation, yes.
It's not a definition of a process.

>>I have 15+ years of experience optimizing real time
>>operation on telephony equipment, so I do know.
>>
>> From a user's perspective, Linux is noticeably slower
>>on the same hardware.
> 
> 
> Not necessarily.

I didn't say "necessarily", nor "for every user", nor
"in every circumstance".

Men have more upper body strength than women. Doesn't mean
there aren't women around whose every muscle is stronger
than mine.

>> From a cycle-by-cycle perspective, Windows (when quiescent)
>>is not a cycle hog. I find that CPU intensive apps (like
>>multiprecision numerical computations, Drhystone, etc.)
>>when compiled using DJGPP and run under Windows XP, 95, and
>>98 runs in the same time as the same source compiled and
>>run under Linux.
> 
> 
> Yes, if you aren't making system calls, the OS is not
> all that relevant except for it's time-slicing overhead.

Even the time-slicing overhead is negligible. The difference
between using the same program running MSDOS 6.0 and WinXP
console was < 0.1% on my machine, using Dhrystone compiled
with DJGPP v2. I *know* what the quiescent overhead
of MSDOS 6.0 is :-)

> Try running a few hundred of your computations at once
> in separate processes so you have a chance at noticing.

Possibly. That's certainly something worth trying.
Hmm, 100 copies of Dhrystones running is an intriguing
concept. It would take some sort of script to start them
all. I'm not familiar enough with Windows to be able to
start 100 copies of Dhrystones running in console a window
from a script (batch file). On Linux, I'd just put them
all in the background.

Are you familiar enough with WinXP to suggest a means
for running 100 concurrent copies of a console app (without
having to start 100 windows up) and timing the results?
Or, if 100 console windows must be started, some way
of starting them all, and then having them load up the
program, but wait for some signal which would make them
all start at once? Something like that, so window creation
time doesn't enter into it (though program load time
probably should enter in).

>>I haven't specifically timed actual context times or
>>interrupt latencies. But for actually starting applications,
>>Linux is definitely and noticeably slower.
> 
> 
> I'll agree if you always qualify that as "X applications".
> I'm sure you realize that many useful things do not
> require the creation of a screen window.

Certainly. Just running Drystone doesn't require creating
a window. Nothing I have written does, as I don't particularly
like GUIs, and have never written a GUI app.

I wonder what could be done to speed Linux/X up?

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!