LWN.net Logo

Linus Torvalds talks future of Linux (apc)

apc features an interview with Linus Torvalds. "APC: Out of curiosity, do you have anything to say to hardware manufacturers who refuse to release datasheets or specifications about the functioning of their hardware so it could operate with the Linux kernel? LT: Is "I hope you all die a painful death" too strong? The good news is that a lot of hw manufacturers are actually doing the right thing. Intel in particular has improved wrt open source a lot, and for that reason I tend to suggest that when buying a machine, just make sure that you buy one with Intel graphics and wireless. That takes care of the two biggest annoyances right there. But Intel certainly isn't the only one, and we're doing fairly well in general - with just a few dark spots."
(Log in to post comments)

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 18:19 UTC (Thu) by jengelh (subscriber, #33263) [Link]

But, do the bigger Intel graphic chips reach the same performance numbers as Nvidia, or is the maximum offer something like ATI Rage XL/Mobility Radeon?

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 21:03 UTC (Thu) by fergal (subscriber, #602) [Link]

I don't think they do but a large number (the majority?) of machines don't need something that can play HALO at 120FPS.

I just went through a reasonable amount of pain because the IGP9100 chipset on my PVR box is no longer supported by ATI. I ended up switching to VESA drivers for X and as far as I can tell, it now uses less CPU for movie playback than with the official ATI drivers.

When I bought the box I don't think there were any open graphics chips but next time, I'll do my best to find one, to avoid hassle in the future and also to vote with my wallet.

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 23:32 UTC (Thu) by dmarti (subscriber, #11625) [Link]

I talked with Matt Domsch at Dell about how the company selects hardware now. They do consider the availability of a kernel.org in-tree GPL driver -- even when selecting parts for a laptop that they're planning to sell with a Microsoft OS.

The interesting thing about the Intel hardware is that if you looked at Dell's site a year or so ago, the bottom configuration of a given laptop would have Intel and the top two would require "evil baby-mulching drivers" (as Jon Masters would say). On the latest machine, only the top is EBMD and the rest are Intel.

Yes, Intel is doing to Nvidia and ATI in the PC video market what they did to Creative Labs and 3Com in the PC sound and network markets. Bwah ha ha.

Linus Torvalds talks future of Linux (apc)

Posted Aug 24, 2007 9:43 UTC (Fri) by dion (subscriber, #2764) [Link]

I so wish you are right about what Intel is doing to ATI and nVidia, but I also feel a little scared that they might now keep being as open as they are now if they end up "owning" the PC completely.

Linus Torvalds talks future of Linux (apc)

Posted Aug 24, 2007 12:12 UTC (Fri) by drag (subscriber, #31333) [Link]

Well Intel does, currently, sell more video cards then AMD and Nvidia combined. So maybe that can help you envision a Intel-only world.

Intel is not our friends, they are corporation and just as greedy. They are just smarter then AMD/ATI and Nvidia and realise that supporting Linux properly is going to help their bottom line. In time Nvidia and AMD will figure this out, I think that AMD probably already knows this but they are mired up their eyeballs in ATI's historical 'Intellectual Property' moronicness. However I don't want it to be a Intel-only world anymore then I want it to be a Broadcom-only world.

As it goes probably both AMD and NVidia are stuck on mistakes from their past involving things like cross-licensing patents, licensing proprietary software from other companies, agreements with Microsoft, DRM-like features , etc etc. They are probably so screwed into the whole deal that they couldn't release open drivers if they wanted to.

As far as performance goes....

Intel IGP chipsets have the edge on Nvidia/AMD products in terms of price, battery life, stability, and compatability. I would not considure buying anything else for a laptop.

Modern Intel drivers for Linux currently lack the mpeg-acceleration XvMC features that makes the hardware perform well on HD-sized video and 3D performance is best described as 'mostly adequate'. It'll play HD stuff if you have a fast enough cpu, no problem. And it will play Quake3-era games and most open source games, no problem. Compiz support is great.

For anything requiring high performance graphics then the only answer is Nvidia video cards, unfortunately.

The principal advantage of Intel IGP is their openness. It has replaced the ATI r200 video cards as the favored choice for X.org developers and Intel has hired several big names from X.org-land to work on their graphics. Such as Keith Packard, principal orginizer behind the X.org-XFree86 fork, creator of the Kdrive drivers, xdamage/composition extensions, xrender, etc. etc.

This should help things like:
http://zrusin.blogspot.com/2007/05/mesa-and-llvm.html
A effort on getting better compiler support for GPUs. I wonder how it's going...

When Mesa 7.xx begins hitting Linux distros then you should see a moderate performance boost coming from the Intel camp.

Newer Mesa stuff provides for things like OpenGL 2.1 compatability, properly texture memory management (big deal, especially for shared memory cards like Intel), shader language support, GLSL compiler support, vertex acceleration, and other such things. These improvements should help especially the Intel GMA X3000 and GMA X3100 video cards (what you'd find in newer centrino laptops like the Dell 1420n or the System76 Darter Ultra).

With these improvements and the newer GMA stuff should bring Intel IGP on par with low-to-mid range discrete graphics products coming out of AMD or Nvidia. I don't know this for a fact.

Also another thing I don't know for a fact, but with the Intel Larrebee we should start seeing descrete graphics coming out from Intel in the next couple years.
http://en.wikipedia.org/wiki/Larrabee_(GPU)

snippets from wikipedia:
> Larrabee is different from its predecessors in that it uses a derivative of the x86 instruction set for its shader cores instead of a custom graphics-oriented instruction set, and is expected to be more flexible.

> According to a presentation made by Intel in December 2006, Larrabee will run at 1.7-2.5 GHz and feature 16-24 in-order cores (as opposed to out-of-order) running a modified x86 instruction set, in addition to texure sampling units and other hardware typical of graphics processors.

16-core GPU proccessor that is easily accessable from the OS for other then just 3D tasks sounds good to me.

Linus Torvalds talks future of Linux (apc)

Posted Aug 24, 2007 12:42 UTC (Fri) by drag (subscriber, #31333) [Link]

A fairly good article
http://arstechnica.com/news.ars/post/20070604-clearing-up...

With Nvidia/AMD/Intel the general trend seems to go towards including these GPUs on the CPU die and making them more general purpose.

Intel seems to be taking the angle of extending x86 (similar to mmx) and making it include GPU-like features were Nvidia/AMD seem to be aiming at making their GPUs more general purpose.

And they are all also aiming for the HPC market.
All in all it's very similar to IBM's Cell stuff, but each are doing it in their own special ways. Nvidia is taking the GPU approach vs IBM's custom highly-risc 'vector' cpu cores.

The scary thing about AMD/ATI and Nvidia is that instead of openning up their hardware for programmers that they are hiding their interfaces behind proprietary software libraries and development environments.

Nvidia has their CUDA environment for C-for-GPUs and AMD has their CTM.
http://developer.nvidia.com/object/cuda.html
http://ati.amd.com/products/streamprocessor/specs.html

Intel wants to have x86-like, AMD and Nvidia seem to want to use slick and easy-to-use interfaces to abstract away their rapidly-changing GPUs. Something like that. I don't know.

If this trend continues then to be able to even access the all the CPU cores on future systems could be very problematic for Linux. What can you do if your cpu requires proprietary drivers?

I don't understand all of this, I am realy no low-level programmer, but I think it's definately something worth keeping my eye on.

Dell chooses free drivers

Posted Aug 24, 2007 16:19 UTC (Fri) by man_ls (subscriber, #15091) [Link]

Wow, that is excellent news. I hope people from AMD, Broadcom and other parts vendors are listening. And I hope HP, Lenovo and other OEMs follow suit.

Linus Torvalds talks future of Linux (apc)

Posted Aug 24, 2007 9:47 UTC (Fri) by tajyrink (subscriber, #2750) [Link]

ATI Rage XL is almost a decade old, and Mobility Radeon doesn't mean much unless you mean specifically the first one of those (M6?).

Anyway, I'd say GMA X3000 is ca. Radeon 9600 performance-wise, but feature-wise more like X800 or even X1800 (quite modern shaders supported) and also the shader performance is way faster than the ordinary fixed pipeline performance. Maybe this is not accurate comparison, but at least a lot closer than RageXL.

The Linux drivers at freedesktop.org seem to have 965-glsl branch, hopefully it'll be merged to Mesa HEAD soon so that the shaders are available on Linux, too.

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 18:55 UTC (Thu) by sab39 (guest, #2185) [Link]

Another relevant question is whether Intel actually make - or plan to make - standalone graphics cards at all. If you're planning to buy new hardware for an existing computer, motherboard-embedded solutions aren't as appealing.

(I only did the most cursory research on this as upgrading the computer in question is still a way in the future, but the answer seems to be "no, embedded only")

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 22:00 UTC (Thu) by beoba (guest, #16942) [Link]

Another question is whether standalone graphics is the way things are ultimately headed. Using AMD and Intel as a barometer, I'd say the forecast is for embedded graphics.

Linus Torvalds talks future of Linux (apc)

Posted Aug 24, 2007 6:01 UTC (Fri) by jwb (subscriber, #15467) [Link]

Whole Intel motherboards are comparable in price to or cheaper than Nvidia video cards. You can get a board with graphics for $60.

Linus Torvalds talks future of Linux (apc)

Posted Aug 24, 2007 14:30 UTC (Fri) by drag (subscriber, #31333) [Link]

look up 'Intel Larrabee' and you'll see Intel's future GPU moves. Hopefully in a couple years we will see discrete Intel graphics and the corrisponding performance improvement of having dedicated video card memory with a 16/24 core GPU.
http://arstechnica.com/articles/paedia/hardware/clearing-...
http://arstechnica.com/news.ars/post/20070604-clearing-up...

On the long-term it seems that the GPU will be integrated onto the CPU die as a speciality core for graphics and floating point performance.

Pretty soon you'll start seeing 8 or 16-way proccessors. I figure for Desktop use you pretty much lose any sort of multitasking benifits once you get over 4 or so cores. I figure that you will see very limited performance benifit from having 16 core vs 4 core cpus. So it makes sense that instead of sticking with general purpose cores you will start to see more and more specialized cores being introduced.. stuff optimized for specific workloads.

Instead of spending the money on special RAM for your video card, you simply have the fastest ram possible for your cpu with the on-die memory controller. Then from CPU to GPU you don't have to deal with any latencies or bandwidth limitations inherent with having to go through the motherboard. Also for mobile applications you can disable and enable cores on the fly for better battery management.

The dangerous part is that currently for High Performance GPU Computing from AMD/ATI and Nvidia is that the only way to access their GPUs for computing is through software interfaces, CUDA for Nvidia, and CTM for ATI. The idea is that they get to keep their hardware secret, they can change the GPU and then modify the software to keep older applications compatable, and users have a easy-to-program interface to deal with. The downsides, of course, is that all of this is proprietary software.

I don't know if that trend will continue to the consumer space, but it wouldn't be good if it did.

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 20:15 UTC (Thu) by hitmark (guest, #34609) [Link]

the bit i find interesting is that linus thinks only ARM has the chance to unseat X86 as the de-facto standard CPU...

Linus Torvalds talks future of Linux (apc)

Posted Aug 23, 2007 20:29 UTC (Thu) by wa1hco (subscriber, #3628) [Link]

ARM may have so much volume related to the embedded market that it grabs all the mind share from developers...and thus becomes the core platform for developers.

Linus Torvalds talks future of Linux (apc)

Posted Aug 30, 2007 18:42 UTC (Thu) by lysse (subscriber, #3190) [Link]

On the subject of ARMs, does anyone know of any manufacturer who packages any of their ARM-based microcontrollers in DIPs? Hobbyists are still left a bit out in the cold otherwise - and when the choice for a breadboard fan is between paying $40 for an LPC-on-a-DIP, and asking Microchip to send you a couple of samples of the dsPIC30F4013 and dsPIC33FJ12GP202 for free... well, the ARM7 is nice, but not THAT nice. :)

future CPUs

Posted Aug 23, 2007 22:18 UTC (Thu) by ncm (subscriber, #165) [Link]

What might finally do in x86 is that it guarantees a simple memory model: the memory controller is very restricted in what order cache spills to memory may occur, and when those writes must be visible to code running on other cores. This is very nice for programmers, but it means that with 8 or more cores on a die, x86 performance will tank. The freedom to decouple caches that comes with some other CPU architecture spec might be enough to displace x86, despite that it makes correct multi-thread programming harder. Expect to see thread programming methods that hide these details (e.g. MPI and futures) heavily promoted.

Curiously, the Java threading memory model is similarly restrictive, and therefore is unimplementable on modern CPUs. "Modern" in this context includes PPC and Itanium, but not MIPS. I don't know about ARM; NUMA ARM systems are not common.

Will the 16- and 32-core chips be populated with ARMs? PPC seems more likely.

future CPUs

Posted Aug 24, 2007 0:00 UTC (Fri) by landley (subscriber, #6789) [Link]

Death of x86 predicted, film at 11. :)

Sorry, not holding my breath. Until we've got software that can benefit
from even 8 cores, who cares? SMP scalability was a huge advantage of
Sparc and Solaris, and they've just taken the market by storm, haven't
they?

As far as I can tell, Intel is going to SMP on a chip because they can't
figure out a better use for the enormous transitor budgets each die shrink
gives 'em (they've already got megabytes of on-chip L2 cache), not because
there's a huge demand to throw yet more mips at general desktop tasks
(word processing, email, web browsing, quicken, turbotax, the occasional
spreadsheet containing a grocery list...).

How is your average laptop going to keep these cores busy? Go back to
software rendering for 3D acceleration? (The ubiquity of existing 3D
coprocessors aside, isn't that about as much a question of memory bus
bandwidth as processor performance, so putting the graphics processor
physically close to the graphics frame buffer actually makes sense
architecturally? And this helps battery life how?)

future CPUs

Posted Aug 24, 2007 6:05 UTC (Fri) by Cato (subscriber, #7643) [Link]

The average Windows PC needs at least one core for 'admin' - running antivirus, content-based firewall, anti-spyware, and general overhead. This leaves the other core(s) to do real work.

Linux is not as bad but there's still some overhead, e.g. Beagle type file indexing, etc. And now that the web is becoming far more video based, and video is moving to HDTV ultimately as bandwidth improves (e.g. serving video within the home), even Joe Average will have far more reason to tie up multiple cores.

The real answer is that programmers will need to learn how to write threaded code even for tasks that are most obviously done sequentially.

future CPUs

Posted Aug 24, 2007 7:41 UTC (Fri) by Los__D (subscriber, #15263) [Link]

Most of these background tasks are more I/O intensive than CPU intensive, as far as I can tell...

If I'm right, then more cores wont really help much in this regard

future CPUs

Posted Aug 24, 2007 21:04 UTC (Fri) by landley (subscriber, #6789) [Link]

> The average Windows PC needs at least one core for 'admin' - running
> antivirus, content-based firewall, anti-spyware, and general overhead.
> This leaves the other core(s) to do real work.

Someone else pointed out this kind of background task causes problems
when it's I/O intensive rather than CPU, but I'll grant the point. I
have a dual core laptop right now.

The assumption I was challenging is that "scaling beyond 8 cores" is
likely to be remotely important to anybody in our lifetimes. SMP was
available back in 1982 (Anybody remember MP/M, the multiprocessing sequel
to CP/M?). OS/2 3.0 did SMP just fine in 1992. This is not something
new, and predictions of huge demand for it aren't new either. What's
always prevent it from becoming interesting is that programming to take
advantage of it is the difficulty to reward ratio in programming for it.
(I have spent two weeks trying to track down a race condition in
multithreaded OS/2 code interacting with the multithreaded desktop
through a third party library. There's a reason I don't bother with
threads anymore.)

> Linux is not as bad but there's still some overhead, e.g. Beagle type
> file indexing, etc.

Mono is a bad idea, gnome is a bad idea, beagle is mono plus gnome. Not
going there.

But again, "some processes are horribly inefficiently written resource
hogs" doesn't quite translate to "systems will be able to keep more than
8 processors busy real soon now".

> And now that the web is becoming far more video based, and video is
> moving to HDTV ultimately as bandwidth improves (e.g. serving video
> within the home), even Joe Average will have far more reason to tie up
> multiple cores.

Video exercises the 3D accelerator, not the processor.

> The real answer is that programmers will need to learn how to write
> threaded code even for tasks that are most obviously done sequentially.

Woah, Deja Vu. (That statement sounds exactly like Team OS/2, circa
1992...)

Programmers don't "need" to do anything. Sturgeon's law applies to the
thundering horde of ex-MCSE types out there, and the bottom 98% will not
be able to debug a multi-threaded race condition in my lifetime. They're
writing visual basic, cut-and-pasting javascript, and they think C++ is
better than C due to the ability to declare things private from their
co-workers.

Sure, the solution isn't to make hardware that does things people want it
to do, the solution is to force all the people to change to take
advantage of the hardware.

I'm not holding my breath.

future CPUs

Posted Aug 30, 2007 10:38 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

No, MP/M wasn't a multiprocessor operating system, it was only a multiprocessing operating system. Today all operating systems are multiprocessing and we take it for granted, it just means that they appear (through time-slicing) to run more than one process aka program at a time. MP/M's ancestor, CP/M was able to run just one program at a time. You could run the text editor, then save your changes and exit, and run the compiler, then the linker, then test the resulting program, see if you'd fixed the bug you were working on, and restart the text editor to continue programming. Digital Research added multiprocessing to create MP/M which they hoped would sell as a multi-user system, two or more people connected to terminals, effectively time-sharing a single CPU with MP/M. Instead people bought it so that at last they could run more than one program at once, a huge time saving.

OS/2 was eventually available in an (expensive) SMP capable version, but only in the mid-1990s, when Windows NT was already SMP, and work to make Linux SMP capable had begun. The first successful SMP version of OS/2 (Warp Advanced Server) wasn't released until 1996, by which time there were many more NT and Linux systems on multi-processor machines.

As to your main thesis, that it's irrelevant how to scale to large numbers of CPU cores, well, the trouble is that Moore's law isn't running out of steam, but it no longer delivers faster CPU cores, just more transistors to make them out of. The obvious way forward is to add more cores and parallelize the software. I acknowledge that this is very hard, but it's no use just saying "that's hard, I won't do it".

future CPUs

Posted Aug 30, 2007 23:46 UTC (Thu) by Nelson (subscriber, #21712) [Link]

What's so bad about Mono?

While it might not be Java or .Net/Mono, technologies like those are exactly how we exploit more parallelism. It's fairly easy to write thread safe code in both. Writing good parallel algorithms is a different matter, but for a lot of common applications there are real advantages just parallelizing certain tasks, just UI response is often a win, for example. (Being an OS/2er I guess you might not have minded the single input queue, you ever search in the help tool and see the whole UI freeze until it was done?) Sure, java and mono are not as fast as assembly... It's been clear as day for decades that parallelism is going to be the future, whether or not you ever want to admit it, it's the only possible way to continue to improve performance at the same rates.

future CPUs

Posted Aug 25, 2007 17:45 UTC (Sat) by oak (subscriber, #2786) [Link]

> The real answer is that programmers will need to learn how to write
threaded code even for tasks that are most obviously done sequentially.

Why? For most tasks one of the system cores on a newish machine should be
fast enough. I don't want DummyApp to keep my whole machine sluggish, it's
better that it runs only on a single core. This saves battery &
electricity (& the world) as the other cores can sleep.

I'd rather programmers spend their time learning to profile and optimize
their code properly than how to create multi-threaded messes. Learning
properly meaning "choose your algorithms / data structures with
care", "premature optimization is root of all evil" etc...

future CPUs

Posted Sep 7, 2007 11:50 UTC (Fri) by Cato (subscriber, #7643) [Link]

Multi-threading is needed because CPUs won't stop at 2 cores - expect 8, 16 and 32 core CPUs (Sun is getting there already with Niagara). Admittedly many tasks won't need multiple cores, but video is an increasingly important datatype that can really use this sort of power. And of course there will be apps invented in next 20 years that we can't imagine (who anticipated Youtube 20 years ago?), perhaps using grid technology with complex local rendering to provide medical advice.

future CPUs

Posted Aug 24, 2007 4:51 UTC (Fri) by Nick (subscriber, #15060) [Link]

Once the data is in cache, it doesn't matter which order it eventually
gets into main memory for all modern coherency protocols that I know
of -- because other CPUs operating on that location are prevented from
doing so until any other possible dirty lines are flushed out (or they
can be transferred directly over from the other cache, in the case of
MOESI).

The interesting thing is the order that the CPU is allowed to get the
data into and out of the cache. However, Intel has got most of the
bases covered here: they indeed do require stores to be in order WRT
other stores, and similarly for loads. These cases are possible to
optimise almost as well as weakly ordered architectures: on the store
side, you can just make store queues large enough to cover typical
latencies; on the load side, they can actually speculatively execute the
loads out of order and recover in the rare cases where it is detected to
have possibly given the wrong results. There are papers on this from the
early 90s I think, and they show they were able to bring performance of
an in-order consistency model very close to a release-consistency model.
(sure, this may not be 100% relevant to modern cores and multi-core
architectures, but I think the theory is still sound).

I think reordering loads before earlier stores is one of the most
important optimisations that can be made (because stores can be easily
deferred and typically have few dependent instructions -- none if you
have perfect store forwarding, while loads have lots of dependants). It
is also hard to do speculatively. However Intel's memory model does
allow reordering in this specific case, so it turns out they were
pretty clued-up back when they decided on this memory model.

There is no doubt a weak, acquire/release model could be better, but I
don't know if this is going to be the killer. Intel can afford to put a
fair bit of complex logic in here because they already have so much to
get single threaded performance that it isn't so significant. If
software gets so parallel that single threaded performance doesn't matter,
then we actually might see lots of really simple ARM cores taking over...
but is that likely to happen any time soon?

future CPUs

Posted Aug 24, 2007 7:16 UTC (Fri) by mingo (subscriber, #31122) [Link]

If software gets so parallel that single threaded performance doesn't matter, then we actually might see lots of really simple ARM cores taking over... but is that likely to happen any time soon?

Single threaded performance will become irrelevant once the human brain starts thinking about logic/algorithmic problems in parallel. I.e. in a few million years at the earliest, once biologic evolution catches up with these demands ;-) (or, much more likely, the moment people start hacking their genome - at which point it's a stretch to call them humans anymore. Or, perhaps even more likely, once machines start their own, independent cycle of evolution, eventually marginalizing/eliminating that weak link of protein based life.)

Or, alternatively, once computers will be able to transform arbitrary serial algorithmic sequences into large-scale parallel sequences. (i'm guessing on one of the former variants to occur first though.)

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds