If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
In article XQbZc.44$A63.6@trnddc09, Raymond wrote:
Oh, really? I did a quick Web search, but couldn't find when the comparable announcement was made for 90 nm. I vaguely remember mid-2001, which was a little matter of 3 years before 90 nm hit the streets in quantity. If you read exactly what Intel said after they achieved 90nm SRAM, they weren't anywhere as rosy as they are now with 65nm. I need to correct what I said - it was 2 years. March 2002. Actually, I remember them being every bit as optimistic. Anyway, such claims are worth almost as much as the hot air that carries them. I shall not be holding my breath for 65 nm; you are welcome to hold yours for it :-) I am holding my breath! :-) You have better lungs than I do :-) Regards, Nick Maclaren. |
#22
|
|||
|
|||
In article XQbZc.45$A63.43@trnddc09, Raymond wrote:
"Nick Maclaren" wrote in message ... In article , Alex Johnson writes: | | I thought 2005 was too soon for 65nm, but that's what I read. That | Pentium 4 will be shipping in 2005 on 65nm. Which, thankfully, gives | that embarrassment that is Prescott just one year of life. If you believe that ordinary customers will be able to buy 65 nm Pentium 4s at commodity prices in mid-2005, I have this bridge for sale .... What they're saying is first production in 2005, and high volume by 2006, perhaps even high enough to overtake that of 90nm. Even if that were so, it would give Prescott a lot more than a year to hold the fort. Anyway, once upon a time when knights were bold and press statements were intended to convey information, "production" meant the delivery of products, and "products" meant goods sold to ordinary customers. At least in this context. Yes, I believe that Intel (and IBM) will be able to make 65 nm CPUs in early 2005, perhaps even late 2004. But small numbers of ones made for testing does not constitute production in any meaningful sense. Regards, Nick Maclaren. |
#23
|
|||
|
|||
I am pretty sure that Intel could cool the chip, even at that speed.
A factory-fitted silver heatsink, with high-speed water-cooling to a heat exchanger in front of a large and fast fan, bolted into a heavy chassis, should do the job. A heat pipe is better at moving heat than any solid material, and quite easy to use. Dumping all those watts in the environment, absent water cooling, is more of a problem. I'd rather not have several hundred watts heating the air in my office, thank you. Jan |
#24
|
|||
|
|||
In article ,
G wrote: Also, I suspect your comments about languages are true when it comes to C/C++. But the newer languages like Java, C# and VB.Net make working with threads MUCH easier. I'm not exactly sure what MS could "incorporate in their next Studio" that could possibly make it any easier to write multi-threaded managed code. And with alot more of Longhorn written itself as managed code, inculding the new Avalon/XAML UI stuff, I suspect that even traditional message driven GUI code will make better use of multiple cores. Of course the cynics will claim that amounts to Windows yet again sucking all possible power out of even the latest & greatest hardware, but I guess that's inevitable. I am afraid not. I haven't looked at them in detail, but a quick glance indicates that they give the appearance of making the design and coding of threaded applications easier, while not tackling the most important problems. But your last remark is correct. It isn't hard to separate GUIs into multiple components, separated by message passing (whether using thread primitives or not), and those are a doddle to schedule on multi-core systems. And that is the way that things are going. Regards, Nick Maclaren. |
#25
|
|||
|
|||
In article ,
=?ISO-8859-1?Q?Jan_Vorbr=FCggen?= wrote: I am pretty sure that Intel could cool the chip, even at that speed. A factory-fitted silver heatsink, with high-speed water-cooling to a heat exchanger in front of a large and fast fan, bolted into a heavy chassis, should do the job. A heat pipe is better at moving heat than any solid material, and quite easy to use. Hang on - I never said that the silver heatsink was solid! It should be silver for the conductivity and resistance to corrosion, but I was assuming circulating water inside it. Sorry about omitting that critical point :-( Dumping all those watts in the environment, absent water cooling, is more of a problem. I'd rather not have several hundred watts heating the air in my office, thank you. Or 1,000 of them dumping heat in my machine room .... Regards, Nick Maclaren. |
#26
|
|||
|
|||
G wrote:
Every version of Windows based on NT (NT, 2000, XP, Server 2k3, Longhorn, etc) has gotten progressively better at utilizing multiple CPU's. MS keeps tweaking things to a finer level of granularity. So minimally, a single threaded application could still hog 1 CPU, but at least the OS underneath will do it's best to make use of the other CPU. A data point. I'm doing nothing much except reading this group and yet the XP performance monitor shows a queue of 7 or 8 threads ready to run. I think applications like WORD and Excel already do things like spell- checking and recalculation in worker threads. I don't find it hard to believe that a typical Windows box would benefit from 4+ "processors". |
#27
|
|||
|
|||
Nick Maclaren wrote: But your last remark is correct. It isn't hard to separate GUIs into multiple components, separated by message passing (whether using thread primitives or not), and those are a doddle to schedule on multi-core systems. And that is the way that things are going. I'm not sure that the gui by itself is enough to justify a multi-core cpu. And there are problems enough in multi-threaded gui, even apart from deadlocks caused by inexperienced programmer mixing threads and OO callbacks. Consider mouse events queued before but received after a resize operation. The mouse coordinates are in the wrong frame of reference and all wrong. Gui designers design as if the event queue was = 1 at all times. What would more likely to utilize concurrency would be the database like Longhorm filesystem that MS is supposed to be doing. Except that I don't think MS has the expertise to do lock-free concurrent programming like that. If they have, they've been keeping a low profile. Joe Seigh |
#28
|
|||
|
|||
In article , Joe Seigh writes: | | I'm not sure that the gui by itself is enough to justify a multi-core | cpu. And there are problems enough in multi-threaded gui, even apart | from deadlocks caused by inexperienced programmer mixing threads and OO | callbacks. Consider mouse events queued before but received after a | resize operation. The mouse coordinates are in the wrong frame of reference | and all wrong. Gui designers design as if the event queue was = 1 at all | times. Take a mouse event in an unrealistically simple design. This is picked up by the kernel, and passed to the display manager, which converts it into another form and passes it to the application. That does something with it, passes a message to the display manager, which calls the kernel to update the screen. The user does not see any effect until that has completed. At best, you have 4 context switches, 2 of which are between user-level contexts, and it is common for there to be MANY more. Now, consider that being done as part of drag-and-drop - you want the process to happen in under 2 milliseconds (certainly under 5), or it will start to be visible. That can be 1,000+ context switches a second, and some of those contexts have large working sets, so you are reloading a lot of cache and TLBs. One of the advantages of a multi-core system is that you don't need to switch context just to pass a message if the threads or processes are on different cores. You just pass the message. Regards, Nick Maclaren. |
#30
|
|||
|
|||
I think applications like WORD and Excel already do things like spell-
checking and recalculation in worker threads. I don't find it hard to I also see a lot of background processes from GUI thingies on my Mac. This sucks because it happens even for application that are currently "idle". E.g. there are two other people "logged in" but currently inactive, but they use up a lot of resident pages, thus making me page a lot more. I suspect that with 10 users logged in at the same time and only 768MB of RAM, the machine would be brought to its knees :-( Stefan |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
GA-8IDML and Mobile CPU compatibility | Cuzman | Gigabyte Motherboards | 0 | December 8th 04 01:29 PM |
Intel chipsets are the most stable? | rstlne | Overclocking AMD Processors | 105 | October 26th 04 02:53 AM |
Intel vs. AMD: Best bang for buck, at the moment | Dave C. | Homebuilt PC's | 40 | September 27th 04 07:19 AM |
Best bang for buck CPU? | Shawk | Homebuilt PC's | 9 | October 5th 03 07:24 PM |
Intel wants to slow down platform changes | Rob Stow | General | 6 | July 5th 03 11:13 AM |