Linked by Thom Holwerda on Tue 26th Sep 2006 23:14 UTC
Intel Quad-core processors are only the beginning of what a revitalized Intel has to offer, the company's top executives said here Sept. 26. The chip maker will deliver in November its first quad-core processors - chips that incorporate four processors each - for both desktops and servers, said CEO Paul Otellini here, in an opening keynote speech at the Intel Developer Forum. The quad-core chips themselves will offer up to 70 percent greater performance in desktops and 50 percent in servers.
Thread beginning with comment 165988
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: The beginning of what?
by bogomipz on Wed 27th Sep 2006 07:51 UTC in reply to "The beginning of what?"
bogomipz
Member since:
2005-07-11

Not if you're running BeOS ;)

As shown 07:50 minutes into this demo:
http://video.google.co.uk/videoplay?docid=1659841654840942756

Reply Parent Score: 0

RE[2]: The beginning of what?
by Kitty on Wed 27th Sep 2006 10:20 in reply to "RE: The beginning of what?"
Kitty Member since:
2005-10-01

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.

Reply Parent Score: 1

RE[3]: The beginning of what?
by bogomipz on Wed 27th Sep 2006 11:58 in reply to "RE[2]: The beginning of what?"
bogomipz Member since:
2005-07-11

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.

Reply Parent Score: 1

RE[3]: The beginning of what?
by phoudoin on Thu 28th Sep 2006 08:31 in reply to "RE[2]: The beginning of what?"
phoudoin Member since:
2006-06-09

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.

Reply Parent Score: 1