http://www.osnews.com/story/15983/Intel_Quad-Core_Is_Just_the_Beginning Exploring the Future of Computing en-us Copyright 2001-2013, David Adams adam+nospam@osnews.com Thu, 23 May 2013 01:03:24 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://www.osnews.com/thread?165865 http://www.osnews.com/thread?165865 Intel and Apple: Pushing the Envelope. Tue, 26 Sep 2006 23:34:00 GMT donotreply@osnews.com (Matt24) Comments http://www.osnews.com/thread?165878 http://www.osnews.com/thread?165878 Intel may have a great cpu but it's shared bus architecture really falls behind AMD's Hypertransport.

On servers this will hit bad, because something like GbE nics or a couple of fast SATA HDDs will choke the BUS. Tue, 26 Sep 2006 23:56:00 GMT donotreply@osnews.com (jcinacio) Comments http://www.osnews.com/thread?165885 http://www.osnews.com/thread?165885 I'm assuming the quad-core 2 CPUs are going to become intel's flag ship high performance processors and downgrade the high price core 2 duo processors to the mainsteam market and make the pentium D, entry level,low budget CPU, until they release the pentium E next year.Edited 2006-09-27 00:06 Wed, 27 Sep 2006 00:04:00 GMT donotreply@osnews.com (happycamper) Comments http://www.osnews.com/thread?165906 http://www.osnews.com/thread?165906 Sources? I'd like to read up on that. Wed, 27 Sep 2006 00:57:00 GMT donotreply@osnews.com (DittoBox) Comments http://www.osnews.com/thread?165921 http://www.osnews.com/thread?165921 Be optimized for it, a lot of games as it is dont support SMP/Duel core/SLI as it is. Wed, 27 Sep 2006 01:43:00 GMT donotreply@osnews.com (SlackerJack) Comments http://www.osnews.com/thread?165931 http://www.osnews.com/thread?165931 Do a search about Intel's next generation bus, called CSI, which is a lot like HyperTransport. That'll basically tell you why the old FSB architecture sucks. Wed, 27 Sep 2006 02:20:00 GMT donotreply@osnews.com (smitty) Comments http://www.osnews.com/thread?165944 http://www.osnews.com/thread?165944 70% greater than what? Wed, 27 Sep 2006 03:11:00 GMT donotreply@osnews.com (setuid_w00t) Comments http://www.osnews.com/thread?165965 http://www.osnews.com/thread?165965 than the marketing figures mention last year probably Wed, 27 Sep 2006 05:13:00 GMT donotreply@osnews.com (Matzon) Comments http://www.osnews.com/thread?165969 http://www.osnews.com/thread?165969 8 cores, 16 cores, 32 cores ... It's nice so hear marketing bla from Intel. As long as only a few applications really support that it's utterly useless. Wed, 27 Sep 2006 05:48:00 GMT donotreply@osnews.com (deb2006) Comments http://www.osnews.com/thread?165988 http://www.osnews.com/thread?165988 Not if you're running BeOS

As shown 07:50 minutes into this demo:
http://video.google.co.uk/videoplay?docid=1659841654840942756 Wed, 27 Sep 2006 07:51:00 GMT donotreply@osnews.com (bogomipz) Comments http://www.osnews.com/thread?165989 http://www.osnews.com/thread?165989 That's inaccurate. Many applications are threaded today. Even my toy editor runs more than 15 threads. And even if applications aren't, the kernel can schedule processes to run on different cores. The question is not whether applications are ready, but rather whether kernels can take advantage of multiple cores. Today, most modern kernels can. Wed, 27 Sep 2006 07:51:00 GMT donotreply@osnews.com (Mystilleef) Comments http://www.osnews.com/thread?165998 http://www.osnews.com/thread?165998 Pentium E ?!?!?! Wed, 27 Sep 2006 08:20:00 GMT donotreply@osnews.com (traderjb) Comments http://www.osnews.com/thread?166027 http://www.osnews.com/thread?166027 I'm far from an expert on SMP, but I don't think I've seen anything in that old video that can't be done with any SMP-ready kernel out there.
Honest question stemming from my ignorance: how come every time SMP is discussed, BeOS is brought up as a silver bullet? I seem to understand that its own GUI/window manager was heavily threaded, and that its API encouraged multithreaded development in frontends.
But regarding the CPU intensive parts of a program not written in any OS-specific special manner (let's say the Gecko renderer, or the filters in GIMP) is there anything that BeOS does that is more SMP-friendly than other OSes? I don't know, migrating processes from one core the other to keep the load balanced or more esoteric stuff?
Thanks to anyone that takes the time to satisfy my curiosity. Wed, 27 Sep 2006 10:20:00 GMT donotreply@osnews.com (Kitty) Comments http://www.osnews.com/thread?166030 http://www.osnews.com/thread?166030 I'm really tired hearing this constant "but there are 500 threads running on my PC !" bs - almost all of them are just waiting, eating no CPU time. Wed, 27 Sep 2006 10:30:00 GMT donotreply@osnews.com (ondrej) Comments http://www.osnews.com/thread?166034 http://www.osnews.com/thread?166034 The beginning of what?

:) Well, the beginning of the next marketing campaign, the beginning of the rest of Intel's days, whatever

