Salon would need to be subsidized
on
Salon Asks for Help
·
· Score: 2, Insightful
Alot of ideological publications cannot make it on their own. "The Nation" has never made money. "National Review" (on the right) is supported by WFB's family wealth. NPR takes government subsidies and still tirelessly presses is subscribers for more money!
There are only two kinds of media that can independently survive in America:
1. Mass-market outlets that take a "least common denominator" approach to content, trying to appeal to a wide array of people (Fox, Rush Limbaugh, Newsweek, US News, etc).
2. Outlets which have very high-quality content (Harper's, Granta, etc), for which a few people will pay a significant amount of money.
Salon is neither of these. To survive, it will require a subsidy, just like "National Review" and "The Nation."
Salon's biggest difficulty is the mediocre quality of its content. Salon tries to be an educated, urban, lefty magazine, but it doesn't quite make it. There are other magazines in the same space: The New Yorker, Atlantic Monthly, Mother Jones, Harper's, and so on. Can anyone seriously pretend that Salon's content is the same quality as, say, the Atlantic Monthly? When I saw that Salon wanted ~$30 to subscribe, I thought to myself: "I don't want to read their articles that badly." And I like leftist opinion journals.
Although I think your initial assesment of line printers was exaggerated, I'm glad to see that you have some basis for what you said.
Obviosuly, cheapo inkjets are not going to replace line printers for high-volume business. However, line printers are still being replaced, by high-volume laser printers. If I recall, a good line printer pumps out 15-20 pages per minute. For the same initial investment, you could get a laser printer that does 30+ ppm. Some volume lasers now get 80+ ppm. Toner lasts longer than inkjet cartridges or line printer ribbons, and produces output superior to line printers.
"[Bios is] necessary for embedded systems, and it's necessary to boot your machine. Your computer isn't just going to magically start your hard drive. And, considering all that legacy stuff is down pat and is _never_ changed, we're talking about 256k of extra EEPROM."
BIOS refers to a series of bootstrap sequences and assembly routines that came on ROM with the original IBM PC, and that served as a basis for the DOS operating system. As such, BIOS is not the same as firmware or ROM. And BIOS is not needed to boot a computer -- any kind of firmware will do. Apples and Suns boot just fine without BIOS.
BIOS is extremely outdated. Most of the assembly routines contained by the BIOS are totally useless to a modern operating system. So, most BIOS routines are never used nowadays. Furthermore, many desirable things are not included in the BIOS, for example, the ability to partition and format disks, examine memory contents, and so on.
"And, just like replacing a line printer with an inkjet printer, it's a much slower, lower quality, harder to read, and more expensive way to do exactly the same thing."
It would be difficult to imagine a comment more totally wrong than this one. Line printers costed thousands of dollars, had crappy output, and were often the size of a refrigerator. Inkjets are tiny, often cost under $50, have far better print quality, and can print pretty color pictures.
I understand that some people find it soothing to say: "things were better in the good old days." But with printers, computers, and firmware? The point of view is so ludicrous that it hurts. Computers and printers have not been declining in capability (see the Moore's Law article).
There is no good reason to retain the BIOS. The BIOS is not and elegant, refined mechanism. It was a hack 20 years ago and now it's around for legacy reasons only.
"Well, another slashdotter w/o any idea what he/she is talking about."
I not only know what I'm talking about, I'm also capable of composing a reasoned message, unlike you.
"1st) SUN doesn't make the CPU's, they specify the design... but the implementation is left to 3th party suppliers. Just like MIPS. But of course you already knew that, not!"
Oh, really? My, you're knowledgeable. Dude, everyone knows that Sun is fabless, and that they've always been fabless, and that Texas Instruments is their current foundry and manufactures their chips.
It's obvious that TI doesn't care about Sun, otherwise US-III wouldn't have been relegated to a manufacturing process that is almost two generations behind that which Intel & IBM are using.
However, Sun's US-III suffers from architectural and design shortcomings that are entirely apart from the outdated manufacturing techniques TI allots them. The design of the US-III is inferior to that of Sun's competitors in extremely important ways. For example, the US-III is the only major RISC CPU that still doesn't have dynamic instruction scheduling! In other words, the US-III is an IN-ORDER cpu. Out-of-order execution was a major architectural innovation that leads to performance improvements of 40-50% on commercial workloads. US-III is the only major chip that doesn't have it. Even MIPS (R10k) does OOO. This is a large part of the reason that the US-III trails its competitors so badly. Another reason is: the US-III has a 14-stage pipeline, which is exceptionally long for a CPU that doesn't even have to dynamically select instructions to execute. To say nothing of the slow clock speed despite long pipeline lenghts.
"2nd) on a per MHZ basis the US III is more efficient that any intel P4, i.e. it gets more done per clock cycle"
Anything is faster than an intel p4 at the same clock speed, even an intel p3. This is because the p4 has a design that increases the clock speed while decreasing the instructions per clock. It's irrelevant that the US-III gets (slightly) more done per clock, because the p4 has more than three times the number of clock cycles. Unless the US-III gets more than three times more done per clock, it will trail the low-end, cheap commodity part (x86) in performance.
At present, the top offering from Sun (US-III 1.05GHz) gets less than half the SpecINT performance of the top commodity Intel offering (p4 3GHz), and less than half the SpecINT performance of other high-end MPUs like POWER4. We would have a better idea of how US-III performed on commercial workloads if we were able to inspect the standard tpc-c benchmarks for Sun platforms. However Sun withdrew from those benchmarks, out of embarrassment, when their performnace began to seriously trail that of their competitors.
"And of course you had to top it all by giving financial advice. My guess is that the less you know the more you have to speak...."
"This is not true. The top end commercial systems suppliers all run within 90% of each other when comparing apples to apples. 50% less is a notion you pulled out of the sky."
That's completely untrue. Sun withdrew from the recognized transaction processing bencharks (tpc) when their performance started to fall seriously behind. I've witnessed the performance of database applications that I architected, on Sun's high-end servers, versus the high-end servers of other vendors. Sun's performance was ABSOLUTELY NOT within 90% of their competition. The major industry benchmarks (tpc-c) amply demonstrated this fact, before Sun withdrew from them out of embarrassment.
Sun's UltraSparc-III is still an in-order processor; they've never been able to implement out-of-order instruction scheduling. This architectural feature alone is responsible for a 30-40% improvement on commercial workloads. This is not "primarily for scientific computing" as you contend, since the primary benefit of OOO is Integer/commercial workloads. ALL of the other RISC vendors have implemented OOO, even MIPS.
Not to mention, the US-III has a 14-stage pipeline, which is rather long considering that they don't even have to dynamically select instructions to execute. And, the US-III is only a 5-issue core!
"Oh, and please do have a visit to Sparc Consortium [sparc.com] and check out the many other who contribute to sparc development."
I've visited the Sparc consortium website many times in the past. The members of the Sparc consortium specify the instruction set architecture for Sparc; they have nothing whatsoever to do with Sun's CPU core designs, or with the UltraSparc-III that I mentioned was deficient. As such, your point is irrelevant to the current conversation.
"Oh, and please do" have a look at Paul DeMone's insightful article regarding Sun CPUs, at www.realworldtech.com:
"The immediate future aside, Sun is faced with a long term MPU credibility problem... The more SPARC performance lags behind openly available merchant processor families like x86, x86-64, and IA64, the greater this pressure becomes."
Sun's CPU offering is simply not competitive. On commercial workloads it gets apprxomiately half the performance of its peers. This is for two reasons: 1) the design is bad, leading to lower performance at a given clock speed, and 2) the manufacturing process is very old, leading to low clock speeds. (double whammy).
It would be very difficult for Sun to sell competitive boxes when their CPUs are half-speed. How are they going to sell an 8-way box for the same price as a 4-way commodity Xeon 3GHz?
What Sun has to do is: GET THE HELL OUT of making CPUs. It costs them tons of money, and they can't do it well, and the failure is crippling them. Everyone likes Solaris; everyone likes Sun's reliability features; everyone HATES Sparc's performance.
My advice to Sun? PARTNER WITH FUJITSU!! Fujitsu currently makes a Sparc chip that's almost twice the speed of Sun's! Sun should just drop their own CPU development and buy Sparc CPUs from Fujitsu. This would save Sun the $400M they currently spend on CPU development, drastically lowering their prices, and would double their performance. Seems like a no-brainer to me.
The old Star Trek was good enough that it created brand-name recognition. It created a certain faith that the next Star Trek installment would be good. The movie producers understood this brand-name recognition, and figured that trekkies would go see anything with Star Trek on the label, which was true. So the content creators released a slew of shitty Star Trek movies and TV series. They abused, and eventually destroyed, the Star Trek brand. When I heard about this movie, I assumed it would be terrible, prior to reading any reviews about it.
The same thing is happening with Star Wars. There was huge brand-name recognition. But now there's been two shitty movies in a row; the faith is teetering and about to collapse. Star Wars cannot withstand another shitty movie, or nobody will see the subsequent one.
"When the CPU does go to RAM for the data, i bet that a 3GHz P4 waits idle for about twice as many cycles as a 1.5GHz Itanium (given same-speed memory systems). "...NOTHING to do with P4 architecture", right?"
The P4 waits idle for twice as many cycles because it HAS twice as many cycles. The clock rate of the processor is not what's important here. Latency to non-cached RAM has NOTHING to do with p4 architecture.
"Read the article, and you'll notice that HT gave a far larger benefit with the designed-specifically-for-HT kernel. You got a better 4-word summary of this than "HT requires OS support"?"
Yes I have a better brief summary. You said that HT "requires" OS support. That is not just an exaggeration; it is false. If true, this would mean that HT would not work at all unless the OS were specifically written to take advantage of it. An accurate summary would read: "HT benefits from optimizations designed to exploit it."
"Summary: you can nit-pick okay, but i don't think you understand the technology or get the point of a short summary."
I understand the technology quite well, and I certainly understand the point of an accurate summary, which yours was not.
SMT (hyperthreading) will become increasingly important when processors are able to execute more than 2 threads simultaneously.
This development is inevitable. Previously, each new processor generation was faster than the prior one at a given clock rate, because each new processor core had more execution units, and was therefore able to perform more work in parallel. This trend abruptly ended recently, for one reason: there is no more instruction-level parallelism (ILP) to exploit. It is impossible for a processor to look at a thead of execution and find more than a few instructions to execute in parallel.
The only parallelism left to exploit is THREAD-LEVEL parallelism (TLP). Therefore the only way to continually increase performance is to increase the number of threads that a CPU can execute in parallel. This requires two modifications to CPU cores: first, increase the number of thread contexts per CPU, and second, increase the number of pipelines to which those threads can be dispatched.
With the P4, it would be pointless to have more than 2 thread contexts, because there aren't enough CPU resources lying idle to execute more than 2 threads. But future CPUs could make use of more than 2 thread contexts by having enough CPU resources to execute all of them. Future CPUs could have 20 execution units or more, which would be enough to execute several threads. Remember that the number of transistors per CPU continues to increase exponentially.
It's easy to forsee a time when processors have 20 execution units (10 integer, 10 fp) and 4 thread contexts, offering more than triple the performance of a non-SMT cpu. In the future, non-SMT CPUs will make as little sense as a non-superscalar CPU would today.
One of the major impediments to increasing CPU performance has been increasing memory latency. Memory latency has grown worse as CPUs have gotten faster. Accessing RAM will now cause a >150 cycle latency, during which the processor sits IDLE.
Cache only partly mitigates this problem. Some applications, such as databases and OLTP, are heavily dependent on repeatedly accessing non-cached RAM. There is no way to cache all the relevant data, since virtually all databases are larger than can fit in any present cache, no matter how large, and there is sometimes no way to predict which data will be accessed. ALL of these applications have CPUs that spend much of their time being IDLE, waiting for memory to be returned.
SMT (hyperthreading) allows the processor to perform useful work during these otherwise idle periods, by allowing the cpu to switch to a thread that is not blocked on memory access. The "idle bubbles" in the execution pipeline can therefore be "filled in" by useful work that advances the state of relevant programs.
SMT can cause a degredation in performance beceause it can lead to "cache thrashing." In an SMT-naive kernel, two unrelated threads could be scheduled for the same physical CPU. These unrelated threads will likely share very little code or data. The two threads will therefore "compete" for the single shared cache, with each thread's data being repeatedly displaced by the other's.
This difficulty can be substantially mitigated by making the kernel aware of "virtual processors," and by implementing scheduleing algorithms to minimize the impact. The performance of hyperthreading will likely improve as kernels are better able to exploit it.
Take the example of database & OLTP applications. Database transactions are heavily dependent on repeated access to RAM. Virtually no database is small enough to fit into cache, and there is often little regularity in which data is accessed. Memory latency will REQUIRE a non-SMT processor to wait IDLY each time there is a memory latency, which takes >100 proc cycles on a modern CPU. This has NOTHING to do with he p4 architecture or long pipelines.
"But remember that HT requires OS support, may require application support..."
HT does not require OS support as long as the OS is capable of recognizing more than 1 CPU. Any threaded app can benefit from HT.
The author misunderstands Moore's law
on
Moore's Law Disputed
·
· Score: 3, Interesting
The author of the article seems to misunderstand completely the intent of Moore's law. The article notes a few things:
1. Increases in transistor count do not precisely follow an exact, continuous, exponential mathematical function. Some years it grows faster, others slower, etc. WELL FUCKING DUH. The article seriously thinks this is original and insightful, but actually it was known to everyone. OBVIOUSLY, Intel releases new processor architectures on some years but not others, therefore the increase in transistor count will be faster on those years and slower on others.
2. A few journalists have misrepresented Moore's law, by publishing versions that were not identical with what Moore actually said. AMAZING. A journalist misquotes, or misunderstands a technical issue? Who would have thought it possible? I'm glad we have this article to expose such shocking truths.
...Moore's law was always intended as a rough rule of thumb that applies relatively well over a long period of time. If anything, the article buttresses Moore's law. The article notes that the original micoprocessor in 1975 had 2,500 transistors, and that the P4 has ~40 million. If we assume a doubling time of 2 years, then Moore's law was substantially correct, within a 10% margin of error. This was far more accurate than I was expecting, and far more accurate than Moore was expecting.
"AMD is a huge company. One, two, three, or even four flopped products are not going to phase AMD. Look at AMD's website. PC processors are the most mainstream product they make, and thus the highest profile, but processors are just a cog in the AMD wheel. (And the same thing goes for Intel)."
All of that is absolutely false.
First, AMD is not a huge company. With a market cap of $2 billion, it counts as a "mid cap" company, almost down to a "small cap" company.
Second, if x86-64 is a flop for AMD, it would gravely damage the company. AMD might survive it, but not easily. When the K5 was a total flop, and the K6 was driven to unprofitable prices, AMD came within a hair of declaring bankruptcy. Even now, AMD is not profitable, and does not have enormous cash reserves.
Third, even though both AMD and Intel manufacture things other than processors, their processors account for the vast bulk of their revenues. Processors are not a "cog" in the wheel of either AMD or Intel; processors are the mainstays of both companies.
"PC processor's are the tip of the iceberg when you consider embedded processors."
AMD is not the biggest player in the embedded market either.
...And finally, someone please downgrade the post as "overrated." All of the facts contained therein were incorrect, which hardly deserves a "5" rating.
Re:Subversion is far better than CVS
on
Multi-User Subversion
·
· Score: 2, Informative
"It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much."
Manually tinkering with the CVS metadata should never be necessary, especially for something so common as moving a file.
"Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming."
That is exactly the problem: diff does not support any other way of renaming. In fact, diff does not support renaming at all; it supports only deletion and addition, which is not the same as renaming. With deletion and re-adding, the history of the new file does not indicate that it was moved from another location; it appears to have been spontaneously generated. You are still thinking in terms of diffs, and assuming that the limits of diffs are the limits of source code control. Diffs are the very architectural drawback of cvs; with subversion, you can get a history that indicates "this file was moved here, then there, then there, then this directory was created and that one deleted, etc." ALL of that is impossible with cvs, and all of it is quite common.
"Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse."
It would be difficult to be worse; cvs does not even handle renaming at present, but only deletion and subsequent addition, which is not the same. The authors of the original cvs are the ones writing subversion, because they realize cvs's serious limitations in this regard. CVS also has limitations in other regards, like lacking atomic commits. This would be possible to implement in cvs, using diffs, but it would be very hacky.
Subversion is far better than CVS
on
Multi-User Subversion
·
· Score: 5, Interesting
The fundamental design of CVS is flawed, and this leads to anomolous behavior. Becase the problem with CVS is in its design, not its current implementation, a re-design and corresponding re-write is reqiured.
For example, CVS stores its repository in a series of diffs in a directory structure, and the directory structure parallels the development tree. The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs. In subversion, the entire repository (dirs, files, and all) is stored as a single coherent revision; a subversion repository is an array of coherent tree/file groupings. As such, correct handling of directories occurs automatically. Also, atomic commits (something cvs lacks) are handled much more easily in this model.
Let me also say that the design of subversion is absolutely excellent. The design is properly decoupled and properly abstracted. Architecturally, it is greatly superior to cvs, and substantially superior to several commercial alternatives. I would imagine that the low-end source control products (PVCS, SourceSafe) will have significant difficulty staying alive once Subversion is widely deployed and tested.
Cable is fundamentally better
on
DSL Rising
·
· Score: 2
Neither the coax cables, nor the phone cables, were initially intended for broadband internet access. As such, both cable and DSL are hacks. However DSL is far more of a hack; trying to do broadband over unshielded twisted pair copper wires is absurd. "Let's hope you're close enough to the switching station that the signal doesn't totally degrade..." At least cable is over a shielded coax cable, something with massive bandwidth that doesn't crap out during bad weather.
And the objection about cable being shared bandwidth, is silly. The Internet is shared bandwidth. Nobody has a "direct line" to any server. Insofar as the cable company is not overselling, cable is a much better technology.
You really should keep quiet on those subjects which you so apparently know verry little about, and you certainly shouldn't attempt to justify your own ignorance by
I deal with telcos on a day-to-day basis as well; several of my dear friends are executives or vice-presidents at various telcos. How the hell does anyone mod up your posts?
"If my company could purchase an unused fiber optic line I can gauran-damn-tee you we make our bandwidth cheaper."
The slight difficulty is: the fiber doesn't go to your company. If your company purchased an unused fiber-optic line, it would run through rural Oregon and would not make your bandwidth cheaper. They are talking about long-distance fiber, not last-mile fiber.
"I deal with the phone company day in and day out, and have been for several years. I know exactly what trenching and maintenance costs are, and they have made more than their money back on every line they've laid."
What color is the sky in your world? The telcos have been hemmoraging money because they've lost vast sums on most lines they've laid. Do you even follow the general economy? Ever heard of the telco meltdown? Did you even read the article? The article states that they have lost close to $1 trillion; how would that be possible if they make money on every line they've laid?
"They are no less monopolies than ma Bell was, only now they've been able to gerrymander and adapt into monopolies which are much harder to prosecute. Perhaps you need a dose of the real world, because this fantasy world where telcos play anywhere near fair doesn't exist."
You are totally and completely uninformed about this issue. The long-distance telcos are not monopolies; there were dozens of companies competing in this area. I personally know somebody that started one.
Monopoly means ONE COMPANY offering service, that has substantial control over prices. In the last several years, I have switched long-distance phone companies more than 4 times. And if telcos had control over prices (as monopoly implies), then why would they be losing money? Virtually every ISP has multiple redundant bandwidth providers; how would that be possible in a monopoly?
Your posts are positively the most uninformed on this matter, and it amazes me that some people have modded them up.
Your post is totally incorrect, and has nothing to do with what is found in econ books.
"Examples include farming (hence we actually pay farmers to grow nothing), steel (at least now), oil (otherwise OPEC wouldn't set production quotas), and, yes, bandwidth."
Farming is supported by an enormous government subsidy. Steel is supported by huge tariffs. The price of oil is kept high by a cartel. These examples have nothing to do with bandwidth. Furthermore, they are not examples of the phenomenon you were attempting to show.
"there are many industries in which a dramatic increase in quantity of product would drop prices so much that the overall net revenue would be lower at higher quantity."
Revenue would be lower at higher quantity?
"It isn't the lack of fiber - as the article says, there's a lot unused. It wouldn't be that hard to tap, especially since most consumers would be willing to pay for reasonable install costs."
Like lots of other posters have pointed out, the fiber would be exceptionally hard to tap. The article is talking about long-distance fiber that has nothing whatsoever to do with the bandwidth going to your house. A "reasonable install cost" would be the cost of paying someone to dig trenches and lay cables to your house -- something that could costs hundreds of thousands of dollars.
"No, the reason is the phenomenal price drop that an increase in quantity would bring, nothing more. And you're right, it's not about "evil" phone companies - it makes good sense to do what they're doing."
An increase in quantity would not bring a phenomenal price drop for anyone. The article states clearly that the excess bandwidth is in excess of current needs; not that it is currently being artificially held off the market to support earnings.
The most important factor is population density. East Asia and Europe are much more densely populated than the US. With DSL, the most important factor is distance; DSL doesn't work if you live over 2 miles away from a telco switching station. The majority of Americans could never get DSL.
Additionally, in some foreign countries there are government subsidies for the rollout of broadband, whereas there are no such subsidies in the US.
Excite@home died because they couldn't make any money selling broadband.
"With no sense whatsoever, the Bush administration forgave them. Better to have a few companies you can rule than many that might constitute a free press."
Bush does not "rule" the telcos. Even if there were more telcos, it would not constitute a "free press," as this issue has nothing to do with the free press.
"Don't think for an instant that you will not be hurt by this. You and I will continue to pay absorbadent [sic] long distance fees or just not use the services as planned."
I'm not meaning to be brash or abrasive; but it's somewhat difficult to believe that your comment got modded up to 5. I'm not sure you were being serious in your comment.
The bandwidth currently available is not artificially kept off the market to benefit some monopoly. The article did not say anything of the sort.
Furthermore, a sudden influx of new bandwidth would not affect your local phone company, or your local phone bill, in any way. Fiber going along the middle of oregon is not the principal cost of local phone service.
And, long-distance phone service is certainly not a monopoly. There are dozens of competitors in that area; in fact, the area is overcrowded and companies are leaving because they can't make any money on it. You can switch long-distance carriers with ease.
The VIA CPU is a reincarnation of the old IDT/centaur winchip. Via purchased both centaur and cyrix after they both flopped at making x86 CPUs.
The Via c3 has only one integer unit and one fp unit, coupled with a decent-sized cache. Architecturally, the via c3 is extremely primitive, worse than the original pentium. The c3 benchmark scores are consistently about 1/3rd to 1/4th those of a celeron or a duron at the same clock speed.
That tragic this is: putting an AMD duron in this machine would have tripled the performance, and would have costed only about $10 more. The $199 lindows box was likely intended to be a no-profit "crippleware" machine, to lure people to the $299 and $399 models.
Umm, an IP address is not the same thing as a database transaction, in any way. New IP addresses are not assigned for every single exchange over the internet, to be agreed upon by every other internet node. Otherwise, all internet bandwidth would be exhausted in assigning IP addresses. Transactions are not the same as an IP address. Transactions require coherent memory or a two-phase commit mechanism (which is very slow).
"Theres a good bit of Computer Science theory on the subject, and there has been for about twenty years. Many professional databases designed today can work in a distributed manner and almost all of them are capable of scaling."
It's true, there is a good bit of CS theory on the subject. The conclusion of this research is that distributed databases are staggeringly difficult to do (MUCH more complicated than IP addresses). There is a huge number of theoretical difficulties.
Look at the benchmarks for clustered databases at www.tpc.org. To match IBM's standalone 32-proc machine, you need a 200+ proc cluster with extremely expensive, low-latency networking equipment. The cluster of commodity boxes ends up being more expensive than the big iron. Consequently, demand for mainframes and large unix boxen will continue.
If clustering databases were so easy, why would anyone buy a 32-way unix box for $5 million? You could just connect 32 emachines with ethernet for 0.002% of the cost. Most companies do not try to spend several hundred times as much money as required. These big boxes have a market because distributed databases require enormous overhead for managing transactions.
Re:32 bits != 4 gig max
on
AMD's 64-bit Plot
·
· Score: 2, Informative
What you said is incorrect. "32 bit" has ALWAYS referred to the width of the data bus/registers.
SSE2 and AltiVec have 128-bit registers. This is so they can hold 4 32-bit quantities (the point is to be able to do 32-bit operations on 4 values at a time). It is still a 32-bit processor.
If the number of bits described the address bus width, then x86 is 36-bit, DEC Alpha is 36-bit (NOT 64-bit), 6502 is 16-bit, 68000 is 24-bit, 80286 is 24-bit, etc. This is clearly not the case. When was the last time you heard anyone refer to a Xeon as a 36-bit processor, or a 68000 as a 24-bit processor?
Slashdot Mirror
Alot of ideological publications cannot make it on their own. "The Nation" has never made money. "National Review" (on the right) is supported by WFB's family wealth. NPR takes government subsidies and still tirelessly presses is subscribers for more money!
There are only two kinds of media that can independently survive in America:
1. Mass-market outlets that take a "least common denominator" approach to content, trying to appeal to a wide array of people (Fox, Rush Limbaugh, Newsweek, US News, etc).
2. Outlets which have very high-quality content (Harper's, Granta, etc), for which a few people will pay a significant amount of money.
Salon is neither of these. To survive, it will require a subsidy, just like "National Review" and "The Nation."
Salon's biggest difficulty is the mediocre quality of its content. Salon tries to be an educated, urban, lefty magazine, but it doesn't quite make it. There are other magazines in the same space: The New Yorker, Atlantic Monthly, Mother Jones, Harper's, and so on. Can anyone seriously pretend that Salon's content is the same quality as, say, the Atlantic Monthly? When I saw that Salon wanted ~$30 to subscribe, I thought to myself: "I don't want to read their articles that badly." And I like leftist opinion journals.
Although I think your initial assesment of line printers was exaggerated, I'm glad to see that you have some basis for what you said.
Obviosuly, cheapo inkjets are not going to replace line printers for high-volume business. However, line printers are still being replaced, by high-volume laser printers. If I recall, a good line printer pumps out 15-20 pages per minute. For the same initial investment, you could get a laser printer that does 30+ ppm. Some volume lasers now get 80+ ppm. Toner lasts longer than inkjet cartridges or line printer ribbons, and produces output superior to line printers.
"[Bios is] necessary for embedded systems, and it's necessary to boot your machine. Your computer isn't just going to magically start your hard drive. And, considering all that legacy stuff is down pat and is _never_ changed, we're talking about 256k of extra EEPROM."
BIOS refers to a series of bootstrap sequences and assembly routines that came on ROM with the original IBM PC, and that served as a basis for the DOS operating system. As such, BIOS is not the same as firmware or ROM. And BIOS is not needed to boot a computer -- any kind of firmware will do. Apples and Suns boot just fine without BIOS.
BIOS is extremely outdated. Most of the assembly routines contained by the BIOS are totally useless to a modern operating system. So, most BIOS routines are never used nowadays. Furthermore, many desirable things are not included in the BIOS, for example, the ability to partition and format disks, examine memory contents, and so on.
"And, just like replacing a line printer with an inkjet printer, it's a much slower, lower quality, harder to read, and more expensive way to do exactly the same thing."
It would be difficult to imagine a comment more totally wrong than this one. Line printers costed thousands of dollars, had crappy output, and were often the size of a refrigerator. Inkjets are tiny, often cost under $50, have far better print quality, and can print pretty color pictures.
I understand that some people find it soothing to say: "things were better in the good old days." But with printers, computers, and firmware? The point of view is so ludicrous that it hurts. Computers and printers have not been declining in capability (see the Moore's Law article).
There is no good reason to retain the BIOS. The BIOS is not and elegant, refined mechanism. It was a hack 20 years ago and now it's around for legacy reasons only.
"Well, another slashdotter w/o any idea what he/she is talking about."
I not only know what I'm talking about, I'm also capable of composing a reasoned message, unlike you.
"1st) SUN doesn't make the CPU's, they specify the design... but the implementation is left to 3th party suppliers. Just like MIPS. But of course you already knew that, not!"
Oh, really? My, you're knowledgeable. Dude, everyone knows that Sun is fabless, and that they've always been fabless, and that Texas Instruments is their current foundry and manufactures their chips.
It's obvious that TI doesn't care about Sun, otherwise US-III wouldn't have been relegated to a manufacturing process that is almost two generations behind that which Intel & IBM are using.
However, Sun's US-III suffers from architectural and design shortcomings that are entirely apart from the outdated manufacturing techniques TI allots them. The design of the US-III is inferior to that of Sun's competitors in extremely important ways. For example, the US-III is the only major RISC CPU that still doesn't have dynamic instruction scheduling! In other words, the US-III is an IN-ORDER cpu. Out-of-order execution was a major architectural innovation that leads to performance improvements of 40-50% on commercial workloads. US-III is the only major chip that doesn't have it. Even MIPS (R10k) does OOO. This is a large part of the reason that the US-III trails its competitors so badly. Another reason is: the US-III has a 14-stage pipeline, which is exceptionally long for a CPU that doesn't even have to dynamically select instructions to execute. To say nothing of the slow clock speed despite long pipeline lenghts.
"2nd) on a per MHZ basis the US III is more efficient that any intel P4, i.e. it gets more done per clock cycle"
Anything is faster than an intel p4 at the same clock speed, even an intel p3. This is because the p4 has a design that increases the clock speed while decreasing the instructions per clock. It's irrelevant that the US-III gets (slightly) more done per clock, because the p4 has more than three times the number of clock cycles. Unless the US-III gets more than three times more done per clock, it will trail the low-end, cheap commodity part (x86) in performance.
At present, the top offering from Sun (US-III 1.05GHz) gets less than half the SpecINT performance of the top commodity Intel offering (p4 3GHz), and less than half the SpecINT performance of other high-end MPUs like POWER4. We would have a better idea of how US-III performed on commercial workloads if we were able to inspect the standard tpc-c benchmarks for Sun platforms. However Sun withdrew from those benchmarks, out of embarrassment, when their performnace began to seriously trail that of their competitors.
"And of course you had to top it all by giving financial advice. My guess is that the less you know the more you have to speak...."
You should learn manners.
"This is not true. The top end commercial systems suppliers all run within 90% of each other when comparing apples to apples. 50% less is a notion you pulled out of the sky."
... The more SPARC performance lags behind openly available merchant processor families like x86, x86-64, and IA64, the greater this pressure becomes."
That's completely untrue. Sun withdrew from the recognized transaction processing bencharks (tpc) when their performance started to fall seriously behind. I've witnessed the performance of database applications that I architected, on Sun's high-end servers, versus the high-end servers of other vendors. Sun's performance was ABSOLUTELY NOT within 90% of their competition. The major industry benchmarks (tpc-c) amply demonstrated this fact, before Sun withdrew from them out of embarrassment.
Sun's UltraSparc-III is still an in-order processor; they've never been able to implement out-of-order instruction scheduling. This architectural feature alone is responsible for a 30-40% improvement on commercial workloads. This is not "primarily for scientific computing" as you contend, since the primary benefit of OOO is Integer/commercial workloads. ALL of the other RISC vendors have implemented OOO, even MIPS.
Not to mention, the US-III has a 14-stage pipeline, which is rather long considering that they don't even have to dynamically select instructions to execute. And, the US-III is only a 5-issue core!
"Oh, and please do have a visit to Sparc Consortium [sparc.com] and check out the many other who contribute to sparc development."
I've visited the Sparc consortium website many times in the past. The members of the Sparc consortium specify the instruction set architecture for Sparc; they have nothing whatsoever to do with Sun's CPU core designs, or with the UltraSparc-III that I mentioned was deficient. As such, your point is irrelevant to the current conversation.
"Oh, and please do" have a look at Paul DeMone's insightful article regarding Sun CPUs, at www.realworldtech.com:
"The immediate future aside, Sun is faced with a long term MPU credibility problem
Sun's CPU offering is simply not competitive. On commercial workloads it gets apprxomiately half the performance of its peers. This is for two reasons: 1) the design is bad, leading to lower performance at a given clock speed, and 2) the manufacturing process is very old, leading to low clock speeds. (double whammy).
It would be very difficult for Sun to sell competitive boxes when their CPUs are half-speed. How are they going to sell an 8-way box for the same price as a 4-way commodity Xeon 3GHz?
What Sun has to do is: GET THE HELL OUT of making CPUs. It costs them tons of money, and they can't do it well, and the failure is crippling them. Everyone likes Solaris; everyone likes Sun's reliability features; everyone HATES Sparc's performance.
My advice to Sun? PARTNER WITH FUJITSU!! Fujitsu currently makes a Sparc chip that's almost twice the speed of Sun's! Sun should just drop their own CPU development and buy Sparc CPUs from Fujitsu. This would save Sun the $400M they currently spend on CPU development, drastically lowering their prices, and would double their performance. Seems like a no-brainer to me.
The old Star Trek was good enough that it created brand-name recognition. It created a certain faith that the next Star Trek installment would be good. The movie producers understood this brand-name recognition, and figured that trekkies would go see anything with Star Trek on the label, which was true. So the content creators released a slew of shitty Star Trek movies and TV series. They abused, and eventually destroyed, the Star Trek brand. When I heard about this movie, I assumed it would be terrible, prior to reading any reviews about it.
The same thing is happening with Star Wars. There was huge brand-name recognition. But now there's been two shitty movies in a row; the faith is teetering and about to collapse. Star Wars cannot withstand another shitty movie, or nobody will see the subsequent one.
"When the CPU does go to RAM for the data, i bet that a 3GHz P4 waits idle for about twice as many cycles as a 1.5GHz Itanium (given same-speed memory systems). "...NOTHING to do with P4 architecture", right?"
The P4 waits idle for twice as many cycles because it HAS twice as many cycles. The clock rate of the processor is not what's important here. Latency to non-cached RAM has NOTHING to do with p4 architecture.
"Read the article, and you'll notice that HT gave a far larger benefit with the designed-specifically-for-HT kernel. You got a better 4-word summary of this than "HT requires OS support"?"
Yes I have a better brief summary. You said that HT "requires" OS support. That is not just an exaggeration; it is false. If true, this would mean that HT would not work at all unless the OS were specifically written to take advantage of it. An accurate summary would read: "HT benefits from optimizations designed to exploit it."
"Summary: you can nit-pick okay, but i don't think you understand the technology or get the point of a short summary."
I understand the technology quite well, and I certainly understand the point of an accurate summary, which yours was not.
SMT (hyperthreading) will become increasingly important when processors are able to execute more than 2 threads simultaneously.
This development is inevitable. Previously, each new processor generation was faster than the prior one at a given clock rate, because each new processor core had more execution units, and was therefore able to perform more work in parallel. This trend abruptly ended recently, for one reason: there is no more instruction-level parallelism (ILP) to exploit. It is impossible for a processor to look at a thead of execution and find more than a few instructions to execute in parallel.
The only parallelism left to exploit is THREAD-LEVEL parallelism (TLP). Therefore the only way to continually increase performance is to increase the number of threads that a CPU can execute in parallel. This requires two modifications to CPU cores: first, increase the number of thread contexts per CPU, and second, increase the number of pipelines to which those threads can be dispatched.
With the P4, it would be pointless to have more than 2 thread contexts, because there aren't enough CPU resources lying idle to execute more than 2 threads. But future CPUs could make use of more than 2 thread contexts by having enough CPU resources to execute all of them. Future CPUs could have 20 execution units or more, which would be enough to execute several threads. Remember that the number of transistors per CPU continues to increase exponentially.
It's easy to forsee a time when processors have 20 execution units (10 integer, 10 fp) and 4 thread contexts, offering more than triple the performance of a non-SMT cpu. In the future, non-SMT CPUs will make as little sense as a non-superscalar CPU would today.
One of the major impediments to increasing CPU performance has been increasing memory latency. Memory latency has grown worse as CPUs have gotten faster. Accessing RAM will now cause a >150 cycle latency, during which the processor sits IDLE.
Cache only partly mitigates this problem. Some applications, such as databases and OLTP, are heavily dependent on repeatedly accessing non-cached RAM. There is no way to cache all the relevant data, since virtually all databases are larger than can fit in any present cache, no matter how large, and there is sometimes no way to predict which data will be accessed. ALL of these applications have CPUs that spend much of their time being IDLE, waiting for memory to be returned.
SMT (hyperthreading) allows the processor to perform useful work during these otherwise idle periods, by allowing the cpu to switch to a thread that is not blocked on memory access. The "idle bubbles" in the execution pipeline can therefore be "filled in" by useful work that advances the state of relevant programs.
SMT can cause a degredation in performance beceause it can lead to "cache thrashing." In an SMT-naive kernel, two unrelated threads could be scheduled for the same physical CPU. These unrelated threads will likely share very little code or data. The two threads will therefore "compete" for the single shared cache, with each thread's data being repeatedly displaced by the other's.
This difficulty can be substantially mitigated by making the kernel aware of "virtual processors," and by implementing scheduleing algorithms to minimize the impact. The performance of hyperthreading will likely improve as kernels are better able to exploit it.
What you said was false.
Take the example of database & OLTP applications. Database transactions are heavily dependent on repeated access to RAM. Virtually no database is small enough to fit into cache, and there is often little regularity in which data is accessed. Memory latency will REQUIRE a non-SMT processor to wait IDLY each time there is a memory latency, which takes >100 proc cycles on a modern CPU. This has NOTHING to do with he p4 architecture or long pipelines.
"But remember that HT requires OS support, may require application support..."
HT does not require OS support as long as the OS is capable of recognizing more than 1 CPU. Any threaded app can benefit from HT.
The author of the article seems to misunderstand completely the intent of Moore's law. The article notes a few things:
...Moore's law was always intended as a rough rule of thumb that applies relatively well over a long period of time. If anything, the article buttresses Moore's law. The article notes that the original micoprocessor in 1975 had 2,500 transistors, and that the P4 has ~40 million. If we assume a doubling time of 2 years, then Moore's law was substantially correct, within a 10% margin of error. This was far more accurate than I was expecting, and far more accurate than Moore was expecting.
1. Increases in transistor count do not precisely follow an exact, continuous, exponential mathematical function. Some years it grows faster, others slower, etc. WELL FUCKING DUH. The article seriously thinks this is original and insightful, but actually it was known to everyone. OBVIOUSLY, Intel releases new processor architectures on some years but not others, therefore the increase in transistor count will be faster on those years and slower on others.
2. A few journalists have misrepresented Moore's law, by publishing versions that were not identical with what Moore actually said. AMAZING. A journalist misquotes, or misunderstands a technical issue? Who would have thought it possible? I'm glad we have this article to expose such shocking truths.
"AMD is a huge company. One, two, three, or even four flopped products are not going to phase AMD. Look at AMD's website. PC processors are the most mainstream product they make, and thus the highest profile, but processors are just a cog in the AMD wheel. (And the same thing goes for Intel)."
...And finally, someone please downgrade the post as "overrated." All of the facts contained therein were incorrect, which hardly deserves a "5" rating.
All of that is absolutely false.
First, AMD is not a huge company. With a market cap of $2 billion, it counts as a "mid cap" company, almost down to a "small cap" company.
Second, if x86-64 is a flop for AMD, it would gravely damage the company. AMD might survive it, but not easily. When the K5 was a total flop, and the K6 was driven to unprofitable prices, AMD came within a hair of declaring bankruptcy. Even now, AMD is not profitable, and does not have enormous cash reserves.
Third, even though both AMD and Intel manufacture things other than processors, their processors account for the vast bulk of their revenues. Processors are not a "cog" in the wheel of either AMD or Intel; processors are the mainstays of both companies.
"PC processor's are the tip of the iceberg when you consider embedded processors."
AMD is not the biggest player in the embedded market either.
"It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much."
Manually tinkering with the CVS metadata should never be necessary, especially for something so common as moving a file.
"Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming."
That is exactly the problem: diff does not support any other way of renaming. In fact, diff does not support renaming at all; it supports only deletion and addition, which is not the same as renaming. With deletion and re-adding, the history of the new file does not indicate that it was moved from another location; it appears to have been spontaneously generated. You are still thinking in terms of diffs, and assuming that the limits of diffs are the limits of source code control. Diffs are the very architectural drawback of cvs; with subversion, you can get a history that indicates "this file was moved here, then there, then there, then this directory was created and that one deleted, etc." ALL of that is impossible with cvs, and all of it is quite common.
"Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse."
It would be difficult to be worse; cvs does not even handle renaming at present, but only deletion and subsequent addition, which is not the same. The authors of the original cvs are the ones writing subversion, because they realize cvs's serious limitations in this regard. CVS also has limitations in other regards, like lacking atomic commits. This would be possible to implement in cvs, using diffs, but it would be very hacky.
The fundamental design of CVS is flawed, and this leads to anomolous behavior. Becase the problem with CVS is in its design, not its current implementation, a re-design and corresponding re-write is reqiured.
For example, CVS stores its repository in a series of diffs in a directory structure, and the directory structure parallels the development tree. The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs. In subversion, the entire repository (dirs, files, and all) is stored as a single coherent revision; a subversion repository is an array of coherent tree/file groupings. As such, correct handling of directories occurs automatically. Also, atomic commits (something cvs lacks) are handled much more easily in this model.
Let me also say that the design of subversion is absolutely excellent. The design is properly decoupled and properly abstracted. Architecturally, it is greatly superior to cvs, and substantially superior to several commercial alternatives. I would imagine that the low-end source control products (PVCS, SourceSafe) will have significant difficulty staying alive once Subversion is widely deployed and tested.
Neither the coax cables, nor the phone cables, were initially intended for broadband internet access. As such, both cable and DSL are hacks. However DSL is far more of a hack; trying to do broadband over unshielded twisted pair copper wires is absurd. "Let's hope you're close enough to the switching station that the signal doesn't totally degrade..." At least cable is over a shielded coax cable, something with massive bandwidth that doesn't crap out during bad weather.
And the objection about cable being shared bandwidth, is silly. The Internet is shared bandwidth. Nobody has a "direct line" to any server. Insofar as the cable company is not overselling, cable is a much better technology.
You really should keep quiet on those subjects which you so apparently know verry little about, and you certainly shouldn't attempt to justify your own ignorance by
I deal with telcos on a day-to-day basis as well; several of my dear friends are executives or vice-presidents at various telcos. How the hell does anyone mod up your posts?
"If my company could purchase an unused fiber optic line I can gauran-damn-tee you we make our bandwidth cheaper."
The slight difficulty is: the fiber doesn't go to your company. If your company purchased an unused fiber-optic line, it would run through rural Oregon and would not make your bandwidth cheaper. They are talking about long-distance fiber, not last-mile fiber.
"I deal with the phone company day in and day out, and have been for several years. I know exactly what trenching and maintenance costs are, and they have made more than their money back on every line they've laid."
What color is the sky in your world? The telcos have been hemmoraging money because they've lost vast sums on most lines they've laid. Do you even follow the general economy? Ever heard of the telco meltdown? Did you even read the article? The article states that they have lost close to $1 trillion; how would that be possible if they make money on every line they've laid?
"They are no less monopolies than ma Bell was, only now they've been able to gerrymander and adapt into monopolies which are much harder to prosecute. Perhaps you need a dose of the real world, because this fantasy world where telcos play anywhere near fair doesn't exist."
You are totally and completely uninformed about this issue. The long-distance telcos are not monopolies; there were dozens of companies competing in this area. I personally know somebody that started one.
Monopoly means ONE COMPANY offering service, that has substantial control over prices. In the last several years, I have switched long-distance phone companies more than 4 times. And if telcos had control over prices (as monopoly implies), then why would they be losing money? Virtually every ISP has multiple redundant bandwidth providers; how would that be possible in a monopoly?
Your posts are positively the most uninformed on this matter, and it amazes me that some people have modded them up.
Your post is totally incorrect, and has nothing to do with what is found in econ books.
"Examples include farming (hence we actually pay farmers to grow nothing), steel (at least now), oil (otherwise OPEC wouldn't set production quotas), and, yes, bandwidth."
Farming is supported by an enormous government subsidy. Steel is supported by huge tariffs. The price of oil is kept high by a cartel. These examples have nothing to do with bandwidth. Furthermore, they are not examples of the phenomenon you were attempting to show.
"there are many industries in which a dramatic increase in quantity of product would drop prices so much that the overall net revenue would be lower at higher quantity."
Revenue would be lower at higher quantity?
"It isn't the lack of fiber - as the article says, there's a lot unused. It wouldn't be that hard to tap, especially since most consumers would be willing to pay for reasonable install costs."
Like lots of other posters have pointed out, the fiber would be exceptionally hard to tap. The article is talking about long-distance fiber that has nothing whatsoever to do with the bandwidth going to your house. A "reasonable install cost" would be the cost of paying someone to dig trenches and lay cables to your house -- something that could costs hundreds of thousands of dollars.
"No, the reason is the phenomenal price drop that an increase in quantity would bring, nothing more. And you're right, it's not about "evil" phone companies - it makes good sense to do what they're doing."
An increase in quantity would not bring a phenomenal price drop for anyone. The article states clearly that the excess bandwidth is in excess of current needs; not that it is currently being artificially held off the market to support earnings.
The most important factor is population density. East Asia and Europe are much more densely populated than the US. With DSL, the most important factor is distance; DSL doesn't work if you live over 2 miles away from a telco switching station. The majority of Americans could never get DSL.
Additionally, in some foreign countries there are government subsidies for the rollout of broadband, whereas there are no such subsidies in the US.
Ummm, whatever...
"With a little malice, ATT killed excite@home"
Excite@home died because they couldn't make any money selling broadband.
"With no sense whatsoever, the Bush administration forgave them. Better to have a few companies you can rule than many that might constitute a free press."
Bush does not "rule" the telcos. Even if there were more telcos, it would not constitute a "free press," as this issue has nothing to do with the free press.
"Don't think for an instant that you will not be hurt by this. You and I will continue to pay absorbadent [sic] long distance fees or just not use the services as planned."
Long-distance fees have been dropping for years.
I'm not meaning to be brash or abrasive; but it's somewhat difficult to believe that your comment got modded up to 5. I'm not sure you were being serious in your comment.
The bandwidth currently available is not artificially kept off the market to benefit some monopoly. The article did not say anything of the sort.
Furthermore, a sudden influx of new bandwidth would not affect your local phone company, or your local phone bill, in any way. Fiber going along the middle of oregon is not the principal cost of local phone service.
And, long-distance phone service is certainly not a monopoly. There are dozens of competitors in that area; in fact, the area is overcrowded and companies are leaving because they can't make any money on it. You can switch long-distance carriers with ease.
The VIA CPU is a reincarnation of the old IDT/centaur winchip. Via purchased both centaur and cyrix after they both flopped at making x86 CPUs.
The Via c3 has only one integer unit and one fp unit, coupled with a decent-sized cache. Architecturally, the via c3 is extremely primitive, worse than the original pentium. The c3 benchmark scores are consistently about 1/3rd to 1/4th those of a celeron or a duron at the same clock speed.
That tragic this is: putting an AMD duron in this machine would have tripled the performance, and would have costed only about $10 more. The $199 lindows box was likely intended to be a no-profit "crippleware" machine, to lure people to the $299 and $399 models.
Umm, an IP address is not the same thing as a database transaction, in any way. New IP addresses are not assigned for every single exchange over the internet, to be agreed upon by every other internet node. Otherwise, all internet bandwidth would be exhausted in assigning IP addresses. Transactions are not the same as an IP address. Transactions require coherent memory or a two-phase commit mechanism (which is very slow).
"Theres a good bit of Computer Science theory on the subject, and there has been for about twenty years. Many professional databases designed today can work in a distributed manner and almost all of them are capable of scaling."
It's true, there is a good bit of CS theory on the subject. The conclusion of this research is that distributed databases are staggeringly difficult to do (MUCH more complicated than IP addresses). There is a huge number of theoretical difficulties.
Look at the benchmarks for clustered databases at www.tpc.org. To match IBM's standalone 32-proc machine, you need a 200+ proc cluster with extremely expensive, low-latency networking equipment. The cluster of commodity boxes ends up being more expensive than the big iron. Consequently, demand for mainframes and large unix boxen will continue.
If clustering databases were so easy, why would anyone buy a 32-way unix box for $5 million? You could just connect 32 emachines with ethernet for 0.002% of the cost. Most companies do not try to spend several hundred times as much money as required. These big boxes have a market because distributed databases require enormous overhead for managing transactions.
What you said is incorrect. "32 bit" has ALWAYS referred to the width of the data bus/registers.
SSE2 and AltiVec have 128-bit registers. This is so they can hold 4 32-bit quantities (the point is to be able to do 32-bit operations on 4 values at a time). It is still a 32-bit processor.
If the number of bits described the address bus width, then x86 is 36-bit, DEC Alpha is 36-bit (NOT 64-bit), 6502 is 16-bit, 68000 is 24-bit, 80286 is 24-bit, etc. This is clearly not the case. When was the last time you heard anyone refer to a Xeon as a 36-bit processor, or a 68000 as a 24-bit processor?