The software model should be such that all input instructions should have no dependencies.
Are you really serious? We have an architecture for that. It's called THE STUPIDEST IDEA EVER. You're saying that — somehow — you can program something useful where every instruction is completely independent of all instructions before it? So, like, if I wanted to write a program to multiply two numbers and store the result in memory, I'd have to have a single instruction for it? And what if I had to get both the numbers from memory as well? And what if I didn't want to just multiply them, but divide them by a third number? How the hell would you code that? With your brilliant plan I'd have to have a single instruction to do that. Terrific.
Processors jump through a lot of hoops to extract parallelism from the instruction stream. Eventually you get down to a level where you just can't. EPIC is good because it offloads a lot of the hardware required for that (and all the energy costs with it) to the compiler, which is a one-time cost. Architectures such as x86, though, still rely on processor hardware to make all the decisions.
Trust me, there's a lot of people out there much smarter than yourself working toward your dream.
There is an infinitely better way to design and program parallel computers that does not involve the use of threads at all. Instead of the Penryn, Intel should have picked something similar to the Itanium, which has a superscalar architecture.
You do know that superscalar architectures have no relevance to multithreading, right? You can have a superscalar MT core, or a superscalar ST core, or a single-issue MT core, or whatever the hell combination you want, and nobody even cares? It's true.
Sooner or later, a competitor will read the writings on the wall and do things right. Intel and the others will be left holding an empty bag.
Intel's CTO Justin Rattner just gave a talk at Cornell two days ago; he covered this topic carefully and confirmed that Intel has the technology and plans to carry out Moore's Law for another 10 years on silicon. Technologies such as SOI and optical interconnects will be leveraged to hit this.
It's not necessarily the size of the transistors that make chips hard to make these days either (although they are now giving us huge problems with leakage current). It's harder to route the metal between these transistors than it is to pack them onto the silicon. New processors from Intel and AMD have areas with low transistor density just because it was impossible to route the large metal interconnects between them. Before we can take advantage of even smaller transistors we'll need a way for higher interconnect density.
Here's a short section of the interface design guidelines as released by Apple:
Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits. It's important to make sure that users do not experience any negative effects because of this reality. In other words, users should not feel that leaving your iPhone application and returning to it later is any more difficult than switching among applications on a computer.
So when the JVM is used by an application, it'll be launched/terminated each time the app is switched to? I'm willing to bet that will make apps that leverage the JVM almost unbearable to use.
I agree with the parent. Too many people confuse the idea of an OS with the standard suite of applications that are shipped with it. When users say that they like the Windows OS or the Mac OS, what 99% of them mean is that they like the applications shipped with it. These applications include the window manager, mail software, file explorer, and others.
Linus is stating that the OS itself should take a back seat and be invisible to the user. And, ironically, this is why many people choose to use Windows and Mac over Linux: they know that, for the most part, they won't need to worry about how the kernel is interacting with their hardware setup and desktop applications. They don't need to know what file system or network adapter they are using, because that level of complexity is hidden well by the applications that are shipped with the operating system.
Where does this lead? I would venture that the two most popular reasons people don't use Linux are either: they don't know about it; or, they believe that it is too complex. The second reason comes straight back to the point that Linus is making: people have the perception that using Linux will require them to know more about their hardware or systems than they feel that they know. And, usually, they are wrong. I just believe that there are more utilities in Linux distros to mess with the operating system than there are in Windows or Mac (a result of being open source), but that using it on a daily basis requires no more knowledge than using the other two.
... as does the chip-makers' obsession with speed. 'There is more to computing than processor speed -- a point which can be easily proven by comparing a two-year-old PC running Linux with a new PC buckling under the weight of Vista. Shrinking the manufacturing process to enable greater speed has proven essential, but it's running out of magic...
Yes, there is more to a processor than raw clock speed. But the article misses a great discussion here and suggests "a better way of tagging data." WTF?
AMD and Intel have already realized that faster clock speeds no longer equates into free performance. The newest processors have cache sizes that were unthought of four years ago. Whether consumers realize it or not, multicore superscalar desktop processors will and have become the norm. These processors have the ability to take advantage of parallelism in programs, which is what the article should have addressed: the slow adoption of desktop processor technologies by large software companies.
While some software, such as 3D renderers and other CPU-intensive applications, take advantage of multiple cores on the same CPU, the vast majority of desktop software still is compiled for a single-issue, single-core CPU. Until we see compilers that are able to take advantage of parallelism in source code, and coding languages that emphasize run-time parallelism and multi-threading become the norm, desktop performance is going to progress pretty slowly.
True, measuring actual current draw and temperature statistics will always require the physical hardware in question. But modern hardware simulators are able to accurately model such parameters (as well as architecture-dependent events such as cache misses) and give a good feel for the performance (both in terms of power consumption and software speed). And I'm sure an architecture as popular as ARM has several simulators for that exact purpose.
I've been seriously disappointed with the number of times I've interconnected USB 1.1 and USB 2.0 devices and had them almost work, only to encounter various strangeness and glitches. I don't know who's to blame... whether it's a fault in the standard or in vendors' faulty implementations... and life's too short to care, because know who's to blame wouldn't do much to help solve the problem. It's not the specification that is to blame. I've spent the time implementing a USB 2.0 host controller, and I can say that the specification is definitely able to handle the mix of USB 1.1 and USB 2.0 devices on it.
the result is all sorts of opportunities to build devices that comply with the standard but do things just a little differently than the most popular devices... and have them not work even though they "should."
This is exactly where the problem is: with the device vendors. There are a lot of choices for USB hardware, and you get what you pay for. With the 600+ page spec that USB 2.0 comes with, it's easy to trip up and miss a corner case that the spec defines. But bear in mind that the spec does define that corner case, and what to do when you reach that. It's up to the vendor to actually implement that.
USB 3.0 will have its own fair share of sloppy vendors that don't spend the time to implement the spec fully, and that will cause a lot of headaches for end users. As the products mature, however, we should see that USB 3.0 will be a powerful protocol. I see a lot of complaints on this article about the 'actual' vs. 'projected' speeds for USB. These posters need to understand a few things:
When the spec states that information flows across the bus at 480 Mbits/s, that means that the frequency at which the bits toggle on the line is 480 Mbits/s. For data to be sent across a USB line, the host must first initiate the transfer with a 'token' packet, which is about 2.5 bytes. There has to be about half a byte of 'delay' on the line after that, at which point the sync for the data packet can be sent, which is about a byte. Only at this point can the actual data be transmitted. But it's not even that easy, because the data is NRZI-encoded and bit-stuffed as well. This is why there's a lot of CPU overhead with USB data transfers - the CPU has to decode the data packet. After the data packet is sent, there's at least 3 more bytes of stuff that needs to happen before the entire transfer is complete.
There's even a limit on the size of the data packet: in USB 2.0, for a bulk transfer (i.e. when you're copying a file to/from your external drive) the maximum data that can be transmitted in one data packet is 512 bytes. And there's no guarantee that you'll even be granted a data transfer at a constant rate - it's completely up to the host controller how often it'll ask the device for a data transfer. If there's a lot of devices contending for the bus, your up/download rates will suffer.
There's a lot of necessary overhead inherent in an asynchronous communication protocol, especially one that grants you the ability to put multiple devices on the same bus. End users need to understand that data does not magically "pop" from one end of the cable to the other, and wherever there are different people implementing the same spec there will be slight differences in how the devices end up working.
Slashdot Mirror
LOL
The software model should be such that all input instructions should have no dependencies.
Are you really serious? We have an architecture for that. It's called THE STUPIDEST IDEA EVER. You're saying that — somehow — you can program something useful where every instruction is completely independent of all instructions before it? So, like, if I wanted to write a program to multiply two numbers and store the result in memory, I'd have to have a single instruction for it? And what if I had to get both the numbers from memory as well? And what if I didn't want to just multiply them, but divide them by a third number? How the hell would you code that? With your brilliant plan I'd have to have a single instruction to do that. Terrific.
Processors jump through a lot of hoops to extract parallelism from the instruction stream. Eventually you get down to a level where you just can't. EPIC is good because it offloads a lot of the hardware required for that (and all the energy costs with it) to the compiler, which is a one-time cost. Architectures such as x86, though, still rely on processor hardware to make all the decisions.
Trust me, there's a lot of people out there much smarter than yourself working toward your dream.
Intel will regret this.
I'm pretty sure they won't regret this.
There is an infinitely better way to design and program parallel computers that does not involve the use of threads at all. Instead of the Penryn, Intel should have picked something similar to the Itanium, which has a superscalar architecture.
You do know that superscalar architectures have no relevance to multithreading, right? You can have a superscalar MT core, or a superscalar ST core, or a single-issue MT core, or whatever the hell combination you want, and nobody even cares? It's true.
Sooner or later, a competitor will read the writings on the wall and do things right. Intel and the others will be left holding an empty bag.
What the hell?
Learn some architecture and come back.
Intel's CTO Justin Rattner just gave a talk at Cornell two days ago; he covered this topic carefully and confirmed that Intel has the technology and plans to carry out Moore's Law for another 10 years on silicon. Technologies such as SOI and optical interconnects will be leveraged to hit this.
It's not necessarily the size of the transistors that make chips hard to make these days either (although they are now giving us huge problems with leakage current). It's harder to route the metal between these transistors than it is to pack them onto the silicon. New processors from Intel and AMD have areas with low transistor density just because it was impossible to route the large metal interconnects between them. Before we can take advantage of even smaller transistors we'll need a way for higher interconnect density.
Especially not Bram Moolenaar.
Here's a short section of the interface design guidelines as released by Apple:
So when the JVM is used by an application, it'll be launched/terminated each time the app is switched to? I'm willing to bet that will make apps that leverage the JVM almost unbearable to use.
I agree with the parent. Too many people confuse the idea of an OS with the standard suite of applications that are shipped with it. When users say that they like the Windows OS or the Mac OS, what 99% of them mean is that they like the applications shipped with it. These applications include the window manager, mail software, file explorer, and others.
Linus is stating that the OS itself should take a back seat and be invisible to the user. And, ironically, this is why many people choose to use Windows and Mac over Linux: they know that, for the most part, they won't need to worry about how the kernel is interacting with their hardware setup and desktop applications. They don't need to know what file system or network adapter they are using, because that level of complexity is hidden well by the applications that are shipped with the operating system.
Where does this lead? I would venture that the two most popular reasons people don't use Linux are either: they don't know about it; or, they believe that it is too complex. The second reason comes straight back to the point that Linus is making: people have the perception that using Linux will require them to know more about their hardware or systems than they feel that they know. And, usually, they are wrong. I just believe that there are more utilities in Linux distros to mess with the operating system than there are in Windows or Mac (a result of being open source), but that using it on a daily basis requires no more knowledge than using the other two.
... as does the chip-makers' obsession with speed. 'There is more to computing than processor speed -- a point which can be easily proven by comparing a two-year-old PC running Linux with a new PC buckling under the weight of Vista. Shrinking the manufacturing process to enable greater speed has proven essential, but it's running out of magicYes, there is more to a processor than raw clock speed. But the article misses a great discussion here and suggests "a better way of tagging data." WTF?
AMD and Intel have already realized that faster clock speeds no longer equates into free performance. The newest processors have cache sizes that were unthought of four years ago. Whether consumers realize it or not, multicore superscalar desktop processors will and have become the norm. These processors have the ability to take advantage of parallelism in programs, which is what the article should have addressed: the slow adoption of desktop processor technologies by large software companies.
While some software, such as 3D renderers and other CPU-intensive applications, take advantage of multiple cores on the same CPU, the vast majority of desktop software still is compiled for a single-issue, single-core CPU. Until we see compilers that are able to take advantage of parallelism in source code, and coding languages that emphasize run-time parallelism and multi-threading become the norm, desktop performance is going to progress pretty slowly.
True, measuring actual current draw and temperature statistics will always require the physical hardware in question. But modern hardware simulators are able to accurately model such parameters (as well as architecture-dependent events such as cache misses) and give a good feel for the performance (both in terms of power consumption and software speed). And I'm sure an architecture as popular as ARM has several simulators for that exact purpose.
Instead of a dummy in the front seat, I'll just put my toaster. Done.
This is exactly where the problem is: with the device vendors. There are a lot of choices for USB hardware, and you get what you pay for. With the 600+ page spec that USB 2.0 comes with, it's easy to trip up and miss a corner case that the spec defines. But bear in mind that the spec does define that corner case, and what to do when you reach that. It's up to the vendor to actually implement that.
USB 3.0 will have its own fair share of sloppy vendors that don't spend the time to implement the spec fully, and that will cause a lot of headaches for end users. As the products mature, however, we should see that USB 3.0 will be a powerful protocol. I see a lot of complaints on this article about the 'actual' vs. 'projected' speeds for USB. These posters need to understand a few things:
When the spec states that information flows across the bus at 480 Mbits/s, that means that the frequency at which the bits toggle on the line is 480 Mbits/s. For data to be sent across a USB line, the host must first initiate the transfer with a 'token' packet, which is about 2.5 bytes. There has to be about half a byte of 'delay' on the line after that, at which point the sync for the data packet can be sent, which is about a byte. Only at this point can the actual data be transmitted. But it's not even that easy, because the data is NRZI-encoded and bit-stuffed as well. This is why there's a lot of CPU overhead with USB data transfers - the CPU has to decode the data packet. After the data packet is sent, there's at least 3 more bytes of stuff that needs to happen before the entire transfer is complete.
There's even a limit on the size of the data packet: in USB 2.0, for a bulk transfer (i.e. when you're copying a file to/from your external drive) the maximum data that can be transmitted in one data packet is 512 bytes. And there's no guarantee that you'll even be granted a data transfer at a constant rate - it's completely up to the host controller how often it'll ask the device for a data transfer. If there's a lot of devices contending for the bus, your up/download rates will suffer.
There's a lot of necessary overhead inherent in an asynchronous communication protocol, especially one that grants you the ability to put multiple devices on the same bus. End users need to understand that data does not magically "pop" from one end of the cable to the other, and wherever there are different people implementing the same spec there will be slight differences in how the devices end up working.