Windows Vista and dual core CPU's..

[dawks]

Its clear of course that Windows NT+ supports dual CPU's, but with dual core systems now becomming much more widespread, and even shifting down to the consumer level, I'm curious as to how Microsoft will bring (enhanced) support into Vista.

Since Windows Vista is now doing much more, and providing ALOT of features/services to other applications (search, windows presentation foundation, .NET), is their code going to be SMP capable? Or just multithreaded and therefore rely on the NT scheduler to assign threads to the different cores? Are they going to provide support for most/all SSE instructions available? Will Windows Vista itself use these instructions? Does Windows XP? (Was SSE2 even out when XP shipped?)

I know I'm kind of asking some odd questions. Windows NT based OS's scale pretty well on the hardware we have, but the kernel is designed in such a generic way. I'm guessing if they started implementing and optimized the OS and the services/code it provides to other programs for the newer more advanced hardware we have (SSE2, SSE3, 3Dnow!, HT, Dual Core, and much larger and faster L2 cache'), we could see even better performance increases. Yes/no?

Keep in mind I believe we might even see quad core systems ship around or after Vista finally ships, (whenever that might be), and dual core will certainly be a regular if not the standard by then, in consumer level systems.

 

[drag]

Vista dropped most those features for now (the search, avalon, .NET foundation) it's mostly a updated version of Windows XP with some updates, some new features, and optional windowing composition with the display. They claim they will add the winfs and avalon stuff later.

But a general purpose OS is inherently smp-capable. It is it's multitasking nature, all that is left is for the OS kernel and scedualing system to make the best use of the aviable cpus by deligating which application/system proccess runs on which cpu.


Individual applications are the rub. They either need to be split up into multiple proccesses and use inter-proccess communication doo-dads or be multithreaded to take advantage of multiple cpus.

 

[Nothinman]

is their code going to be SMP capable? Or just multithreaded and therefore rely on the NT scheduler to assign threads to the different cores?

What's the difference? If the code itself is trying to outsmart the kernel process scheduler something is very wrong here.

Are they going to provide support for most/all SSE instructions available?

That's dependent on the compiler being used since virtually none of Windows should be done in hand-coded asm. And I really doubt any SSE will be used because they'll still want to support Pentium or at least PPro level CPUs without providing dozens of copies of each file.

Will Windows Vista itself use these instructions? Does Windows XP? (Was SSE2 even out when XP shipped?)

AFAIK you can still coax XP to install on a 486 or at least Pentium, so it would seem not.

I'm guessing if they started implementing and optimized the OS and the services/code it provides to other programs for the newer more advanced hardware we have (SSE2, SSE3, 3Dnow!, HT, Dual Core, and much larger and faster L2 cache'), we could see even better performance increases. Yes/no?

Maybe, probably nothing too noticable though. And the cost would be much higher than the benefit. Imagine trying to maintain 1,000,000 lines of asm vs maintaining 1,000 lines of C. Then multiply that times as many architectures as you want to support because if you're going to 'OMG optimize' things with hand-coded asm you might as well go all the way and do one build for each CPU and stuff coded for a P4 might not run on a P3 (not sure of the differences) and sure as hell won't run on IA64 or AMD64 in 64-bit mode.

 

[dawks]

Originally posted by: drag
Vista dropped most those features for now (the search, avalon, .NET foundation) it's mostly a updated version of Windows XP with some updates, some new features, and optional windowing composition with the display. They claim they will add the winfs and avalon stuff later.

Thats going a little far.. the search is clearly there. Its a fairly simple system already developed by the MSN group and in use daily. Avalon is there, the name is now Windows Presentation Foundation.. and .NET will be there too... I think you're under-estimating the changes Vista will bring about. Have you spent anytime watching the videos at Channel9?

But a general purpose OS is inherently smp-capable. It is it's multitasking nature, all that is left is for the OS kernel and scedualing system to make the best use of the aviable cpus by deligating which application/system proccess runs on which cpu.

Sure it is, but I'm thinking some parts of it, some jobs it does, could be better designed to use SMP, rather then just waiting on a general purpose scheduler to handle the work. I'm sure theres a reason a multithreaded application like Photoshop or 3D Studio Max actually have code written for SMP, rather then just relieing on a generic scheduler.

Originally posted by: Nothinman

is their code going to be SMP capable? Or just multithreaded and therefore rely on the NT scheduler to assign threads to the different cores?

What's the difference? If the code itself is trying to outsmart the kernel process scheduler something is very wrong here.

Like I said, why are some applications specifically written for SMP but other multithreaded apps are not. Certain tasks may benefit from specific optimizations rather then relieing on a generic scheduler.

Are they going to provide support for most/all SSE instructions available?

That's dependent on the compiler being used since virtually none of Windows should be done in hand-coded asm. And I really doubt any SSE will be used because they'll still want to support Pentium or at least PPro level CPUs without providing dozens of copies of each file.

Will Windows Vista itself use these instructions? Does Windows XP? (Was SSE2 even out when XP shipped?)

AFAIK you can still coax XP to install on a 486 or at least Pentium, so it would seem not.