For you, for us, we'll believe when we see, so it's a nothing-here-move-along effect.

70% more than whatever sounds nice, still, e.g. saying these chips will deliver 70% more performance than let's say core2s sounds a bit, well, worthy of some doubt. Wed, 27 Sep 2006 11:00:00 GMT donotreply@osnews.com (l3v1) Comments http://www.osnews.com/thread?166035 http://www.osnews.com/thread?166035 You win something with X cores if you run at least X-1 heavy applications, so your system will still be responsive. But in today use, for most users 1 core was sufficient, for geek, dual core was useful (ripping a dvd while playing a game) and for anybody that need a very responsive system. But now, 4, and more then, for not specific usage, it's a waste of CPU and nothing else. It will be useful for servers.

(This comment consider that most applications are not efficiently threaded)Edited 2006-09-27 11:03 Wed, 27 Sep 2006 11:02:00 GMT donotreply@osnews.com (kevinlb) Comments http://www.osnews.com/thread?166042 http://www.osnews.com/thread?166042 i agree. i think dual cores is a pretty great thing even for standard desktops as it can make your system much more responsive when multitasking. however with 4 cores (and fast cores at that) in today's desktops i think there is going to be a lot of people firing up their multithreaded hd video encoder and wondering why each core is only running at 60% load. they will be hitting other bottlenecks, the bus will become saturated with disk io traffic and memory accesses. i'm sure someone can crunch the numbers and get a rough estimation of the impact of this phenomenon.

the new CSI bus from intel is supposed to be their answer to this problem but it doesn't appear to be anywhere near desktops yet. its slated to first be available for xeons and itaniums sometime in 2007. Wed, 27 Sep 2006 11:48:00 GMT donotreply@osnews.com (borat) Comments http://www.osnews.com/thread?166046 http://www.osnews.com/thread?166046 Hello Kitty

The Be API not only encourages multithreaded code, it automatically makes each window run in its own thread. This means that any program that opens a window is multithreaded. Of course this doesn't help much if all the work of the application happens in the thread of its only window, but I believe apps on BeOS generally use these threads for user interaction only. This is in contrast to say Windows where I'm sure you have experienced menus and other GUI components hang when the app has alot of work to do.

In addition to that, the application in the linked video has two threads that only do rendering. This is application specific code and is possible on any modern OS, but I guess the BMessage centric API makes it easier to achieve. Someone with actual experience beyond reading a book on BeOS programming might be able to elaborate. Wed, 27 Sep 2006 11:58:00 GMT donotreply@osnews.com (bogomipz) Comments http://www.osnews.com/thread?166062 http://www.osnews.com/thread?166062 These systems are for pro's and enthusiasts. I may not always be utilizing the full power of my system, but when I do, I'm glad I have it.

Here's an example, lets say that for one of my clients I have to process 5 large datasets, encrypt the output and take a hash of the encrypted output. The script below would simulate this excersise:

In bash (on one line):
t1=`date +%s`; r=0; while [ $r -le 4 ]; do openssl rand 1234567890 -base64 | openssl enc -bf -k guess | openssl sha1 > /dev/null & r=$((r+1)); done; wait; t2=`date +%s`; t3=$((t2-t1)); echo $t3

On my MacPro here are the results:
4 cpu's = 139 seconds
2 cpu's = 269 seconds
1 cpu = 550 seconds

While this work is occuring, it is nice to be able to still use the system for e-mail, writing documentation, web research, listening to some tunes, etc...

BertEdited 2006-09-27 13:33 Wed, 27 Sep 2006 13:18:00 GMT donotreply@osnews.com (anonymous-bert) Comments http://www.osnews.com/thread?166066 http://www.osnews.com/thread?166066 >> Be optimized for it, a lot of games as it is dont support SMP/Duel core/SLI as it is.

Ofcourse Be optimized BeOS for it. BeOS and Haiku loves multiple CPUs, the more the better.

Sorry guys, I just could not resist. Wed, 27 Sep 2006 13:23:00 GMT donotreply@osnews.com (Earl Colby pottinger) Comments http://www.osnews.com/thread?166090 http://www.osnews.com/thread?166090 bogomipz has the answer pretty well nailed. The multi-threaded nature of the windows makes porting apps from "traditional" architectures a pain, but makes your UI feel responsive even when the app is pegging the CPU. The window's threads are also higher priority than most apps, which helps some too.

