Assuming they go multicore (like IBM and Power[x] chips) what are the limits involved there? What would logically stop the development of multicore chips from increasing their number of cores?
One limit is still power dissipation. Yes, you get more bang for your watt by going multicore, but each core must be simpler than a uniprocessor one, and finding the right balance will probably require some iterations.
A related problem is to write efficient software for these beasts. Keeping two or even four cores reasonably busy is probably simple with today's multitasking OSes, but more of them?
Another problem is memory bandwidth. Memory access is already a huge bottleneck, and going multicore does nothing to solve that.
And: What next?
First of all, do people really want more powerful processors, or do they prefer cheaper or more silent ones?
Assuming people want more power, it is probably safe to say that lots of parallelism will be needed. This will mean that the nice, comfy world of programming languages like C, Java, and Python must be abandoned for exotic parallel programming languages that are mostly not even defined yet.
The exact form of this parallelism is difficult to predict, but could range from lots of small cores on a single chip, like the IBM/Sony Cell processor, to local processors on each memory chip, to reconfigurable hardware similar to FPGAs.
How long before we can reach it with rockets and park it at one of the Lagrange points? Something that massive would be much better for an international space station than a few hundred tons in low earth orbit, and it would provide more than enough shielding for any conceivable solar flare.
That is never going to be practical. What you are suggesting requires slowing it down almost completely. The amount of energy required for that would be huge (lots of orders of magnitude more than we're currently capable of).
Moreover, if we want a huge rock in a convenient orbit, there are lots of good candidates in the solar system that would require far less energy.
For example, in QT4, they are moving to new template containers, but instead of using the STL (which even MFC developers tend to use) they having decided to develop their own container classes.
Qt3 also has container classes, Qt4 just has more of them. I for one welcome this, since they are much more useful than the STL ones. Ditto for QString versus string.
Standards are great, but the Qt people have the courage to fix their mistakes.
Could you please explain why a JVM could not notice that you are autoboxing a primitive type into a parameterised collection, and then just store the unboxed primitive efficiently, with a type specialised piece of code, as Pizza or.Net would?
I can't really see why this would be impossible or even hard... and the Java way does keep the class format the same.
Because the programmer can also put instances of the boxed type in that collection. Since there may be references to these instances outside of the collection, they can potentially be modified from outside the collection.
Of course, a compiler could try to prove that no such modifications occur, (e.g. by proving there are no other references) but that's not so simple.
Some things I can't say were related to these displays... There were at least 3 (nda) sessions I attended where I kept thinking mentally. "It's about time. I wonder if the 30" displays made the engineering teams decide to finally add this to Mac OS X". The Mac has always said that they have a well engineered foundation for graphics, but I think making these displays a reality will be a nice impetus for getting some of those ideas out of the realm of theory and into reality as well:-)
These displays are a great thing that will benefit Mac users even if you don't have a 30" display.
Hmm, now what would you do with a 30" display if you're not hooking it up to a computer? Something graphics intensive? You couldn't possibly be hinting at TV, could you?
TiVo-like functionality on a mac would be great! I already wondered if the iLamp models would be useful for that, but they would probably be a little too small in many situations.
Good idea, bad example. I can think of a few ways just in ten seconds why a compiler could never match numbers of mallocs/frees successfully.
Agreed. This is fundamentally impossible at compile-time.
Java does something like this [compile-time checking] to prevent an app from dereferencing a null pointer - but it only works in local scope.
No it doesn't. This is just as impossible as the malloc check you reject! You are proably confusing a number of Java features.
Java has strict runtime checking of null pointers dereferences and array bound violations.
Also, it has compile-time checks to prevent the use of un-initialized variables.
These bounties are really odd. Can you imagine if structures were built that way? First one to build me a new arena, to spec, gets $1 Million! We'd either have no buildings at all or a bunch of partially-built shells.
Bad example. Competitions are very common for building design (i.e. architecture). For example, a quick Google on `architecture competition' gives this one.
Given that each seat already has a myriad of cabling going to it, I simply can't see why they've opted for WiFi connectivity - other than as a gimmic.
Two good reasons are weight and maintenance. All that extra wiring may be a small fraction of total takeof weight, but why waste it, when you can get paid for air freight or burn less fuel? Also, keeping all those connectors functioning is much harder than keeping a wireless access point running.
Oh, and installing all that wiring would require a lot of expensive maintenance time, whereas installing a wireless access point is fairly simple.
How many people do you know with dual procs. anywho? the only one I know is a mac friend. What kind of heat sink are we going to need for dualies? Its gotta weigh in round 5lbs. And have the noise output of a harley
That's exactly what they try to avoid. Each core in a multi-core processors is simpler than a single processor of the current generation, but they make it up by putting two or more of them on the same chip. Another way to look at it is that the parallel execution units of a current generation processor are made even more autonomous, and this is made explicit by declaring them to to be separate processor cores.
The point is to use the available transistors on a chip as effictively as possible. For a long time computer architects used the growning number of transistors to enlarge caches and pipelines, add execution units, and add other niceties (e.g. branch prediction, MMX), but the gains have gotten less and less (and were sometimes dubious to begin with).
Multicore processors are only useful if people have enough parallelism in their applications to make it worthwhile. Therefore, it won't help every application, but that's also true for many tricks in existing architectures.
History suggests that the reverse also happens. Outsourcing in the past also led to wage hikes in the low-wage countries. Witness Japan, Korea, Taiwan, and even Germany shortly after WWII.
Of course, this is not an unbreakable law, but I've already seen the first complaints by outsourcers about large wage hikes in India.
Well politics aside, owning the "high ground" has been a military imperative since there was a military.
It is not at all clear that this particular high ground has any advantages in a military conflict, apart from reconaissance.
The amount of enery that is needed to do something nasty from orbit is usually so large that a terrestial weapon is much more efficient.
Personally I hope that manned Mars missions can be international and a point of pride for Humanity as a race, rather than an object of Nationalistic hubris.
Good for you, but how likely is an international mission? And do you think that every US citizen will be glad for the Russians or Chinese (or even the Europeans) if they were the first to get to mars?
Presuming you're talking about Iraq, let me remind you that even considering that their WMD program was a failure, there was still ample reasons to invade.
Such as? And `helping terrorists' doesn't count, since there is no credible evidence that Saddam did that. That only leaves `being an annoying git' and `mass murder'. There is ample evidence on both counts, but neither have been reason to invade in the past. It is not clear why Iraq should be an exception.
Oh, and ditch the "proven beyond a reasonable doubt" bullcrap. The world of international diplomacy is not analagous to a courtroom.
You mean that in diplomacy vague innuendo is enough? Probably true, but not something to brag about.
It's not like we could put out a warrant for Saddam's arrest and then search his premesis for clues. He and his thugs would resist,...
In a dictatorship, yes. Otherwise, you would search the premises first to find clues, and then arrest the suspect if warranted. In Iraq, weapons inspectors were searching the premises, but found no evidence. And yes, the suspect resisted, but that is not proof of guilt.
... we'd have force our way in, and suddenly we're in the middle of a war.
What do you mean, `have [to]'? Nobody was forcing the USA to invade. And `suddenly' is a poor choice of words, it is not as if the USA wasn't warned about the mess they were getting themselves in.
I'm not sure why the von Neumann architecture is such a security problem.
That's not what they mean. The article is a report on a defense brainstorm session where people identified fundamental problems in today's computer/datacom technology (for defense applications). Unfortunately, many of these issues get labeled with terms that are not immediately obvious to outsiders. My translation is:
TCP/IP causes security problems, one of them is the lack of support for channel reservation for important data.
Current network protocols have fundamental problems in setting up ad-hoc networks, because the OSI protocol layer model that everyone uses does not support this.
The von-Neumann computer model that every main-stream processor uses is becoming more and more problematic, because for technological reasons it would be better to use more parallel computers.
In this context the von-Neumann architecture is the traditional sequential instruction execution model, and alternatives would have multiple parallel instruction streams, or would be radically different architectures such as data-flow machines, systolic arrays, or field-programmable gate arrays.
And since this is just a blue-sky brainstorm session, don't expect any of the proposed changes to be implemented overnight, or taken serious by anyone with any money. In fact, I read this more as a list of `to do it right it must be done like this' items rather than a list of commands to some kind of development institute.
Fact 1: Electric motors are more efficient than internal combustion engines. Run a gas engine at X watts for 20 minutes. Run an electric motor at X watts for 20 minutes. Afterwards, the gas engine will be hotter than the electric motor. Yes, it depends on the load, blah, blah, blah, but in the loads typically encountered by cars, the internal combustion engine loses.
Yes, true, but it does not address the "But electric cars just get energy from gas-burning power plants . .." argument you put up yourself. Which is a pity, because it can be answered: since those gas-burning power plants can be tuned to a specific load, they can be more efficient than even good car engines.
As far as I know the efficiency of `gas to torque' of the two processes is rougly the same, but with electric cars you at least have the potential to use cleaner energy sources, and you get the pollution at a central place where you can do something about it.
The only truely clean form of power available today is nuclear, yet every self-describes "environmentalist" I know is dead-set against it for reason I can't understand.
Nuclear power plants are most certainly not clean. They produce lots of radioactive waste that must be disposed of somehow at great expense. Producing the fuel for these power plants is complicated and produces more radioactive waste. And once such a power plant is decomissioned, it becomes an even larger lump of radioactive waste. Taking this into account I'm not so sure that nuclear power is at all economical.
Beyond the economical problems, there are other issues: is it right to leave future generations with all this nuclear waste, even if it is burried somewhere? Nuclear accidents are unlikely, but are potentially very lethal. Do we really want to take this risk? And there are some nasty issues with potential terrorism and WMD that are real despite the hype.
No power source will ever be truely clean, but I think that the best we could do today is put large solar arrays into orbit, and beam down the generated energy (and no, the downlink would not be dangerous). The problem is that this is only economical on a massive scale.
The only problem is that there is no way for the election officials and representatives to verify that the software is reliable and has not been tampered with. Perhaps some sort of checksum process similar to what's used in slot machines could do???
In my opinion all such software should be open source by law.
In fact, all blueprints of such a machine should be public as well. No matter how you think about OSS in general, this is a clear example where openness is so important that no compromises should be made.
And to counter the most common objections against this: yes, hackers will have an easier job if everything is open, but the same is true for everyone that wants to verify it. And yes, there will still be manufacturers for this, why not?
Of course making it open may mean that the development needs public funding, but since a good system could be used for many elections all over the world, that shouldn't be a problem.
It should be pretty obvious that the "cutting off their air supply" strategy is still applicable, it just has to be modified to attack a different form of currency. Instead of impacting revenue or hard currency, Microsoft will have to impact the reputation of the competing technology. It must harm Linux's reputation. Which, in turn, reduces or erodes Linux's adoption and resources.
Very good summary.
The chilling thing is that by describing it in such a detached manner, it even sounds like a sound business strategy. Put in a few more eufemisms, and I can imagine the Microsoft board of directors discussing this as yet another item between, say, the packaging of the next Flight simulator and the budget problems of Microsoft Japan.
What is even more chilling is that, assuming the analysis is true, SCO is essentially a corporate suicide bomber for Microsoft.
I know Linus is everybody's teddybear, but wouldn't this finally be an excellent opportunity for him to get an injunction at the very least?
Try to put yourself in his shoes. What would you rather do: spend 20% of your next few years in meetings and court, or spend all that time doing something interesting? And the only point of the excercise would be to defend your honour, since IBM will mash SCO into a fine pulp anyway.
LCD's do that already! They stay in their state until they get a signal to change their brightness. They arent scanned like CRTS are! Thats why they look more clear/are thinner etc/.
That's wrong on a lot of levels: LCDs do not store light, they selectively block it. Liquid Crystals (that give LCDs their name) do not stay in a fixed state on their own, but must be regularly aligned. Small and old displays use scanning very similar to CRTs, modern and large displays have a memory cell for each pixel.
No, the API changes way too much. You do not ever need to make an API totally incompatable with previous versions to add stuff to it, ever heard of backwards compatability?
If you want open source drivers, write one yourself.
Sigh. Like nobody thought of that before.
The problem is the documentation isn't there, and aparently reverse-engineering it is too difficult/dangerous.
And yes, there are good reasons for wanting an open-source driver. For example, the current driver is known to do a double memory free on some occasions. Could have been fixed easily if the source was available. And it would have been far better if the NVidia driver could have been developed with all the other drivers during the 2.5 development cycle, because any bugs could have been detected much earlier.
There are very good reasons for wanting open-source drivers, even if you're not an OSS fundamentalist.
[I was turned off by] non-standard classes, e.g. string
Normally, I'd agree, but somehow QString always makes the things I want to do easy, whereas string makes the same thing much more painful. The same goes for Qt container classes versus STL container classes.
There is a reason for this: the Qt designers have refined these classes over the years, and were willing to abandon old aproaches that didn't work. And they have taste.
The STL, on the other hand, is in some places poorly designed, and has been refined very little over the years.
Compatibility with standards is A Good Thing, but so is having a clean design.
Wouldn't the whole process be faster if the "seed 'bomblets'" exploded on landing?
No, because (a) you don't explode all mines this way, and (b) there is always a fraction of the bomblets that doesn't explode, so you're only making the problem worse (just ask the iraqi children in some areas where cluster bombs were used). Oh, and (c) cluster bombs are expensive, especially compared to flower seed, even if it is GM seed.
Slashdot Mirror
One limit is still power dissipation. Yes, you get more bang for your watt by going multicore, but each core must be simpler than a uniprocessor one, and finding the right balance will probably require some iterations.
A related problem is to write efficient software for these beasts. Keeping two or even four cores reasonably busy is probably simple with today's multitasking OSes, but more of them?
Another problem is memory bandwidth. Memory access is already a huge bottleneck, and going multicore does nothing to solve that.
And: What next?
First of all, do people really want more powerful processors, or do they prefer cheaper or more silent ones?
Assuming people want more power, it is probably safe to say that lots of parallelism will be needed. This will mean that the nice, comfy world of programming languages like C, Java, and Python must be abandoned for exotic parallel programming languages that are mostly not even defined yet.
The exact form of this parallelism is difficult to predict, but could range from lots of small cores on a single chip, like the IBM/Sony Cell processor, to local processors on each memory chip, to reconfigurable hardware similar to FPGAs.
That is never going to be practical. What you are suggesting requires slowing it down almost completely. The amount of energy required for that would be huge (lots of orders of magnitude more than we're currently capable of).
Moreover, if we want a huge rock in a convenient orbit, there are lots of good candidates in the solar system that would require far less energy.
Qt3 also has container classes, Qt4 just has more of them. I for one welcome this, since they are much more useful than the STL ones. Ditto for QString versus string. Standards are great, but the Qt people have the courage to fix their mistakes.
I can't really see why this would be impossible or even hard... and the Java way does keep the class format the same.
Because the programmer can also put instances of the boxed type in that collection. Since there may be references to these instances outside of the collection, they can potentially be modified from outside the collection.
Of course, a compiler could try to prove that no such modifications occur, (e.g. by proving there are no other references) but that's not so simple.
These displays are a great thing that will benefit Mac users even if you don't have a 30" display.
Hmm, now what would you do with a 30" display if you're not hooking it up to a computer? Something graphics intensive? You couldn't possibly be hinting at TV, could you?
TiVo-like functionality on a mac would be great! I already wondered if the iLamp models would be useful for that, but they would probably be a little too small in many situations.
Agreed. This is fundamentally impossible at compile-time.
Java does something like this [compile-time checking] to prevent an app from dereferencing a null pointer - but it only works in local scope.
No it doesn't. This is just as impossible as the malloc check you reject! You are proably confusing a number of Java features.
Java has strict runtime checking of null pointers dereferences and array bound violations. Also, it has compile-time checks to prevent the use of un-initialized variables.
Bad example. Competitions are very common for building design (i.e. architecture). For example, a quick Google on `architecture competition' gives this one.
Two good reasons are weight and maintenance. All that extra wiring may be a small fraction of total takeof weight, but why waste it, when you can get paid for air freight or burn less fuel? Also, keeping all those connectors functioning is much harder than keeping a wireless access point running.
Oh, and installing all that wiring would require a lot of expensive maintenance time, whereas installing a wireless access point is fairly simple.
That's exactly what they try to avoid. Each core in a multi-core processors is simpler than a single processor of the current generation, but they make it up by putting two or more of them on the same chip. Another way to look at it is that the parallel execution units of a current generation processor are made even more autonomous, and this is made explicit by declaring them to to be separate processor cores.
The point is to use the available transistors on a chip as effictively as possible. For a long time computer architects used the growning number of transistors to enlarge caches and pipelines, add execution units, and add other niceties (e.g. branch prediction, MMX), but the gains have gotten less and less (and were sometimes dubious to begin with).
Multicore processors are only useful if people have enough parallelism in their applications to make it worthwhile. Therefore, it won't help every application, but that's also true for many tricks in existing architectures.
I don't know about Ebola, but yes, in general this is an important aspect of the virulence of both biological and computer viruses.
Of course, this is not an unbreakable law, but I've already seen the first complaints by outsourcers about large wage hikes in India.
It is not at all clear that this particular high ground has any advantages in a military conflict, apart from reconaissance. The amount of enery that is needed to do something nasty from orbit is usually so large that a terrestial weapon is much more efficient.
Personally I hope that manned Mars missions can be international and a point of pride for Humanity as a race, rather than an object of Nationalistic hubris.
Good for you, but how likely is an international mission? And do you think that every US citizen will be glad for the Russians or Chinese (or even the Europeans) if they were the first to get to mars?
There is a lot of prior art on this answer, proving that brilliant insights are not restricted to this day and age.
Such as? And `helping terrorists' doesn't count, since there is no credible evidence that Saddam did that. That only leaves `being an annoying git' and `mass murder'. There is ample evidence on both counts, but neither have been reason to invade in the past. It is not clear why Iraq should be an exception.
Oh, and ditch the "proven beyond a reasonable doubt" bullcrap. The world of international diplomacy is not analagous to a courtroom.
You mean that in diplomacy vague innuendo is enough? Probably true, but not something to brag about.
It's not like we could put out a warrant for Saddam's arrest and then search his premesis for clues. He and his thugs would resist, ...
In a dictatorship, yes. Otherwise, you would search the premises first to find clues, and then arrest the suspect if warranted. In Iraq, weapons inspectors were searching the premises, but found no evidence. And yes, the suspect resisted, but that is not proof of guilt.
What do you mean, `have [to]'? Nobody was forcing the USA to invade. And `suddenly' is a poor choice of words, it is not as if the USA wasn't warned about the mess they were getting themselves in.
That's not what they mean. The article is a report on a defense brainstorm session where people identified fundamental problems in today's computer/datacom technology (for defense applications). Unfortunately, many of these issues get labeled with terms that are not immediately obvious to outsiders. My translation is:
- TCP/IP causes security problems, one of them is the lack of support for channel reservation for important data.
- Current network protocols have fundamental problems in setting up ad-hoc networks, because the OSI protocol layer model that everyone uses does not support this.
- The von-Neumann computer model that every main-stream processor uses is becoming more and more problematic, because for technological reasons it would be better to use more parallel computers.
In this context the von-Neumann architecture is the traditional sequential instruction execution model, and alternatives would have multiple parallel instruction streams, or would be radically different architectures such as data-flow machines, systolic arrays, or field-programmable gate arrays.And since this is just a blue-sky brainstorm session, don't expect any of the proposed changes to be implemented overnight, or taken serious by anyone with any money. In fact, I read this more as a list of `to do it right it must be done like this' items rather than a list of commands to some kind of development institute.
However, the issues that are mentioned are real.
Yes, true, but it does not address the "But electric cars just get energy from gas-burning power plants . . ." argument you put up yourself. Which is a pity, because it can be answered: since those gas-burning power plants can be tuned to a specific load, they can be more efficient than even good car engines.
As far as I know the efficiency of `gas to torque' of the two processes is rougly the same, but with electric cars you at least have the potential to use cleaner energy sources, and you get the pollution at a central place where you can do something about it.
Nuclear power plants are most certainly not clean. They produce lots of radioactive waste that must be disposed of somehow at great expense. Producing the fuel for these power plants is complicated and produces more radioactive waste. And once such a power plant is decomissioned, it becomes an even larger lump of radioactive waste. Taking this into account I'm not so sure that nuclear power is at all economical.
Beyond the economical problems, there are other issues: is it right to leave future generations with all this nuclear waste, even if it is burried somewhere? Nuclear accidents are unlikely, but are potentially very lethal. Do we really want to take this risk? And there are some nasty issues with potential terrorism and WMD that are real despite the hype.
No power source will ever be truely clean, but I think that the best we could do today is put large solar arrays into orbit, and beam down the generated energy (and no, the downlink would not be dangerous). The problem is that this is only economical on a massive scale.
In my opinion all such software should be open source by law. In fact, all blueprints of such a machine should be public as well. No matter how you think about OSS in general, this is a clear example where openness is so important that no compromises should be made.
And to counter the most common objections against this: yes, hackers will have an easier job if everything is open, but the same is true for everyone that wants to verify it. And yes, there will still be manufacturers for this, why not?
Of course making it open may mean that the development needs public funding, but since a good system could be used for many elections all over the world, that shouldn't be a problem.
Very good summary.
The chilling thing is that by describing it in such a detached manner, it even sounds like a sound business strategy. Put in a few more eufemisms, and I can imagine the Microsoft board of directors discussing this as yet another item between, say, the packaging of the next Flight simulator and the budget problems of Microsoft Japan.
What is even more chilling is that, assuming the analysis is true, SCO is essentially a corporate suicide bomber for Microsoft.
Try to put yourself in his shoes. What would you rather do: spend 20% of your next few years in meetings and court, or spend all that time doing something interesting? And the only point of the excercise would be to defend your honour, since IBM will mash SCO into a fine pulp anyway.
That's wrong on a lot of levels: LCDs do not store light, they selectively block it. Liquid Crystals (that give LCDs their name) do not stay in a fixed state on their own, but must be regularly aligned. Small and old displays use scanning very similar to CRTs, modern and large displays have a memory cell for each pixel.
Linux developers do not support backseat drivers.
Sigh. Like nobody thought of that before.
The problem is the documentation isn't there, and aparently reverse-engineering it is too difficult/dangerous. And yes, there are good reasons for wanting an open-source driver. For example, the current driver is known to do a double memory free on some occasions. Could have been fixed easily if the source was available. And it would have been far better if the NVidia driver could have been developed with all the other drivers during the 2.5 development cycle, because any bugs could have been detected much earlier.
There are very good reasons for wanting open-source drivers, even if you're not an OSS fundamentalist.
Normally, I'd agree, but somehow QString always makes the things I want to do easy, whereas string makes the same thing much more painful. The same goes for Qt container classes versus STL container classes.
There is a reason for this: the Qt designers have refined these classes over the years, and were willing to abandon old aproaches that didn't work. And they have taste. The STL, on the other hand, is in some places poorly designed, and has been refined very little over the years.
Compatibility with standards is A Good Thing, but so is having a clean design.
No, because (a) you don't explode all mines this way, and (b) there is always a fraction of the bomblets that doesn't explode, so you're only making the problem worse (just ask the iraqi children in some areas where cluster bombs were used). Oh, and (c) cluster bombs are expensive, especially compared to flower seed, even if it is GM seed.