Slashdot Mirror
Next Windows To Get Multicore Redesign
eldavojohn writes "A Microsoft executive announced that the next Windows will be fundamentally redesigned to handle the numerous cores of present and future processors. The article notes that the NT technology underneath Vista has been able to take advantage of multiple processors since 1993, and can now handle 32 or 64 cores. And since Microsoft completely rewrote the 20-year-old GDI/GDI+ model for Vista, what more can (or should) they parallelize? It will be interesting to see how Microsoft tackles the race conditions and deadlocks that come with pervasively multithreaded software and in the past complicated attempts (like that of BeOS) to utilize multiple CPUs. Do you think it's it a smart move to further complicate an operating system to take advantage of multiple cores, or should Microsoft stick to its knitting while applications take advantage of (possibly) more resources?"
im not sure about your computer but on mine with 4 cores. just using MS software only uses 1 core by default. i have to specificly go into the task manager and move processes to another core. which the user shouldnt have to do. which means my $4k computer is only getting to utilize 1 core. also new threads are only started on the processor that the original executable was started on from what i can tell. so if i have an app with 64 threads running and a computer with 64 cores. 63 sit doing nothing. why cant i have 1 thread per processor? looking at the win32 documentation i cant even tell it to create the thread on another processor if 1 exists.
NT has always been a multiprocessor OS.
The big problem with NT is its "Message Passing" architecture, whereby
various components of the OS talk to each other by putting messages on queues
(In the *nux model you just call the function you need.)
The weakness of the architecture is that the component handling any one
message queue is automatically single threaded and tied to a single processor.
Which is OK for 2 or four processor systems but in 16 or 34 processor
systems 12 or 30 of your processors are wasted.
However I expect the idea of any resources being available to the application
is an anathema to Redmond so they will fix this problem to ensure that VISTA
keeps its design goal to consume 90% of available resources.
Old COBOL programmers never die. They just code in C.
Actually I've never seen them on a Linux platform. Zombies are not a problem though. See here for example.
What I've seen that is a problem are processes in "D" state (ininterruptible sleep waiting for the end of an I/O IIRC), usually happening with bad drivers / bad hardware.
But contrary to the windows platform, it never clutters your desktop, as you can "xkill" X ressources even if the program still uses ressources in the background.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
ur pretty dumb lol
It seems that they've already begun to develop services akin to the message passing systems in Erlang and Mozart-Oz. Given that those message passing systems are how those languages avoid the vast bulk of problems described, it seems likely that their attempts to prevent these problems are in fact well underway.
StoneCypher is Full of BS
There's an option: "Launch folder windows in separate processes".
See if you can find it...
No sig today...
"just using MS software only uses 1 core by default" Really depends on which software you're using. A lot of applications like Word, Excel, etc don't usually do process-intensive tasks and the act of spreading the work over multiple threads would actually decrease performance (there is overhead for each thread, context switches, etc). Those apps are more often IO-bound... either waiting for user IO or disk IO. However, if you're using software like SQL Server which performs tasks that do benefit from multiple concurrent threads, it does use multiple cores out of the box. (Yes, it's actually just using multiple threads out of the box, but Windows tosses those to multiple cores... trying not to be too pedantic here) Also if you're manually setting the affinity of processes, you're probably inadvertently decreasing your performance. Windows will spread processing across multiple cores by default (not only using 1 core like you say). When you specifically set the affinity, you're not really moving the process to a different core so much as saying "don't use this core even if it's not being used by anything else." Multi-threading with IO intensive applications should make use of IO completion ports in Windows. That will give you much better perf than trying to manually control which core you explicitly want a thread running on. Keep in mind that IO is orders of magnitude slower than processing, and more often than not that's now the bottleneck in systems. Check out http://www.microsoft.com/technet/sysinternals/info rmation/IoCompletionPorts.mspx/ for more info. Unfortunately, there are a lot of applications out there (both from MS and other vendors) that do multi-threading poorly. Hopefully if MS re-writes some of the Windows infrastructure to make multi-threading easier for applications we'll see better apps that more properly take advantage of the hardware that's out there.
None of this is MS's fault. You have the same problem there always is when upgrading your OS. The only companies more pathetically backwards than scanner/printer companies are "security" companies.
I hear NOD32 has a 64-bit version. NOD32 is also less likely to break your network/OS on a whim than Symantec's shovelware.
I've no idea why you've been modded "Funny". IIRC, NT4 was licensed in exactly this way.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Say what?
"Multicore" is essentially SMP (multiprocessor) but all on one physical chip rather than several. Windows has supported that ever since the days of NT 4, but its architecture is more suited to 2 or 4 cores rather than 16 or 24.
Your comment is only valid for Windows '9x.
>> just using MS software only uses 1 core by default
Depends on the SW - the SW can specify what processor it wishes to run on, although it is rare for applications to do so.
>> i have to specificly go into the task manager and move processes to another core.
That statement is suspect. Generally speaking, applications don't specify the processor on which they run but instead leave it up to Windows to decide.
>> also new threads are only started on the processor that the original executable was started on from what i can tell.
Not correct. The thread will be created on whatever processor is available, and if a processor is not available, the application will be blocked until one is available. This is assuming that the application has not specified a particular processor on which to run.
>> looking at the win32 documentation i cant even tell it to create the thread on another processor if 1 exists.
You can specify what processor the thread runs on after creation:
SetThreadAffinityMask
GetThreadAffinityMask
SetThreadIdealProcessor
To specify what processor is used during thread creation (although why anyone would care about what processor a thread is *created* on seems odd to me):
SetProcessAffinityMask
GetProcessAffinityMask
Note that by default threads are not bound to a particular processor and during a thread's lifetime the thread itself will likely be run on different processors. I suspect that this is leading you to some confusion as how this works.
Apple already had 32-bit and 64-bit PowerPC to support before any of the Intel chips had come out. Now they have four architectures to support instead of three. That being said, they've built Xcode (their IDE that ships with every Mac and is available for free download from their website) with this in mind. By default, all applications you make with it are compiled to run nateively on any of the four architectures with no additional work on your part. I have never once heard of an issue with an application or a piece of hardware only working in 32 or 64 bit mode, and applications that have been compiled since Xcode became Intel aware run perfectly fine on either Intel or PowerPC. The only issue has been older binaries that were compiled solely for PowerPC, and thus must run in emulation on Intel Macs.
Microsoft simply has inferior 64-bit support. On OS X, 32-bit and 64-bit drivers can hapily co-exixt. On Windows, it's one or the other. That means your entire system must migrate to 64-bit at once (including all your peripherals), which is a pretty strong detriment from going 64-bit. I have a 64-bit processor, but neither my network card, my printer, nor my sound card have 64-bit drivers or ever will. No way am I replacing all those components so that I can run 64-bit Windows when 32-bit Windows gets the job done just fine.
Sunwalker Dezco for Warchief in 2016
I think you'd find that there are other areas where Linux is well ahead of Windows, beyond filesystem support and research. The following are just the ones right off the top of my head:
I'm sure there'll be more to add to this list. There are good comparisons around.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
NT ran on Alphas under a compiler called FX!32 which actually took Intel 32 bit code and translated it to 64 bit Alpha code. Basically you could take your standard NT install CD and install it on the Alpha and FX!32 took care of it. It was not till late 1990's that a true 64 bit NT became available for the Alpha but by then Intel came out with their very fast 32 bit cpu's which enabled NT to perform better on the Intel platform than on the lower clock speed Alphas so 64 bit NT was shelved. Not much later Compaq took over DEC which was the beginning of the end for the Alpha so most of the chip designers went to Intel or AMD.
If you have MS Windows Vista Ultimate you have 64 bit but the others from what I can gather are still 32 bit This means that for many laptops which are now predominately dual core 64 bit, you are running a 32 bit OS. Sort of like the old Alpha days except 64 bit Intel/AMD chips can run native 32 Wintel code.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
Uhh.. come up with a new story and read other technical sites besides Slashdot. Windows Vista has a helluva lot of new features in the OS besides the GUI. Some examples that come to mind.
- Prioritization of I/O not just CPU usage in tasks.
- Love it or hate it the UAC.
- ReadyBoost
- Memory for certain processes is randomized to prevent direct access by malware.
There are many more, but thats just off the top of my head. I guess you could argue that a couple of my bullet points fall under security model, but hey at least I went into more detail. Now go off and use Google to find something interesting to post.JOhn
Campaign for Liberty
No one, because it's Glenda, the Plan 9 Bunny. And it's an official attribution.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
You are confused. There was a native version of NT 4.0 (not sure about 3.5) for Alpha. Digital released a third party utility called FX!32 that allowed x86 applications to run on the Alpha version of NT (otherwise you'd need the alpha binaries).