I'm guessing if they started implementing and optimized the OS and the services/code it provides to other programs for the newer more advanced hardware we have (SSE2, SSE3, 3Dnow!, HT, Dual Core, and much larger and faster L2 cache'), we could see even better performance increases. Yes/no?

Maybe, probably nothing too noticable though. And the cost would be much higher than the benefit. Imagine trying to maintain 1,000,000 lines of asm vs maintaining 1,000 lines of C. Then multiply that times as many architectures as you want to support because if you're going to 'OMG optimize' things with hand-coded asm you might as well go all the way and do one build for each CPU and stuff coded for a P4 might not run on a P3 (not sure of the differences) and sure as hell won't run on IA64 or AMD64 in 64-bit mode.

Maybe I am under-estimating the ability of the coder/compiler to just detect the available hardware and shift to different code... The binaries themselves must be compiled for the optimizations they want to use? A program that uses these optimizations needs to have multiple exes/dlls for each instruction set? Like I said, ideally they should be able to detect and take a different code path. It doesnt seem like WMP or WME have multiple dlls for different CPU extentions for example..

 

[Nothinman]

Like I said, why are some applications specifically written for SMP but other multithreaded apps are not. Certain tasks may benefit from specific optimizations rather then relieing on a generic scheduler.

Multithreaded apps are usually written for both or either of two reasons.

1) To take advantage of multiple CPUs, the most 'optimization' they should be doing is asking how many CPUs are available and spawning that many threads. The rest of the scheduling has to be left to the kernel process scheduler
2) To seperate the UI from the background processing. Putting the UI in a seperate thread means that while the app is doing it's thing the UI doesn't hang.

In both cases there is nothing the process can do to change how much CPU time it gets or when it's interrupted. Sure, they could probably set the affinity of each thread to certain CPUs but that's pretty dumb because you can't guess the load each CPU will have based on where it's currently at, so you have as much chance of hurting yourself as you do helping.

Maybe I am under-estimating the ability of the coder/compiler to just detect the available hardware and shift to different code... The binaries themselves must be compiled for the optimizations they want to use? A program that uses these optimizations needs to have multiple exes/dlls for each instruction set? Like I said, ideally they should be able to detect and take a different code path. It doesnt seem like WMP or WME have multiple dlls for different CPU extentions for example.

It's definitely possible, but the cost usually far outweights any gains you would get. For very specific tools it might be worthwhile, like WME could probably see noticable benefits, but 99% of the things out there won't.

 

[hooflung]

I think you're under-estimating the changes Vista will bring about. Have you spent anytime watching the videos at Channel9?

I think you need to reword that to "you're under-esimating the changes Vista will bring about to current Window's users."

Nothing they have planned is new. The best thing they brought to the table since windows for workgroups 3.11 is the Registry. Since then the only other notable feature would be their windows media 9 codecs. Other than that... Windows 95/XP just a prettied up, driver supported OS/2 grandchild.

 

[drag]

Originally posted by: dawks

Originally posted by: drag
Vista dropped most those features for now (the search, avalon, .NET foundation) it's mostly a updated version of Windows XP with some updates, some new features, and optional windowing composition with the display. They claim they will add the winfs and avalon stuff later.

Thats going a little far.. the search is clearly there. Its a fairly simple system already developed by the MSN group and in use daily. Avalon is there, the name is now Windows Presentation Foundation.. and .NET will be there too... I think you're under-estimating the changes Vista will bring about. Have you spent anytime watching the videos at Channel9?

I'd try to, but the video player for it would cost me around 300 dollars or so and be a pain in the rear to install.

 

[MrChad]

Originally posted by: hooflung

I think you're under-estimating the changes Vista will bring about. Have you spent anytime watching the videos at Channel9?

I think you need to reword that to "you're under-esimating the changes Vista will bring about to current Window's users."

Nothing they have planned is new. The best thing they brought to the table since windows for workgroups 3.11 is the Registry. Since then the only other notable feature would be their windows media 9 codecs. Other than that... Windows 95/XP just a prettied up, driver supported OS/2 grandchild.

And OS X is just a prettied up, driver supported Xerox Star grandchild!

 

[xtknight]

Don't count on ASM-level optimizations in Vista. It looks like Microsoft is moving closer to managed code at every release. Many of their apps may be .NET, we don't know. Maybe even Explorer (Desktop, taskbar, notification area) will be. Way too much work for little benefit anyway.

Photoshop could start 10 (or 100 or 1000) threads. It's up to the kernel scheduler to split that work (in addition to other processes') across the number of CPUs you have, whether it be 1, 2, or 10. Time slicing will happen when you have more than one thread per CPU with the OS giving more CPU time to the foreground process (or the background process if you have that selected as the preference in the Performance options).

 

[Rilex]

Originally posted by: xtknight
Don't count on ASM-level optimizations in Vista. It looks like Microsoft is moving closer to managed code at every release. Many of their apps may be .NET, we don't know. Maybe even Explorer (Desktop, taskbar, notification area) will be. Way too much work for little benefit anyway.

Managed code is excellent. It will certainly cut down on the number of buffer overflows. ASM provides little to no costerformance benefit on modern computers anyways.