I described above the idea of including a DNS hostname in a normal host string. I like that because it only needs client library changes, DNS can stay the same, and those setting up alternative DNS hosts only need to include a few censored names, not the entire DNS database. If I had a few days, I'd whip a demo up myself, but that's not going to happen for a while.
I haven't had time to try this, but there's no reason not to include a DNS host in the hostname, to use as a resolver. An example to explain, imagine "oppressed-group.org" is blocked, but "freeworld.net" hosts a DNS with a list of blocked domain names (just some, doesn't have to be the entire DNS database), you could specify "oppressed-group.org(freeworld.net)" (or give the IP address of the DNS server). It could be chained with as many additional DNS servers as it takes (as in "host(dns2)(dns1)").
In the end, the servers see everything normally, the root DNS and other servers are unchanged, the only change is in the client code that does the lookup.
Alternative syntax could go in the other direction, using "/" or "!" (bring back bang paths!), looking like "freeworld.net!oppressed-group.org".
IBM generally sells business solutions and technology - the latter sometimes as patent licenses, sometimes developing products and selling them off. For example, the popular "swiping" method of keyboard entry on smartphones came from ""ShapeWriter" (previously SHARK), an IBM product they sold to another company to commercialise.
I'm sure there are a lot of assets in WebOS that could be developed. For example, what if you go a step beyond Apple's Siri, and integrate a smartphone interface with the deep AI of IBM's Watson Jeopardy champion (currently being commercialised for optimising medical treatment in the health insurance industry)? Sell or license that product to application developers for everything from intelligent tourist guides to on site first aid agents, who sell their wares on Android, iTunes, Blackberry or Microsoft app stores.
Lots of possibilities for a firm with cutting edge research and development. Like HP used to be, once.
Sun had out of order SPARCs for years, contrary to the article's claims. Sun had a two pronged strategy, one aimed at single thread performance (the UltraSPARC series), the other at multithreaded performance (the T series). The UltraSPARCs were never really that good, so were eventually dropped in favour of the Fujitsu SPARC64 series, and the replacement (code named "rock") was dropped by Oracle because progress seemed stalled forever, but they did indeed have out of order execution, register renaming, and "Rock" had a promising "pre-execution" thread that was supposed to alert cache controllers ahead of time to pre-fetch data that can't be statically predicted, dropping cache misses to near zero.
The purpose of the multithreaded processor was to support mainly I/O bound tasks, and lots of them - web servers are like this, though more in the past where web content was more static. In those systems, a T series SPARC system noticeably outperformed similarly priced competition (with similar reliability - you could get a lot cheaper if you didn't care about component quality).
The single threading improvements in the T series are being added because even I/O bound systems often have compute-bound tasks. In particular, the T4 lets you assign one high priority thread which gets to hog CPU resources, in addition to out of order execution and other techniques that all threads benefit from, so I/O bound threads don't get hung up waiting for a single CPU-bound task to finish.
I suspect a lot of people don't think about that expression "Can't see the forest because of all the trees in the way". But that seems to be life for the vast majority of people. When it comes down to it, the way almost everything works is wrong, somehow. But it's like a local minimum, almost nobody seems to look past a few small tweaks and adjustments to see the global minimum.
Related, but separate, something that bothers me about most technically minded developers or engineers trying to design things - almost all of them never bother finishing the race. When designing the interface for something, they will develop it until it's possible to accomplish a task, but usually no further. A classic example is digital clocks - how to adjust the time on them. Even now, the interface for most sucks into the negative digits, but the earlier ones were painfully stupid: Hold the "time" button, then either the "fast" or "slow" as the clock advances - past the time you want to set. Repeat this for another 12 or 24 hour cycle and miss again. Repeat until frustrated. Newsflash designers, you can add buttons to go backwards! Yes, you need to redesign the chip to subtract, but you only do that once. Millions of people have to set the time over and over.
And why doesn't every clock just have a "DST ON/OFF" switch? Is that really so impossible?
I see this over and over again, from things like Java libraries, Unix networking, Windows (classic press "start" to stop the computer - and why are there seven options, any why should I care which does what?), the damn "smart" photocopier (I needed to copy a slip of paper onto a page, the copier rotated it and cut off the bottom. I rotated the slip to match the new orientation, the copier rotated it and again cut off the bottom. Should I try diagonal?) - it's like technical types go as far enough to see the finish line, and say "theoretically we can finish the race, so let's just stop here".
This is the thing that separates a genuinely innovative product from others, actually getting to the destination. GUI word processors let you see the format, rather than imagine how special codes would make it look like eventually. iPods couldn't do as much as the competition, but the competition only made it possible to do more, iPods were easier to do more. Nintendo Wii games didn't require reading an instruction manual. A Roomba vacuum just had to be plugged in and turned on.
The common aspect of these things is designing for the end use, not the implementation. It's more work, but it's work that has to be done only once. The end user that has to figure out what they hell you were thinking has to do this every single time (until they get used to, say, a list of keystrokes or menu choices written on a post-it that they don't understand). If the user has to enter an email address, help out - have a separate username and host fields, with a "@" label between them, rather than trying to parse it for validity after it's entered and just saying "keep trying until you get the format right". Basically, anywhere there are user instructions that give a list of steps to perform, make the computer do them - computers are better at following instructions!
This, fundamentally, is why almost all smart phones sucked before the iPhone - every possible operation needed a magic invocation of actions (or a long menu path) to start that you had to memorize to use them. Apple designers (not one single person, but an entire design team) broke down what was needed and got rid of all exposed implementation, and put the effort into making it just work. I have no idea how complex the technology is that measures where I tap on an iPod keyboard and guesses which of the four keys my finger overlaps is the one I'm trying to press, but it gets it right so I don't care - it should just work, and it does, so I'm happy.
When it comes down to it, whether it's a dictatorship or not isn't important. But without some strong insistence on finishing the job, most technical developers won't bother. And even then, they can come up with some amazingly hair-brained designs (search for design failures/hall of shame sites). A dictatorship is a way to avoid them, at least.
[...] since the compilers necessary to perform the required dynamic analysis would have to cover just about every possible scenario
Just to clarify, it's not the compilers (though those are important too), it's the runtime which does the optimisation. The problem is the overhead required. The end result may crunch numbers faster in the end, but it may slow down unexpectedly after the execution has been profiled long enough to get data indicating a hot spot, and the optimiser kicks in. It's a little like the problem that garbage collection has - in the end, GC is faster than manual memory management (with few exceptions), but program freezes when it kicks in are annoying.
Multiple cores help - the optimiser can work in the background, with no slowdown and only imperceptible pauses when the binary blocks are replaced. But it's still a trade-off because you might have a better use for that second core.
Anyway, dynamic optimisation optimises how the program actually executes, it doesn't have to predict anything. The main advantages are that it can optimise in ways hardware can't (e.g. remove dead code entirely), and it can be updated with a software upgrade.
Oh, by CPU independence, I meant that the same code can be run without caring what it runs on, like Java. Previously Apple and NeXT simply included binaries for more than one CPU, but LLVM has the potential to perform the final compile step either at installation or runtime, as well as dynamic optimisation while running.
For compatibility, I think they had an emulator to run PA-RISC programs on Itanium. One of the incentives for starting an incompatible design was a project called Dynamo, which was like a Java JIT interpreter which analyses a program as it's running, and can optimise the most used parts. One surprise was that they could speed up a program by translating from PA-RISC to PA-RISC - the runtime optimisations in software were better than hardware (at the time).
A similar strategy was followed by Transmeta, interpreting 80x86 programs on custom VLIW CPUs. It failed partly due to Intel manipulation (basically giving a much better price to customers who never use a competing product), but partly from inconsistent performance - that matters less on a server, but more on a laptop, which was Transmeta's focus. Java is used mostly on servers, so the JIT and optimisation works well there.
I think continuing PA-RISC could have matched Itanium performance (if Itanium had not been delayed) eventually, but at the time it wasn't a sure thing. The real question was whether to put the dynamic optimisation in software or hardware, and a number of research projects hinted that software might be capable of far more than hardware (in addition to HP Dynamo, IBM's DAISY project did much the same thing, as well as Java JITs and Transmeta, and the Macintosh which just switched from 680x0 to PowerPC using emulation). Many people thought instruction sets would be irrelevant (Transmeta released several CPUs, all incompatible - no backwards compatibility barriers to newer, faster designs).
The idea is not dead though. Look up the Low Level Virtual Machine, or LLVM, which is used by Apple. One example is in the Macintosh OpenGL stack - rather than including a lot of branches to test for various settings, the LLVM optimiser basically strips out all those out when they don't change (or are handled by hardware), leaving behind simpler code for displaying windows and other graphics. Probably other things too, but that's all that's publicly announced. I suspect Apple is aiming for CPU independence eventually.
10 million people. 4 million of they may have been homosexuals, gypsies, mentally retarded, and other undesirables instead of Jews, but they were still people, and shouldn't be forgotten.
"Itanium" was originally HP's internal replacement for PA-RISC, to leapfrog the next generation of RISC processors in performance. The deal with Intel was intended to split development cost, so the competition couldn't keep up (HP already stopped making expensive fabs, hiring Intel to make PA-RISC). Management changes in both companies led to Itanium being handled by people who didn't understand the original strategy, or the technology, so it was "redesigned to death" until competitors caught up, and it was finally released.
It was a gamble by HP that static program analysis with simpler circuitry would be faster than dynamic analysis, in the same way that simpler RISC outperformed CISC, but it didn't pay off. It turns out that dynamic analysis became such a small percentage of the transistor count that it no longer mattered. RISC processors create their own VLIW instruction bundles (at least the last Alpha and later POWER did), and CISC processors can translate code on the fly internally with almost no speed penalty. I think even the most recent Itaniums ignore the static information and regroup dynamically for better performance.
Still, Itanium is among the top performers for number crunching, and if it had kept to its original plan, probably would have been a leader for at least a few years, which would have been great for HP. As it is, the main accomplishment was strategic - to convince most competitors to stop developing their high end CPUs (Alpha, MIPS).
When I saw this done on Max Headroom, I was skeptical that it could work. Not because a regular news camera had an "infra-red" mode, I expected that could happen (and some do, just not enough to be heat sensitive yet), but I thought the keys would cool down too fast. Good to know how scientifically accurate a show about a simulated human infecting the world's computer networks was.
One thing that Apple does is not waste time on "lower end" products. Every "stripped down" version of a product that companies typically make has engineering, marketing, logistical and other costs. Apple typically won't produce a produce that has any overlap - there is no "iPod Touch Lite" between the Touch and the Nano (say, missing a camera or WiFi or less functional apps... memory size aside - that's a legitimate consumer preference), because the Touch would do everything the "lite" version does (a Nano is physically different enough that it has different uses than a Touch), so why bother?
That means that rather than a dozen different screens or boards or cases for a dozen products, Apple needs one. That means it purchases a dozen times more of what it does buy, and that leads to economies of scale, allowing it to make these gambles successfully more often.
Like others have said, nobody stops any competitors from doing the same, but they haven't so far, for it is an immense gamble. Apple also could fail and buy out the full capacity of some widget that ends up in a landfill somewhere, but that hasn't happen so far either.
Look up the fate of the Apple "Twiggy" drives for old Lisa.
The most important thing that Apple (as a company) does is pay attention to detail at every level. Back when Jobs was in charge of the initial Macintosh, he even complained if the motherboard looked messy. Most companies will cover up shoddy work with a shiny case or flashy interface, cheaping out on everything not visible to the end customer. I saw an Apple Store in Chicago, it had a bus stop with one of those scrolling billboards. Every add on that scroll was an Apple ad.
Jobs has always been fanatic that everything must be done well, from the sweeping the floors to the design of the head office building. Apple is not unique in that, it's pretty typical of Japanese companies like Toyota or Sony, but Apple takes it a little further. When everything looks good from the inside out, mistakes really stand out.
The U.S has several health care systems operating in parallel:
At it's basic, the it's a fee for service business, with distortions from the side effects of various laws, regulations, and other systems. One distortion is that I think all states require that providing emergency services cannot be refused - treat first, demand payment later. A lot of uninsured people get treated this way, and if they're too poor to afford insurance, they're usually too poor to pay. This means a lot of money is wasted on debt collection, and a lot of fees just go unpaid. All prices in a hospital are jacked up to cover the losses - so an aspirin tablet in hospital costs $10.
The insurance system added on changes things. Insurance is usually too expensive for individuals, so it's almost always through employers. The main expense here is the hospitals and doctors trying to get payment. The insurance companies are adversarial, and try to avoid paying as much as possible. They will hire doctors to claim procedures are unnecessary (often as a rubber stamp to meet a quota of rejections), or reject forms for small technical mistakes, etc. Micheal Moore's movie focussed on this. The adversarial system is supposed to prevent unnecessary procedures, but the malpractice insurance industry pushes for more procedures. Meanwhile, insurance plans are far more complicated than needed, to give more opportunities for rejection. People in this system always experience problems, even when the actual health care that they receive is very good. The people with good (expensive) insurance plans are usually happy with it, largely because their company pays the costs, so they don't see any of it.
Certain categories of people have government payment acting as insurance. Poor, usually children, qualify for Medicaid, and seniors qualify for Medicare. This is basically the Canadian system as well, only not universal. Physicians can "opt out" like they can in Canada, but in Canada there are few payment alternatives, so in practice almost all doctors are part of Medicare. In the U.S, a lot of doctors don't accept Medicaid or Medicare patients.
Military personnel are covered by a hospital system operated by the government, through the military while serving, and through Veterans Affairs after. This is basically the same as the U.K's National Health System - government run from top to bottom. It actually works well, but suffers from gigantic bureaucracy typical of any large government organisation (just like the military itself, for that matter).
The reforms are meant to lower the cost of health care and insurance in two ways. First, usually people who don't need insurance (young people) don't get it, so those who do typically cost the insurance companies more, and they have to charge more for private plans. If everyone must have it, the costs should drop - this is the reason auto insurance is mandatory, and the result there. The other is to eliminate the non-payment problems of hospitals and doctors, so prices charged will be lower. Overall, this is the system used in Japan, and it works pretty well. It's not a quick fix though - quick fixes are really wanted these days. And ideological meddling and corporate corruption may prevent it from working at all - the U.S has a shortage of patience and reason when it comes to these things.
Most of those thugs are non-government party supporters - either hired, or part of typically criminal activities which support the governing party. Or, occasionally, popular supporters fed propaganda to incite them.
In other words, the money and orders are flowing to the government, not from it. The fact that it's government is incidental, and often irrelevant - see Somalia, where "government" means whatever local crime bosses are on top at the moment, these things also happen.
[...]
They are exploited by their OWN governments. Unless we have troops in their nation forcing them to give up their money and resources, then any "exploitation by 1st world governments" is second hand at most, and is carried out with the explicit consent of the local government.
All these people need is for their governments to recognize that their people ARE PEOPLE, and stop murdering and stealing from them, and stop them from murdering and stealing from each other.
For the most part, the governments there just leave the people alone - they don't have the resources to do much to them, outside of some large cities (which is where the oppression occurs in corrupt countries). And even within the cities, they can only concentrate on the most prominent.
Africa is an example of "government which governs least" - also should be an example to those anti-government types in the U.S, who want to move towards that system.
Once that is done, then their economy can begin to grow in a real, sustainable manner. People will recognize that they can get ahead by hard work and savings, rather than bullying those weaker than themselves. Once you see that fundamental change in the people, education will take off, and Africa will pull herself out of her death spiral.
There are politically stable, developing areas in Africa. Kenya isn't bad, Ghana and Botswana as well. The problems aren't as simple as "people just have to start working". First, there is culture - stupidly followed tradition gets in the way of a lot of reform. For example, often irrigation projects won't be done because men don't want to work on them - gathering water is women's work.
The long established human habitation means there are a huge number of conflicting cultures. Lack of a unifying culture or language means that almost all concerns people have are local - large scale co-operation is both difficult and suspicious. The same problem held back the Americas until they were "settled"/""conquered" (take your pick). Once a culture dominated wide areas (Spanish, English, Portuguese, French), large scale development followed.
There is a huge infrastructure deficit in Africa. Roads, power, rail, services, supply chains, all need to be developed to make actually getting resources from the source to where they're needed efficient. Part of this is from the cultural differences, but part is from other deficits.
Africa is underpopulated. You'd think with the stories of starvation that it had the opposite problem, but no, the population density is still below many developed places in the world. The average farmer produces only a fraction of what someone in Europe, North America, Japan, Australia or other developed nations does. Some of that is due to energy used for machinery and chemicals, but a lot is simply tradition / lack of knowledge of better practices, and lack of infrastructure to get resources (even just better seeds) to farmers. More people would mean more demand for infrastructure (as well as more and better organisation).
Other people's rules. An example, in early South Africa the mining companies couldn't hire workers - the people lived off the land and had no need for money. The government started levying taxes on the people, forcing them to join the "modern economy", an effect which split up families (the men had to travel days and live at the mines), reduced the amount of food grown and increased real (as opposed to "money based") poverty, lead to illness and death from working conditions - really it destroyed lives. Africa as a whole is being subjected to the same thing, as outsiders decide how the countries should run. This is possible due to some of the factors above, but it can't be ignored that capitalists are greedy (kind of by definition) and verge on psychopaths in their lack of concern for the damage they do.
That's a start on the problems facing Africa.
[...] Understand that any and all charitable aid only su
I'm still amazed that almost nobody seems to notice the fact that in Fahrenheit, there are 180 degrees between freezing and boiling (as in, degrees in a half circle, like a dial might use). Meaning Fahrenheit is based on the same physical constants as Celsius, not "human physical comfort" or similar misinformation.
The weirdness of Fahrenheit is that the 0 was moved from the freezing point of fresh water to salt (ocean) water, so now it no longer makes obvious sense.
Anyway, neither Fahrenheit nor Celsius make sense as SI units - temperature is a measure of thermal energy over density, neither converts directly to any SI (or imperial) units without a conversion constant (ignoring calories, you still need a constant to convert to joules).
If you're referring to the photoelectric effect, that has nothing to do with ionizing radiation, since metals don't "ionize" (in that way).
But rods and cones are affected by non-ionizing light. More generally, heat also affects tissues, so any non-radiation that is converted to heat (down to microwaves) affects tissue. Even lower on the spectrum, non-thermal low frequency radio waves beamed at certain brain tissues can affect thought, perception, mood and emotion.
What this research is referring to involves how dissolved molecules, which become ionized by interactions with water molecules breaking components apart, might be affected by electromagnetic fields. Since ions are positive or negative, a positive or negative electric field, or a changing magnetic field (as in an electromagnetic field), may physically influence the movement. It's completely possible that a constant electromagnetic field might jiggle those ions enough to prevent or reduce the chemical coupling that would normally occur in, say, bone growth. Even a very weak field, it it were a resonant frequency, could do that.
I didn't mean literally a DSP like you'd find in a CD player, Itanium was always intended to be a server chip. But features like no integer register multiply, in order to keep all integer instructions to a single cycle - integer values have to be moved to floating point registers for multiplication, then back.
I like a lot of the quirky features, especially the extensive use of flags to defer exceptions (like a missed load) allowing speculative operations to work safely before the condition is known. But it was all designed for "avoid unpredictability at all costs" like a DSP, rather than other CPUs designed to manage unpredictability using caches, buffers, multithreading, and so on. And as I said it was successful, but the strengths weren't as useful in the real world as I guess they expected, since the costs of things like memory access and interrupts just keeps rising, and since they can never be eliminated completely, at some point it needs to manage it anyway (remember the i860 had exactly the same problem). And now special hardware like GPUs are being applied to the problems now instead, so the advantage it does have is smaller.
Itanium was basically a DSP, making it fast. But DSPs are terrible for anything with branches, interrupts, traps, etc., so almost every interesting feature added to Itanium exists to compensate for the inherent weakness of a DSP design for non-DSP tasks. It worked out in the sense that it was still fast at DSP tasks while not being slower than regular CPUs at regular tasks, but the DSP style workload turned out to be not significant enough to justify that complexity. And recently GPUs or other hardware (PowerPC Cell extension, coprocessors, multi-core) are being used for that instead.
You're forgetting that Windows wasn't unique, it had competitors: OS/2, GEM, GEOS were the main ones. That was the competition, not Unix. Unix vendors made token efforts to support a GUI, but their efforts like Motif and CDE were a lot like lipstick on a pig.
Microsoft had a few strategies it used. Some could have been done by competitors, such as the major emphasis on developers with VisualStudio, VisualBasic, frameworks like OLE, and so on (there was no good equivalent for the others). Some essentially expanded Window's scope by supplying its own software with Word, Excel, etc. which were integrated into Office. Some involved less honest things, like hidden OS features for MS applications, or actively sabotaging competitors with OS releases (DR-DOS, for example). And a big part was back room deals, leveraging decision makers with money, promises, and threats, like the "per-CPU licensing" which charged a Windows license for every computer shipped, even if it had no Microsoft software on it, making it more expensive to include competing software (like OS/2) because they would have to pay twice. Also the intense fight to kill Apple's QuickTime codec, and the sales force targeting technology ignorant management of companies, taking technology decisions out of the hands of technology specialists.
The final strategy was more of an accidental one: Windows and other software was just so badly designed that it couldn't run on other CPUs. In fact, often it couldn't be made to run using the same CPU on better hardware. Do you remember the "640K limit"? Hardware that got rid of that limit was also incompatible with a lot of MS-DOS and Windows software and drivers - badness was actually required for Windows. With a situation like that, every application that was made Windows compatible became stuck, depending on it. Trying to make software portable was almost as bad as writing two completely different versions, so the first version was always for the bigger market. The race for new versions meant there was always a new version needed, so often no time to work on any other versions, so anything non-Windows just wasn't as good, or just didn't exist.
Hence the "Windows ecosystem" accumulated marketwise, while a very clever CEO leveraged every strategy businesswise, and drove out all competitors - while at the same time requiring Intel x86 compatibility, purely as a side effect.
Since the instruction format hasn't changed (still using 6 instruction bundles), I think Poulson is just ignoring the packing info and being superscalar just like every other high performance chip (Alpha EV6 or EV7 (can't remember) and Power 4 grouped instructions internally, rather than flinging them independently through the execution units - simplified tracking, apparently). Actually I think even the previous version of Itanium gave up on that - runtime data lets you group independent instructions more efficiently anyway, so many people thought it was a waste of time to try to get the compiler to do it when Itanium was introduced. Remember, it was not the first, but the last of a long history of attempts at making VLIW not suck (er. except Transmeta, which doesn't count because it hid the native instructions - essentially it put the instruction grouping into software rather than hardware, and that was never fast enough to work well).
Still, recompiling could make runtime grouping better, so you'd get more speedups if you did. But even existing binaries should benefit.
As I understand it, the Holy Trinity is kind of like that optical illusion which sometimes looks like a vase, and sometimes like two people looking at each other. The picture doesn't change, but your perception does depending on how you look at it - when you look for people, you see people. The Trinity is three perspectives, not two, but it's the same idea - you look for God, you see things as aspects of God, look for Jesus, you see the same things as aspects of Jesus, and so on for the Holy Spirit.
Slashdot Mirror
I described above the idea of including a DNS hostname in a normal host string. I like that because it only needs client library changes, DNS can stay the same, and those setting up alternative DNS hosts only need to include a few censored names, not the entire DNS database. If I had a few days, I'd whip a demo up myself, but that's not going to happen for a while.
I haven't had time to try this, but there's no reason not to include a DNS host in the hostname, to use as a resolver. An example to explain, imagine "oppressed-group.org" is blocked, but "freeworld.net" hosts a DNS with a list of blocked domain names (just some, doesn't have to be the entire DNS database), you could specify "oppressed-group.org(freeworld.net)" (or give the IP address of the DNS server). It could be chained with as many additional DNS servers as it takes (as in "host(dns2)(dns1)").
In the end, the servers see everything normally, the root DNS and other servers are unchanged, the only change is in the client code that does the lookup.
Alternative syntax could go in the other direction, using "/" or "!" (bring back bang paths!), looking like "freeworld.net!oppressed-group.org".
The "Kentucky Fried Movie" 'Fistful of Yen' parody of "Enter the Dragon" featured guards named: Hung Well, Long Wang, and Enormous Genitals.
IBM generally sells business solutions and technology - the latter sometimes as patent licenses, sometimes developing products and selling them off. For example, the popular "swiping" method of keyboard entry on smartphones came from ""ShapeWriter" (previously SHARK), an IBM product they sold to another company to commercialise.
I'm sure there are a lot of assets in WebOS that could be developed. For example, what if you go a step beyond Apple's Siri, and integrate a smartphone interface with the deep AI of IBM's Watson Jeopardy champion (currently being commercialised for optimising medical treatment in the health insurance industry)? Sell or license that product to application developers for everything from intelligent tourist guides to on site first aid agents, who sell their wares on Android, iTunes, Blackberry or Microsoft app stores.
Lots of possibilities for a firm with cutting edge research and development. Like HP used to be, once.
Sun had out of order SPARCs for years, contrary to the article's claims. Sun had a two pronged strategy, one aimed at single thread performance (the UltraSPARC series), the other at multithreaded performance (the T series). The UltraSPARCs were never really that good, so were eventually dropped in favour of the Fujitsu SPARC64 series, and the replacement (code named "rock") was dropped by Oracle because progress seemed stalled forever, but they did indeed have out of order execution, register renaming, and "Rock" had a promising "pre-execution" thread that was supposed to alert cache controllers ahead of time to pre-fetch data that can't be statically predicted, dropping cache misses to near zero.
The purpose of the multithreaded processor was to support mainly I/O bound tasks, and lots of them - web servers are like this, though more in the past where web content was more static. In those systems, a T series SPARC system noticeably outperformed similarly priced competition (with similar reliability - you could get a lot cheaper if you didn't care about component quality).
The single threading improvements in the T series are being added because even I/O bound systems often have compute-bound tasks. In particular, the T4 lets you assign one high priority thread which gets to hog CPU resources, in addition to out of order execution and other techniques that all threads benefit from, so I/O bound threads don't get hung up waiting for a single CPU-bound task to finish.
I suspect a lot of people don't think about that expression "Can't see the forest because of all the trees in the way". But that seems to be life for the vast majority of people. When it comes down to it, the way almost everything works is wrong, somehow. But it's like a local minimum, almost nobody seems to look past a few small tweaks and adjustments to see the global minimum.
Related, but separate, something that bothers me about most technically minded developers or engineers trying to design things - almost all of them never bother finishing the race. When designing the interface for something, they will develop it until it's possible to accomplish a task, but usually no further. A classic example is digital clocks - how to adjust the time on them. Even now, the interface for most sucks into the negative digits, but the earlier ones were painfully stupid: Hold the "time" button, then either the "fast" or "slow" as the clock advances - past the time you want to set. Repeat this for another 12 or 24 hour cycle and miss again. Repeat until frustrated. Newsflash designers, you can add buttons to go backwards! Yes, you need to redesign the chip to subtract, but you only do that once. Millions of people have to set the time over and over.
And why doesn't every clock just have a "DST ON/OFF" switch? Is that really so impossible?
I see this over and over again, from things like Java libraries, Unix networking, Windows (classic press "start" to stop the computer - and why are there seven options, any why should I care which does what?), the damn "smart" photocopier (I needed to copy a slip of paper onto a page, the copier rotated it and cut off the bottom. I rotated the slip to match the new orientation, the copier rotated it and again cut off the bottom. Should I try diagonal?) - it's like technical types go as far enough to see the finish line, and say "theoretically we can finish the race, so let's just stop here".
This is the thing that separates a genuinely innovative product from others, actually getting to the destination. GUI word processors let you see the format, rather than imagine how special codes would make it look like eventually. iPods couldn't do as much as the competition, but the competition only made it possible to do more, iPods were easier to do more. Nintendo Wii games didn't require reading an instruction manual. A Roomba vacuum just had to be plugged in and turned on.
The common aspect of these things is designing for the end use, not the implementation. It's more work, but it's work that has to be done only once. The end user that has to figure out what they hell you were thinking has to do this every single time (until they get used to, say, a list of keystrokes or menu choices written on a post-it that they don't understand). If the user has to enter an email address, help out - have a separate username and host fields, with a "@" label between them, rather than trying to parse it for validity after it's entered and just saying "keep trying until you get the format right". Basically, anywhere there are user instructions that give a list of steps to perform, make the computer do them - computers are better at following instructions!
This, fundamentally, is why almost all smart phones sucked before the iPhone - every possible operation needed a magic invocation of actions (or a long menu path) to start that you had to memorize to use them. Apple designers (not one single person, but an entire design team) broke down what was needed and got rid of all exposed implementation, and put the effort into making it just work. I have no idea how complex the technology is that measures where I tap on an iPod keyboard and guesses which of the four keys my finger overlaps is the one I'm trying to press, but it gets it right so I don't care - it should just work, and it does, so I'm happy.
When it comes down to it, whether it's a dictatorship or not isn't important. But without some strong insistence on finishing the job, most technical developers won't bother. And even then, they can come up with some amazingly hair-brained designs (search for design failures/hall of shame sites). A dictatorship is a way to avoid them, at least.
[...] since the compilers necessary to perform the required dynamic analysis would have to cover just about every possible scenario
Just to clarify, it's not the compilers (though those are important too), it's the runtime which does the optimisation. The problem is the overhead required. The end result may crunch numbers faster in the end, but it may slow down unexpectedly after the execution has been profiled long enough to get data indicating a hot spot, and the optimiser kicks in. It's a little like the problem that garbage collection has - in the end, GC is faster than manual memory management (with few exceptions), but program freezes when it kicks in are annoying.
Multiple cores help - the optimiser can work in the background, with no slowdown and only imperceptible pauses when the binary blocks are replaced. But it's still a trade-off because you might have a better use for that second core.
Anyway, dynamic optimisation optimises how the program actually executes, it doesn't have to predict anything. The main advantages are that it can optimise in ways hardware can't (e.g. remove dead code entirely), and it can be updated with a software upgrade.
Oh, by CPU independence, I meant that the same code can be run without caring what it runs on, like Java. Previously Apple and NeXT simply included binaries for more than one CPU, but LLVM has the potential to perform the final compile step either at installation or runtime, as well as dynamic optimisation while running.
In case you're still reading this thread...
For compatibility, I think they had an emulator to run PA-RISC programs on Itanium. One of the incentives for starting an incompatible design was a project called Dynamo, which was like a Java JIT interpreter which analyses a program as it's running, and can optimise the most used parts. One surprise was that they could speed up a program by translating from PA-RISC to PA-RISC - the runtime optimisations in software were better than hardware (at the time).
A similar strategy was followed by Transmeta, interpreting 80x86 programs on custom VLIW CPUs. It failed partly due to Intel manipulation (basically giving a much better price to customers who never use a competing product), but partly from inconsistent performance - that matters less on a server, but more on a laptop, which was Transmeta's focus. Java is used mostly on servers, so the JIT and optimisation works well there.
I think continuing PA-RISC could have matched Itanium performance (if Itanium had not been delayed) eventually, but at the time it wasn't a sure thing. The real question was whether to put the dynamic optimisation in software or hardware, and a number of research projects hinted that software might be capable of far more than hardware (in addition to HP Dynamo, IBM's DAISY project did much the same thing, as well as Java JITs and Transmeta, and the Macintosh which just switched from 680x0 to PowerPC using emulation). Many people thought instruction sets would be irrelevant (Transmeta released several CPUs, all incompatible - no backwards compatibility barriers to newer, faster designs).
The idea is not dead though. Look up the Low Level Virtual Machine, or LLVM, which is used by Apple. One example is in the Macintosh OpenGL stack - rather than including a lot of branches to test for various settings, the LLVM optimiser basically strips out all those out when they don't change (or are handled by hardware), leaving behind simpler code for displaying windows and other graphics. Probably other things too, but that's all that's publicly announced. I suspect Apple is aiming for CPU independence eventually.
10 million people. 4 million of they may have been homosexuals, gypsies, mentally retarded, and other undesirables instead of Jews, but they were still people, and shouldn't be forgotten.
"Itanium" was originally HP's internal replacement for PA-RISC, to leapfrog the next generation of RISC processors in performance. The deal with Intel was intended to split development cost, so the competition couldn't keep up (HP already stopped making expensive fabs, hiring Intel to make PA-RISC). Management changes in both companies led to Itanium being handled by people who didn't understand the original strategy, or the technology, so it was "redesigned to death" until competitors caught up, and it was finally released.
It was a gamble by HP that static program analysis with simpler circuitry would be faster than dynamic analysis, in the same way that simpler RISC outperformed CISC, but it didn't pay off. It turns out that dynamic analysis became such a small percentage of the transistor count that it no longer mattered. RISC processors create their own VLIW instruction bundles (at least the last Alpha and later POWER did), and CISC processors can translate code on the fly internally with almost no speed penalty. I think even the most recent Itaniums ignore the static information and regroup dynamically for better performance.
Still, Itanium is among the top performers for number crunching, and if it had kept to its original plan, probably would have been a leader for at least a few years, which would have been great for HP. As it is, the main accomplishment was strategic - to convince most competitors to stop developing their high end CPUs (Alpha, MIPS).
When I saw this done on Max Headroom, I was skeptical that it could work. Not because a regular news camera had an "infra-red" mode, I expected that could happen (and some do, just not enough to be heat sensitive yet), but I thought the keys would cool down too fast. Good to know how scientifically accurate a show about a simulated human infecting the world's computer networks was.
One thing that Apple does is not waste time on "lower end" products. Every "stripped down" version of a product that companies typically make has engineering, marketing, logistical and other costs. Apple typically won't produce a produce that has any overlap - there is no "iPod Touch Lite" between the Touch and the Nano (say, missing a camera or WiFi or less functional apps... memory size aside - that's a legitimate consumer preference), because the Touch would do everything the "lite" version does (a Nano is physically different enough that it has different uses than a Touch), so why bother?
That means that rather than a dozen different screens or boards or cases for a dozen products, Apple needs one. That means it purchases a dozen times more of what it does buy, and that leads to economies of scale, allowing it to make these gambles successfully more often.
Like others have said, nobody stops any competitors from doing the same, but they haven't so far, for it is an immense gamble. Apple also could fail and buy out the full capacity of some widget that ends up in a landfill somewhere, but that hasn't happen so far either.
Look up the fate of the Apple "Twiggy" drives for old Lisa.
The most important thing that Apple (as a company) does is pay attention to detail at every level. Back when Jobs was in charge of the initial Macintosh, he even complained if the motherboard looked messy. Most companies will cover up shoddy work with a shiny case or flashy interface, cheaping out on everything not visible to the end customer. I saw an Apple Store in Chicago, it had a bus stop with one of those scrolling billboards. Every add on that scroll was an Apple ad.
Jobs has always been fanatic that everything must be done well, from the sweeping the floors to the design of the head office building. Apple is not unique in that, it's pretty typical of Japanese companies like Toyota or Sony, but Apple takes it a little further. When everything looks good from the inside out, mistakes really stand out.
The U.S has several health care systems operating in parallel:
The reforms are meant to lower the cost of health care and insurance in two ways. First, usually people who don't need insurance (young people) don't get it, so those who do typically cost the insurance companies more, and they have to charge more for private plans. If everyone must have it, the costs should drop - this is the reason auto insurance is mandatory, and the result there. The other is to eliminate the non-payment problems of hospitals and doctors, so prices charged will be lower. Overall, this is the system used in Japan, and it works pretty well. It's not a quick fix though - quick fixes are really wanted these days. And ideological meddling and corporate corruption may prevent it from working at all - the U.S has a shortage of patience and reason when it comes to these things.
Most of those thugs are non-government party supporters - either hired, or part of typically criminal activities which support the governing party. Or, occasionally, popular supporters fed propaganda to incite them.
In other words, the money and orders are flowing to the government, not from it. The fact that it's government is incidental, and often irrelevant - see Somalia, where "government" means whatever local crime bosses are on top at the moment, these things also happen.
[...] They are exploited by their OWN governments. Unless we have troops in their nation forcing them to give up their money and resources, then any "exploitation by 1st world governments" is second hand at most, and is carried out with the explicit consent of the local government. All these people need is for their governments to recognize that their people ARE PEOPLE, and stop murdering and stealing from them, and stop them from murdering and stealing from each other.
For the most part, the governments there just leave the people alone - they don't have the resources to do much to them, outside of some large cities (which is where the oppression occurs in corrupt countries). And even within the cities, they can only concentrate on the most prominent.
Africa is an example of "government which governs least" - also should be an example to those anti-government types in the U.S, who want to move towards that system.
Once that is done, then their economy can begin to grow in a real, sustainable manner. People will recognize that they can get ahead by hard work and savings, rather than bullying those weaker than themselves. Once you see that fundamental change in the people, education will take off, and Africa will pull herself out of her death spiral.
There are politically stable, developing areas in Africa. Kenya isn't bad, Ghana and Botswana as well. The problems aren't as simple as "people just have to start working". First, there is culture - stupidly followed tradition gets in the way of a lot of reform. For example, often irrigation projects won't be done because men don't want to work on them - gathering water is women's work.
The long established human habitation means there are a huge number of conflicting cultures. Lack of a unifying culture or language means that almost all concerns people have are local - large scale co-operation is both difficult and suspicious. The same problem held back the Americas until they were "settled"/""conquered" (take your pick). Once a culture dominated wide areas (Spanish, English, Portuguese, French), large scale development followed.
There is a huge infrastructure deficit in Africa. Roads, power, rail, services, supply chains, all need to be developed to make actually getting resources from the source to where they're needed efficient. Part of this is from the cultural differences, but part is from other deficits.
Africa is underpopulated. You'd think with the stories of starvation that it had the opposite problem, but no, the population density is still below many developed places in the world. The average farmer produces only a fraction of what someone in Europe, North America, Japan, Australia or other developed nations does. Some of that is due to energy used for machinery and chemicals, but a lot is simply tradition / lack of knowledge of better practices, and lack of infrastructure to get resources (even just better seeds) to farmers. More people would mean more demand for infrastructure (as well as more and better organisation).
Other people's rules. An example, in early South Africa the mining companies couldn't hire workers - the people lived off the land and had no need for money. The government started levying taxes on the people, forcing them to join the "modern economy", an effect which split up families (the men had to travel days and live at the mines), reduced the amount of food grown and increased real (as opposed to "money based") poverty, lead to illness and death from working conditions - really it destroyed lives. Africa as a whole is being subjected to the same thing, as outsiders decide how the countries should run. This is possible due to some of the factors above, but it can't be ignored that capitalists are greedy (kind of by definition) and verge on psychopaths in their lack of concern for the damage they do.
That's a start on the problems facing Africa.
[...] Understand that any and all charitable aid only su
Spoken like someone without a clue. There is fundamentally absolutely nothing in x86 that would cause it to consume more power than ARM.
One something: the instruction decoder in x86 is more complex. Another: The overhead of supporting byte-aligned instructions and data access.
There are many more somethings, but I only needed one to prove you wrong (and that between you two, mellon is not the clueless one).
I'm replying to this because I'm out of mod points, and it's a legitimate point made here.
I'm still amazed that almost nobody seems to notice the fact that in Fahrenheit, there are 180 degrees between freezing and boiling (as in, degrees in a half circle, like a dial might use). Meaning Fahrenheit is based on the same physical constants as Celsius, not "human physical comfort" or similar misinformation.
The weirdness of Fahrenheit is that the 0 was moved from the freezing point of fresh water to salt (ocean) water, so now it no longer makes obvious sense.
Anyway, neither Fahrenheit nor Celsius make sense as SI units - temperature is a measure of thermal energy over density, neither converts directly to any SI (or imperial) units without a conversion constant (ignoring calories, you still need a constant to convert to joules).
If you're referring to the photoelectric effect, that has nothing to do with ionizing radiation, since metals don't "ionize" (in that way).
But rods and cones are affected by non-ionizing light. More generally, heat also affects tissues, so any non-radiation that is converted to heat (down to microwaves) affects tissue. Even lower on the spectrum, non-thermal low frequency radio waves beamed at certain brain tissues can affect thought, perception, mood and emotion.
What this research is referring to involves how dissolved molecules, which become ionized by interactions with water molecules breaking components apart, might be affected by electromagnetic fields. Since ions are positive or negative, a positive or negative electric field, or a changing magnetic field (as in an electromagnetic field), may physically influence the movement. It's completely possible that a constant electromagnetic field might jiggle those ions enough to prevent or reduce the chemical coupling that would normally occur in, say, bone growth. Even a very weak field, it it were a resonant frequency, could do that.
I didn't mean literally a DSP like you'd find in a CD player, Itanium was always intended to be a server chip. But features like no integer register multiply, in order to keep all integer instructions to a single cycle - integer values have to be moved to floating point registers for multiplication, then back.
I like a lot of the quirky features, especially the extensive use of flags to defer exceptions (like a missed load) allowing speculative operations to work safely before the condition is known. But it was all designed for "avoid unpredictability at all costs" like a DSP, rather than other CPUs designed to manage unpredictability using caches, buffers, multithreading, and so on. And as I said it was successful, but the strengths weren't as useful in the real world as I guess they expected, since the costs of things like memory access and interrupts just keeps rising, and since they can never be eliminated completely, at some point it needs to manage it anyway (remember the i860 had exactly the same problem). And now special hardware like GPUs are being applied to the problems now instead, so the advantage it does have is smaller.
Itanium was basically a DSP, making it fast. But DSPs are terrible for anything with branches, interrupts, traps, etc., so almost every interesting feature added to Itanium exists to compensate for the inherent weakness of a DSP design for non-DSP tasks. It worked out in the sense that it was still fast at DSP tasks while not being slower than regular CPUs at regular tasks, but the DSP style workload turned out to be not significant enough to justify that complexity. And recently GPUs or other hardware (PowerPC Cell extension, coprocessors, multi-core) are being used for that instead.
You're forgetting that Windows wasn't unique, it had competitors: OS/2, GEM, GEOS were the main ones. That was the competition, not Unix. Unix vendors made token efforts to support a GUI, but their efforts like Motif and CDE were a lot like lipstick on a pig.
Microsoft had a few strategies it used. Some could have been done by competitors, such as the major emphasis on developers with VisualStudio, VisualBasic, frameworks like OLE, and so on (there was no good equivalent for the others). Some essentially expanded Window's scope by supplying its own software with Word, Excel, etc. which were integrated into Office. Some involved less honest things, like hidden OS features for MS applications, or actively sabotaging competitors with OS releases (DR-DOS, for example). And a big part was back room deals, leveraging decision makers with money, promises, and threats, like the "per-CPU licensing" which charged a Windows license for every computer shipped, even if it had no Microsoft software on it, making it more expensive to include competing software (like OS/2) because they would have to pay twice. Also the intense fight to kill Apple's QuickTime codec, and the sales force targeting technology ignorant management of companies, taking technology decisions out of the hands of technology specialists.
The final strategy was more of an accidental one: Windows and other software was just so badly designed that it couldn't run on other CPUs. In fact, often it couldn't be made to run using the same CPU on better hardware. Do you remember the "640K limit"? Hardware that got rid of that limit was also incompatible with a lot of MS-DOS and Windows software and drivers - badness was actually required for Windows. With a situation like that, every application that was made Windows compatible became stuck, depending on it. Trying to make software portable was almost as bad as writing two completely different versions, so the first version was always for the bigger market. The race for new versions meant there was always a new version needed, so often no time to work on any other versions, so anything non-Windows just wasn't as good, or just didn't exist.
Hence the "Windows ecosystem" accumulated marketwise, while a very clever CEO leveraged every strategy businesswise, and drove out all competitors - while at the same time requiring Intel x86 compatibility, purely as a side effect.
Since the instruction format hasn't changed (still using 6 instruction bundles), I think Poulson is just ignoring the packing info and being superscalar just like every other high performance chip (Alpha EV6 or EV7 (can't remember) and Power 4 grouped instructions internally, rather than flinging them independently through the execution units - simplified tracking, apparently). Actually I think even the previous version of Itanium gave up on that - runtime data lets you group independent instructions more efficiently anyway, so many people thought it was a waste of time to try to get the compiler to do it when Itanium was introduced. Remember, it was not the first, but the last of a long history of attempts at making VLIW not suck (er. except Transmeta, which doesn't count because it hid the native instructions - essentially it put the instruction grouping into software rather than hardware, and that was never fast enough to work well).
Still, recompiling could make runtime grouping better, so you'd get more speedups if you did. But even existing binaries should benefit.
As I understand it, the Holy Trinity is kind of like that optical illusion which sometimes looks like a vase, and sometimes like two people looking at each other. The picture doesn't change, but your perception does depending on how you look at it - when you look for people, you see people. The Trinity is three perspectives, not two, but it's the same idea - you look for God, you see things as aspects of God, look for Jesus, you see the same things as aspects of Jesus, and so on for the Holy Spirit.
Details are left as an exercise for the deity.