I just finished multi-threading a linux app and I really missed the BeOS threading API... :-D Wed, 27 Sep 2006 14:39:00 GMT donotreply@osnews.com (mphipps) Comments http://www.osnews.com/thread?166148 http://www.osnews.com/thread?166148 however with 4 cores (and fast cores at that) in today's desktops i think there is going to be a lot of people firing up their multithreaded hd video encoder and wondering why each core is only running at 60% load.

"Test results with the software packages Main Concept with H.264 encoding and the WMV-HD conversion make this very clear. We noticed performance jumps of up to 80% when compared to the Core 2 Duo at the same clock speed (2.66 GHz)."

http://www.tomshardware.com/2006/09/10/four_cores_on_the_rampage/pa...

they will be hitting other bottlenecks, the bus will become saturated with disk io traffic and memory accesses. i'm sure someone can crunch the numbers and get a rough estimation of the impact of this phenomenon.

"Our test results reveal that a FSB1333 (true 333 MHz) does not entail advantages - at least not based on the tests at a CPU clock speed of 2.66 GHz. At CPU clock speeds of 3.0 GHz and above, and memory speeds beyond the DDR2-1000 mark (true 500 MHz), the FSB1333 shows what it is capable of.

One should not forget - viewed from the perspective of the Pentium 4 - that the Core 2 micro-architecture offers a few features to ease the strain on memory access, whereby higher FSB or memory speeds barely register any speed advantages."

http://www.tomshardware.com/2006/09/10/four_cores_on_the_rampage/pa... Wed, 27 Sep 2006 16:59:00 GMT donotreply@osnews.com (stare) Comments http://www.osnews.com/thread?166222 http://www.osnews.com/thread?166222 I don't see your point. The same can be said of almost all applications (processes) running on your PC. How's that relevant to the issue at hand. Wed, 27 Sep 2006 21:33:00 GMT donotreply@osnews.com (Mystilleef) Comments http://www.osnews.com/thread?166224 http://www.osnews.com/thread?166224 Problem is you are assuming large data flows to each CPU, there are programs that the more CPUs you have the less data needed to be sent to per CPU.

Example: The other day I wanted to resize a collecting of pictures I have (using TAR on BeOS). A quick rough resize is done as fast as I move the mouse, but the smooth-resize takes a few seconds per picture. There is no reason that the picture could not be broken up in 80 or more overlapping pieces and each piece sent to a separate CPU for processing. When you look at the amount of data moved into the CPUs, there is not that much, most of the pictures were less that a meg in size.

Note: following the numbers are just examples not real wold measurements.

If a modern single CPU processes a picture a second, we have to move 2 MBytes/sec on the buss. If we have 80 CPUs of the same power, we have to move 160 MBytes/sec to keep up. This is not even close to what a modern buss can do. For image processing the code for any one function is relatively very small, it will run out of the local cache.

I don't mean to say the above are the true real world figures but I do know in the graphic and photo that doing a lot of simple functions in parallel on a chunk of data makes a lot of sense.

And there are a lot of graphic and photo people out there. Wed, 27 Sep 2006 21:37:00 GMT donotreply@osnews.com (Earl Colby pottinger) Comments http://www.osnews.com/thread?166232 http://www.osnews.com/thread?166232 Pentium E ?!?!?!


http://www.tgdaily.com/2006/09/20/conroe_single_core/ Wed, 27 Sep 2006 22:06:00 GMT donotreply@osnews.com (happycamper) Comments http://www.osnews.com/thread?166336 http://www.osnews.com/thread?166336 I seem to understand that its own GUI/window manager was heavily threaded, and that its API encouraged multithreaded development in frontends.
But regarding the CPU intensive parts of a program not written in any OS-specific special manner (let's say the Gecko renderer, or the filters in GIMP) is there anything that BeOS does that is more SMP-friendly than other OSes?

Not only BeOS's window manager was heavily threaded, but pretty much everything in BeOS is, from top to bottom. In 1990's, it was not that common. For example, all drivers and kernel modules, file systems included, must be SMP-aware (no giant lock) and many of them even use extra threads to achieve better/smoother asynchronous I/O handling.
Kernel is fully thread-safe and use also threads itself. The BONE network stack use threading everywhere.

And, indeed, all userland servers and their corresponding libraries (BeOS "kits", aka C++ API) are threaded. BeOS kits not only encouraged multithreaded development but in the case of GUI, its enforced on the developer.

Which, in 1990's, unfortunatly, didn't help this IMHO great operating system to get quickly the critical mass of graphical software ported from unix or windows code base. At this time, before SMP became mainstream, multithreaded development and parallel software programming was not that well mastered by developers. Since, things have improved. Alas, Be Inc. was too early too small to survive during these years.

Beside this pervasive threading model, BeOS have no other "exotic" SMP features. Thu, 28 Sep 2006 08:31:00 GMT donotreply@osnews.com (phoudoin) Comments