Michael D. Ober wrote:

"Martin 53N 1W" <ml_news@ddnospamddml1dd.co.uk.dd> wrote in message

[...]

Actually, since Windows shares read-only executable images in memory and

[...]

image is from the save .EXE file.  As a general rule, SETI Driver only uses
a single CLI executable.  The Windows Task Manager doesn't show this,

That's a nice optimisation for that special case. Certainly good for s@h. Not sure how often it can otherwise be taken advantage of on home computers. Very useful for servers running multiple copies of some one service... just like the s@h example...

however.  Windows does other performance tricks such as not writing
read-only pages to the swap file.  Instead, it simply discards them and then
re-reads them back from the original location on disk, thus saving a disk
write when the EXE's physical memory is needed for other processes or data.
I assume that all modern OS's, including Linux, do this as well.

An obvious 'quick' Windows tweak for performance.

Interesting.

Don't know all of the linux optimisations that are done. However I would doubt that such a 'bolt-on' optimisation would be accepted. The linux developers are very thorough and would follow a 'consistent' approach with strict kernel divisions that are robust across all platforms and all configurations.

Aside: There is a deep 'debate' in full flow at the moment on news:linux.kernel about the name spaces (naming system) for all file systems and for presenting a robust consistent and useable interface for all requirements. A new file system is being developed which is now forcing issues that have been patched over since file systems began... Good stuff.

I doubt anything like that will get supported either. Intel's 'HT' is
likely a very short lived design 'workaround' for attempting to balance
out the bottlenecks in their P4 CPU architechture.

Dual core CPU designs date back to the 1970s with the IBM System 370.  This
is a tried and true design for boosting performance without increasing power

[...]

The P4 is a collection of execution units with deep pipelining (for marketing driven claims of very high clock speeds) coordinated by _two_ sets of stored state. You have a single core but with a 'split' 'mind'. This is similar to what was done with early super computers that had deep vector units.

Note that other CPUs achieve better performance for lower clock speeds.

There's still good questions as to whether RISC or CISC is better.

Also, whether two coupled but independent cores in the same package are 'better' than a large collection of execution units on the same die with multiple CPU threads as in Intel's HT. "Better" here is in terms of price/performance.


[...]

'fork' and unix 'vfork' mechanisms that run two processes from the one

[...]

know how.  You can do this same in Windows simply by using the same .EXE for
your multiple instances.  SETI Driver takes advantage of this by only

[...]

Similar results but done at different levels in the respective systems. Windows here is taking a more 'tweaky' approach where the affected program is unaware of what is happening. You must carefully follow a magic route for the run context to make it happen. The OS then 'notices' that it is the same code and so optimises the memory management. This is indeed one way of doing things.

In the linux example, the program itself deliberately determines how it and a 'copy of itself' runs. ("fork" is pretty fundamental to unix.) The OS is 'directed' to behave in a certain expected way.

Note, this is not a Linux bashing post.  It is simply a clarification of
what Windows is capable of doing if you know the OS's execution model.

The tone and content are all wrong for bashing (:-))

There is the old phrase of "horses for courses". Better understanding is better than blind bashing.


Regards,
Martin