Upon the 4th month, at the stroke of midnight, they will deliver the code. It's funny to say, but terrifyingly true. I've gotten to the point this seems normal.
Although my boss is growing more and more grey hair these days.
I have add my $0.02 1.) The mainframe guys have cars?!? (I thought they had tractors-- the original 'off-road' vehicle, and still quite relevant). 2.) The Windows crowd doesn't use screwdrivers. (That's what thumbscrews are for.)
I can walk into a massive dust devil, spin around like the tazmanian devil in looney tunes, act like it's my spinning that's causing the thing to spin. I'll come out generally unharmed. (Maybe a bit irritated from bits of dust hitting my skin, or maybe a bit of dirt in my eyes and/or nostrils -- but otherwise quite unharmed.)
OTOH, I tend to avoid (and flee from) tornadoes, as there's a high degree of certainty if we were to interesect one another, I wouldn't survive.
the big wins in power savings come not from shrinking instruction decode space, but going to new fabrication technologies and materials and other technologies. you get orders of magnitude savings there, versus a few %. pure "risc" designs (sparc, mips, etc)
I won't argue otherwise; but every microwatt counts (espescially to the embedded world).
And for diminishing returns vs. effort for a RISC design vs. a CISC design -- CISC is intrinsically harder to design (pipelining, decode, optimization, etc.) That's why everything AMD designed from the Athlon to the Opteron are, in their heart, a RISC chip; it's much easier (and therefore cheaper) to pipeline a RISC design. A major argument of RISC was that it's a cheaper/easier design methodology; something that is no less true today. While the proportion of the savings are diminished, the savings are still there.
it is interesting to note that in the most recent generations of chips, x86/"cisc" designs tend to be much smaller, lower power, etc. than their "risc" counterparts. take the behemoth alpha 21364 for example.
Comparing Alphas to Athlons is really quite apples to oranges... it's not even the same market.
When I first read this, I was wondering what you were on; then I read the qualification of 'x86/cisc'. Recent x86 designs are neither CISC nor RISC, (since they are both and neither) so it's inaccurate to call it a CISC cpu. The same is true for PowerPC, SPARC, and just about every other desktop/workstation processor out there.
But I have yet to see a true/fully CISC design that is smaller and has lower power requirements than an equivalent pure RISC design. For that matter, I haven't seen a new and true CISC design in ages. However, the embedded market is dominated with true RISC chips -- precicely because they are smaller, cheaper, and use less power.
Like I've been saying from my first post -- the desktop/workstation and server market is less than 1% of the total CPU market (in both dollars and quantities); the rest are variations of embedded processors, whose market is thoroughly dominated by fairly pure RISC designs.
In terms of die space the instruction decode is vanishingly small compared to everything else. So thank you for confirming that this 'design win' of RISC is no longer significant or even relevant anymore. On the original Opteron, Instruction Decode was about the same size as one of the FPU pipelines, or about 10% of the total die space; this is not 'vanishingly small.' Of that, about 75% of the ID was strictly for translation of x86 into 'native opteron.' So that's a 5% power and heat penalty that is entirely unnecessary.
RISC still does have a design win here, and is quite significant -- an extra 15-20 minutes of battery life on a notebook computer isn't unappreciated. It's just that the win isn't as big as its proponents anticipated, largely due to the fact that modern superscalar/superpipelined CPU has multiple (frequently identical) execution units. RISC assumed (quite reasonably, at the time) there wouldn't be such duplication of resources within a single CPU core. Reguardless, that few percent reduction of complexity, size, and power do matter, and does add up when you ship a few million chips.
The other design wins of RISC was in pipelining and promoting(requiring) good compilers -- both of which are the biggest wins of the RISC evolution, and are very, very far from being insignificant or irrelevant.
Yes they can. uops are like "increment program counter" "emit address out the memory bus" "submit read command to memory bus" "retrieve word from data bus into memory bus register" "transfer word from memory bus register into cpu register" etc.
Apparently we're talking a difference between operations and instructions. These are not instructions, they are hardwired operations that tend to use the clock as a trigger. Many (such as the program counter increment) happen with each and every clock tick, and are only overridden with an instruction.
What I was speaking of are what were termed 'RISCops' by AMD -- meaning a CISC instruction like:
add
would be translated into its RISC equivalent for execution in the Opteron's core: load load add store
Of course pipelining ends up breaking even these down into the operations of shuffling bits into and around registers until the actual 'add' takes place; then moving the result back to a register, which is in turn moved to cache, and if it's really lucky, back to main memory.
The number of operations within the instruction (setting address pins, wait for ready, read data pins, store value in register, etc, etc.) are of course still there. And the number of these operations has only increased with AMD putting the entire memory controller on the die; life used to be so much simpler... just set the pins and wait for the memory controller to do its job...
the die space you "win" with a smaller instruction decode stage doesnt make up for the space you lose having to add enormous caches because of the increased bandwidth your RISC instructions take. save a few % in instruction decode and lose tons of % in added cache to make up for it.
This isn't the problem you seem to believe -- at least not for a RISC design. A VLIW design, however, is another story entirely. VLIW (ie Itanium) != RISC; VLIW needs massive amounts of cache (and bandwidth).
On a RISC chip, the amount of die size increase due to the instruction cache is negligible compared to the die shrink from reduced instruction decode. And in terms of actual usage, instruction caching is a tiny fraction of the space taken; data cache is (overwhelmingly) the majority holder -- and data takes up the same amount of space reguardless of the chip paradigm.
RISC looked very "n3at0" in the late 80s as it appeared CISC was running out of steam, but we learned a lot since then. a lot of the assumptions which were the foundation of RISC design turned out to be not true in the long term.
CISC did run out of steam. Entirely. The only vestigal part of a CISC design that exists today is the programmer's instruction set -- but after the programmer's interface has been passed, everything is entirely in RISC country. A CISC uop is the CPU's RISC core execution instruction. The only place CISC exists is to the programmer -- it doesn't exist at all after the instruction has been chopped up into RISC instrucitons for execution. There is no CISC vs. RISC war; RISC won -- and won so convincingly that the only popular CPU that even looks like a RISC chip anymore is x86 -- but it only looks like a CISC chip to the ignorant who choose to delude themselves into believing that CISC still has relevancy. CISC chips are notoriously difficult (and often impossible) to pipeline; one of the key goals of the RISC model was to make pipelining almost trivial -- which is the biggest reason why nearly all modern chips (including x86) are, at their core, RISC designs (with a bit of circuitry to chop CISC instructions into a series of RISC instructions).
That's not to say that there aren't elements of both; one of the key goals of a CISC design was to have the assembly act much like a higher-level language like C. On other side of the coin, RISC doesn't provide high-level instructions at the assembly level -- the developer isn't supposed to be writing in assembly -- compiling the code from a higher-level language such as C was the intended path for RISC machines. RISC chip design assumes a good, optimizing compiler would generate fast code (so much for that assumption)...
And as for your contention about a RISC instruction being very complex compared to a CISC uop... RISC instructions (such as 'add', 'load', 'store', or 'is greater') can't be made more atomic. The 'complex' instructions of a PPC, MIPS, Alpha, or SPARC processor aren't a RISC instruction at all -- but rather an attempt to provide a way for developers to use the 'new gee-whiz-bang SIMD idea'. Since a RISC chip assumes the use of a compiler, then compilers would have to add support to SIMD operations -- but the timeline to get compilers to support SIMD was so long that the decision was made to make a high-level (CISC) series of instructions and bolt them onto the RISC core; in this way the new SIMD features could be used immediately, rather than years down the road. Considering the time it took compiler developers to support SIMD outside of inline assembly, this decision seems to have been well-justified.
I'm well aware there are few programs that are 100% static and linear. There is a lot to be said for runtime optimization; all I'm saying is there needs to be more done at compiler time instead.
now you want compilers to emit u-ops to make your life easier. and you hardware guys wonder why we call you unhinged? You realize this argument goes both ways, right? That turf war aside, emiting a 'u-op' as you put it, is exactly what a compiler for a 'RISC' processor does, because there are no u-ops -- this is one of the key characteristics of a RISC processor. It's not like it's something that isn't done; x86 is not the entire universe, or even close to 1% of it. Most of the world's CPU's are a RISC machine, and a RISC cpu's compiler dispatches the equivalent of a CISC u-op.
And it isn't really a case of making my life any easier-- run-time optimization isn't going away. But there are costs involved with doing optimizations at runtime rather than at compile time. First is the consumption of electricity, and there's the closely tied generation of heat from the extra circuitry. It significantly increases the size of the CPU die, the transistor count, etc. In fact, that's the whole reason the RISC methodology came about -- at the time, it was noticed that the instruction decode stage was taking up some-odd 17-20% of the CPU -- and most of those transistors did nothing but suck power and produce heat 99.999% of the time. By making the compiler smarter, and the chip dumber, chip costs, chip complexity, power consumption, heat produced, transistor count, and cost were all slashed -- with no drop in performance.
People care about how long the battery lasts on their portable devices, how hot their notebook gets in their lap, how much cooling is required to keep a rack of servers running, things like that.
Taking that much more effort ONCE at compile time is cheaper (for everybody involved) when contrasted to doing the same optimization trillions of times while executing the program. There are far more negative consequences that come as a result of having the hardware optimize code -- not that it doesn't have its uses (as you stated, not all programs are static and linear); but that doesn't excuse a substantial portion of what is being offloaded to the CPU for optimization.
The Itanium takes the offloading tasks to the compiler a bit too far; you miss out on the optimizations that can really only be done at execution time. Most of the other complexity problems with Itanium compilers are more related to its VLIW design than the Itanium itself; there are few who are familiar with writing a VLIW compiler, because it's a more difficult problem to wrap one's head around.
A pure comiler-optimized execution isn't really a practical thing; but compilers can (and should) be doing more, as they have a much better opprotunity to take a larger view of the code.
The fact is that in either case, the algorithm to implement a given optimization is nearly the same in either case -- The only substantial difference is in its implementation, and the corresponding tradeoffs. Obviously, I believe if a compiler can do the particular optimization, it should be doing it-- not the CPU.
It doesn't take additional energy at runtime if the optimization is done by the compiler. It does require energy each time the optimization is executed during a program's run -- which is fairly non-trivial, espescially over time.
This doesn't matter much to those who will only be programming to a 'PC' plugged into a wall. But for those who make any kind of battery-powered, consumer, or embedded device, the extra energy consumption is a very big deal, as are the extra costs involved with a larger die, higher transistor count, and larger amount of heat dissapated.
Not the problems that the PPC's implementation has.
One favorite is that while the PPC is 'RISC', it has a larger number of instructions than an Opteron; but since 'RISC' is usually slapped on any load/store architecture, it still is considered a 'RISC' chip.
x86_64: load 64 bit constant 1 instruction = 10 bytes to load an 8 byte value
You mean one instruction that the program issues. A modern 'CISC' chip (such as the x86_64) accepts the one instruction; that doesn't mean that only one instruction is executed, and that only 18 bytes of memory get used to perform the operation. The CPU has to then translate the programs 'instruction' into the actual instructions that the CPU executes, using a much larger number of internal registers (and memory) than is visible through software. The PowerPC (and to a greater extent, VLIW chips) expose this to the software level. But just because an x86 doesn't expose this to the developer doesn't mean that it isn't happening.
Of course, this isn't as apparent with an operation as simple as 'load'. It (rapidly) becomes apparent the moment you start using instructions that do a load, operation, store, (and more!) all in one instruction.
Which brings me back to my point of hardware being forced to do things that the compiler should have been doing in the first place. There's nothing like having to translate each 'input' instruction into multiple real instructions to be executed.
It's funny hearing compiler guys complain about how woefully hard it is to create a good optimizing compiler for ; yet the same group will gleefully throw the task at hardware designers and tell them that it's much easier to handle the same code optimization in instruction decode.
Riight. Let's compare the difference in resources a compiler has to toss at a problem, and compare that to what a subsystem within the CPU die has. It's also quite wonderful to hear people who have no clue how to design silicon telling hardware guys that they need to take a compiler class (something most 'new' silicon designers do, in fact, take).
Don't complain about how hard it is to make an optimizing compiler, until you've been tasked with designing hardware to do the same job -- the difference being that the compiler has megabytes of memory and all the time it needs, wheras the hardware has a few bits, and a few hundred picoseconds.
Yes, there are some (and they are few) optimizations that really are only doable on the CPU core -- but there are far, far too many optimizations that should be done at compile time, that the CPU has to optimize/schedule/re-order instead.
You forgot to mention the emnity of those who enjoy Radio-Controlled hobbies (be it R/C Aircraft, cars, boats, robots), whom are also not small in number.
Re:Not Insightful or Interesting
on
How Ice Melts
·
· Score: 1
Man, you gotta be hating that post...
Then you get modded as 'informative' for informing the clueless that you were joking.
You forgot to mention that the 'Soft Updates' vs. 'Journaling' argument ends in a draw most of the time anyway; both have strengths and weaknesses, and there's a tremendous amount of overlap in the end result. The difference isn't exactly earth-shattering. It's almost like the AltiVec vs. SSE vs. 3DNow! arguments; each has strengths and weaknesses.
How about virtual channels on a sound card? I do not need to run a software multiplexer to run multiple applications on my sound card with FreeBSD.
Think about this carefully; Either the sound card handles multiple sources in hardware, or you must be using a software multiplexer to handle multiple applications.
Just because you haven't been exposed to it doesn't mean that it's not there.
Personally, I choose to spend a few pennies more for hardware that doesn't require software multiplexing; and after I've done that, it doesn't matter what OS I'm running.
On a side note, I recall that the sound systems in FreeBSD and Linux are of a common origin: The 'old' Open Sound System was the standard for Linux audio, and as I recall, the same was true of FreeBSD.
And one company did the development for many of those first drivers: 4front technologies.
So go ahead and gloat about FreeBSD's audio; its roots are the same as that in Linux.
Just because the IETR gets funding doesn't mean that other forms of energy development is going to even slow down.
It's not only possible, but desirable to fund many different energy projects; simply trying to throw more resources at any particular problem doesn't necessarily mean that it will get finished any faster.
The greenpeace argument depends on the belief that somehow all scientists are equal, and you can take any metallurgist, and he'll magically be an immediate expert in nuclear physics. The fact is that each area of energy development is highly specialized; taking decades to learn the dicipline; you can't just take the people working on the ITER and move them to solar power, and expect them to work their best; first you insult them by telling them their life's work is worth nothing, then you force them to do something they don't like.
It would also have a terrible effect on scientific morale; why start a promising new branch of research at all; you won't be able to prove your theories anyway!
Even the worst fixed-wing hangar queen doesn't need near the maintenance of its helicopter equivalent.
Isn't that redundant? Isn't the equivalent of the most maintenance-intensive aircraft therefore the most maintenance-intensive helicopter?
Not that the meaning is lost: The most maintenance-intensive airplane still doesn't need much compared to a helicopter that needs the least maintenance.
Which also brings up why a helicopter needs more maintenance: Unlike an airplane, a helicopter is several thousand parts trying despearately to get away from each other.
I'm not going to argue with your points; they are fairly good ones. I'll not bother talking about the merits of a BSD based firewall vs. a Linux one, because such conversations generally degenerate into territorial pissings.
If a user knows how to run and setup a Linux firewall, it's a better idea to stick with a Linux firewall; the 'superiority' of BSD over the Linux solution is arguable at best; however one thing that should be beyond argument is that if you know how to set up and use a Linux firewall, you're better off making use of that experience/knowledge than you would be making a frenzied (and quite possibly poor) firewall by using the BSD tools improperly.
After that, if you are so inclined, learn to implement a firewall using one of the BSD's.
And, of course, the reverse is also quite true.
But I'm suprised I haven't seen anybody mention 'shorewall' (at least on the Linux side)
Well, at least free for-profit media, like ZDNet and CNN Online. Most blogs, etc are run at the cost of the blogger. Microsoft pays for their own site, and doesn't resort advertising as a means of funding the website. (Sure, they have ads for their own products/services, but since they are paying themselves to put their own ad on their own site, the money never leaves the company.)
The NY Times has a for-fee service. So do many, many other publications.
And I already pay to receive Slashdot without ads. (As well as to support./) I don't have to donate to Slashdot; I choose to support SlashDot.
The fact of the matter is that there is a large (and growing) market where people are willing to pay more for a product and/or service just to avoid advertisements.
And the advertising world is reeling in horror to find that more and more people are actually paying the publishers to keep advertising out of their product. They simply cannot understand that the public does not want to receive 'exciting new offers' from 'partner compnaies'. They are at the receiving end of a very public slap in the face, as an increasing number of consumers tell them their presence is neither desired, appreciated, or even tolerated.
The market is working fine -- people are paying to have ads removed, which is exactly what the advertising agencies dissaprove of. What makes things even worse is that many informed individuals are removing the ads without paying the publisher. -- And, of course, they spread FUD that it's the beginning of the end of the 'free' internet, something that isn't going to happen -- the fact is that the internet 'media' market itself is going to change, and the 'for-profit' news media may no longer be 'free', but I imagine it will lead to the adoption of blogging as a source of the kind of information that the traditional 'for-profit' agencies currently hold.
And the transition is already currently underway. The fact is that the consumer is voting with their pocketbooks; they are voting against advertising, and media megacorporations.
So the advertisers are doing what they know how to do-- spread disinformation that is a partial-truth at best, while making every effor to ignore/distract from any fact that doesn't mesh with their carefully-crafted propaganda.
The primary thing being there's a difference between being 'perfectly good' and being 'outstanding'.
Firefox is a decent browser, better than IE.
But Opera is a better browser, so much so that I had no problem paying for it, and getting my money's worth out of it.
With FireFox and IE, you get what you paid for; and considering neither cost anything, it's not difficult. (Never forget Microsoft offered IE for zero cost from the beginning).
With Opera, you also get what you pay for. Sure, it costs more than 'zero dollars', but you get more too.
But I certainly don't approve of cookies from advertisers that never expire (well, not in my lifetime, at least). I don't like them keeping stats on what pages I view; I don't care for 'targeted' advertising.
I certainly don't approve of cookies that note that (hypothetically), I've been looking at Toyota's web site, and stragely enough for the next week I get Honda propaganda banner ads.
I honestly view advertising as propaganda; an almost-truth whose point is to twist the reader's perception of reality.
And I'm even more sick of 'Marketers' who think that I'm some kind of brainless ATM machine they can just make withdrawls from.
Case in point: I will never buy or use a product that is advertised via SPAM. I will never use a credit card from a company that fills my mailbox with an application I did not specifically and explicitly request.
When I want to refinance some sort of loan, I will go to a bank or credit union -- one that doesn't jack up my rates by advertising constantly. It's definately not something I'd even consider doing in any way other than 'in person'.
I also take a perverse pleasure in how much money advertising and/or 'marketing' is spent trying to get me to buy something I don't want and don't need.
For that matter, I usually take technical specifications with a sizeable grain of salt -- and usually find myself justified by how overstated they are; polluted by marketers.
Even 'consumer' sites (like the Consumer's Union, which publishes Consumer Reports) that claim to never take advertising money, or reduced cost items for testing -- have rather obvious biases. Case in point: Honda makes high quality products; there's no doubt of that.
But looking at the 'reporting' offered, it seems plausible that if low-grade ice cream were to have a Honda logo slapped on it, the reviewers would find the ice cream to be higher quality than Ben & Jerry's; you just have to get used to chewing on the chunks of ice, and the rancid smell it has.
And, like I said -- I have nothing against Honda; it's just that even 'consumer' groups are heavily influenced by marketers, and some companies generate a teflon shell around them -- and an identical flaw that would villify another maker's product will just slide off.
Easy: Dependancy handling is better. Better metapackaging. An utter lack of library conflicts and/or mismatches. Customization of each and every package on the system.
It handles new/old configuration files in a much more sane way than Debian does (which in turn handles config files much better than RPM does). Configuration of the entire system, daemons, library depends, inits, etc. -- considerably better than what SuSE and Red Hat offer, nicer than Debian too. And I haven't even discussed 'slots' -- which lets you install multiple versions of the same package (like gcc, GNOME, KDE, autoconf, whatever), and it allows the user to manage them in a much more sane way, as well as with considerably less effort.
Portage also has more packages, as well as a higher number of those packages that actually work compared with precompiled distros; there's something innately cool about having a distro with a larger software selection than Debian (unstable, which has more packages than stable), SuSE, and various flavors of Red Hat; the icing on the cake is that these packages actually work without any fuss.
I got fed up with binary packages that simply wouldn't work at all; would immediately segfault, library dependancies that were unresolvable, etc. (And this was with 'stable' releases of various distros) While portage doesn't eliminate them entirely, it happens far, far less.
(That is, unless the user happens to think that things like his 'l337' -O7337 --fsuper-l33t-0pt1m1z4t1on will always result in faster, more stable code. But even then -- at least he was able to choose to shoot himself in the face.)
Honestly -- I've had far fewer problems with my Gentoo systems than I have had with any of the precompiled distros; far less frustration, etc. And isn't that why people try out (and switch to) different/new distros -- because they are sick of what they had been using?
Right, gentoo was better and all the people that thought dumping real package management in favor of "make" was a huge step back are obviously just jelous.
Remarkably inaccurate. The complete and total *JOKE* that is RPM and.deb packages is obscene. I maintain and build RPM's professionally; it's all I do every single day. Package management is, quite literally, what I eat and breathe.
I shell into my build machines, and build the packages there; SuSE, Red Hat, Debian, what have you. I tried going back to a precompiled-package based desktop system; that lasted about three days before I canned the whole idea and replaced the binary-package distro with Gentoo. Portage (and Gentoo) is quite simply the most elegant Linux package manager/distro I've used -- And I've used every major distro for the past ten years.
Although I must admit I frequently end up mixing up 'apt-get,' 'emerge,' 'dpkg,' and 'rpm,' among others; I typically use the wrong one (ie. dpkg on an RPM system, emerge on a debian system, rpm on a Gentoo system, etc.)
Frankly, people whining about it taking too long to build a system haven't actually tried it. Just set it to build friday evening before leaving work, come back Monday to a fully-functioning system, configured exactly the way you want it to be. I guess that wouldn't work out well for someone primarily interested in browsing porn or playing video games; but I use mine to get real work done. Any and all updates are rebuilt transparently (ie. low process priority) in the background, usually taking less than 10 minutes per day (gotta keep the computer busy during that lunch break!) The only exception to that rule is when there is a major KDE or GNOME release (which is about every... 3-4 months? Wow! I guess I'll have to let emerge run overnight... And unlike the poor saps using a binary distro, it's built to MY specifications. And I also have no problems keeping my home machine updated -- and it's physically turned OFF most of the time.
The only real downside of running Gentoo is you actually have to know how you want your system to be configured. It's great for somebody who actually knows what they are doing. Gentoo isn't for people who want choices made for them.
So for jealosy-- sure... I guess if you define it in some strange way, I'm jealous of the chains that binary packages force upon their users. I really get upset when I have to wander through a dark, dimly lit cave to look into the prison that RPM and Debian users have.
But mainly, I'm pissed that the prisoners consider their cage 'real package management'. Portage is real package management; in fact, it's a model that most people looking to replace RPM and Debian packages took to; Portage is quite capable of building (and using/handling) binary packages (yes, even RPM's).
But, in the end, I get paid to build binary packages for these users, because they are too stubborn to admit that their beloved package systems, while slightly updated since their conception, are still extremely primitive beasts, little more than a glorified tarball (or CPIO archive). I'm not at all jealous of the other distros. In fact, I pity their users greatly, and want to show them a better way.
Slashdot Mirror
Upon the 4th month, at the stroke of midnight, they will deliver the code.
It's funny to say, but terrifyingly true. I've gotten to the point this seems normal.
Although my boss is growing more and more grey hair these days.
I have add my $0.02
1.) The mainframe guys have cars?!? (I thought they had tractors-- the original 'off-road' vehicle, and still quite relevant).
2.) The Windows crowd doesn't use screwdrivers. (That's what thumbscrews are for.)
Unless you're an irrational fanboy, it shouldn't matter if it's PPC, Intel, AMD, SPARC, silicon, diamond, neural net, or whatever.
Well, we all grow up at some point in time; that's where the 'boy' in fanboy comes from, right?
Although the thought of saying that a particular CPU is a 'gem' would take on a whole new meaning with a diamond CPU.
I can walk into a massive dust devil, spin around like the tazmanian devil in looney tunes, act like it's my spinning that's causing the thing to spin. I'll come out generally unharmed. (Maybe a bit irritated from bits of dust hitting my skin, or maybe a bit of dirt in my eyes and/or nostrils -- but otherwise quite unharmed.)
OTOH, I tend to avoid (and flee from) tornadoes, as there's a high degree of certainty if we were to interesect one another, I wouldn't survive.
the big wins in power savings come not from shrinking instruction decode space, but going to new fabrication technologies and materials and other technologies. you get orders of magnitude savings there, versus a few %. pure "risc" designs (sparc, mips, etc)
I won't argue otherwise; but every microwatt counts (espescially to the embedded world).
And for diminishing returns vs. effort for a RISC design vs. a CISC design -- CISC is intrinsically harder to design (pipelining, decode, optimization, etc.) That's why everything AMD designed from the Athlon to the Opteron are, in their heart, a RISC chip; it's much easier (and therefore cheaper) to pipeline a RISC design. A major argument of RISC was that it's a cheaper/easier design methodology; something that is no less true today. While the proportion of the savings are diminished, the savings are still there.
it is interesting to note that in the most recent generations of chips, x86/"cisc" designs tend to be much smaller, lower power, etc. than their "risc" counterparts. take the behemoth alpha 21364 for example.
Comparing Alphas to Athlons is really quite apples to oranges... it's not even the same market.
When I first read this, I was wondering what you were on; then I read the qualification of 'x86/cisc'. Recent x86 designs are neither CISC nor RISC, (since they are both and neither) so it's inaccurate to call it a CISC cpu. The same is true for PowerPC, SPARC, and just about every other desktop/workstation processor out there.
But I have yet to see a true/fully CISC design that is smaller and has lower power requirements than an equivalent pure RISC design. For that matter, I haven't seen a new and true CISC design in ages. However, the embedded market is dominated with true RISC chips -- precicely because they are smaller, cheaper, and use less power.
Like I've been saying from my first post -- the desktop/workstation and server market is less than 1% of the total CPU market (in both dollars and quantities); the rest are variations of embedded processors, whose market is thoroughly dominated by fairly pure RISC designs.
In terms of die space the instruction decode is vanishingly small compared to everything else.
So thank you for confirming that this 'design win' of RISC is no longer significant or even relevant anymore.
On the original Opteron, Instruction Decode was about the same size as one of the FPU pipelines, or about 10% of the total die space; this is not 'vanishingly small.' Of that, about 75% of the ID was strictly for translation of x86 into 'native opteron.' So that's a 5% power and heat penalty that is entirely unnecessary.
RISC still does have a design win here, and is quite significant -- an extra 15-20 minutes of battery life on a notebook computer isn't unappreciated. It's just that the win isn't as big as its proponents anticipated, largely due to the fact that modern superscalar/superpipelined CPU has multiple (frequently identical) execution units. RISC assumed (quite reasonably, at the time) there wouldn't be such duplication of resources within a single CPU core. Reguardless, that few percent reduction of complexity, size, and power do matter, and does add up when you ship a few million chips.
The other design wins of RISC was in pipelining and promoting(requiring) good compilers -- both of which are the biggest wins of the RISC evolution, and are very, very far from being insignificant or irrelevant.
Yes they can. uops are like "increment program counter" "emit address out the memory bus" "submit read command to memory bus" "retrieve word from data bus into memory bus register" "transfer word from memory bus register into cpu register" etc.
Apparently we're talking a difference between operations and instructions. These are not instructions, they are hardwired operations that tend to use the clock as a trigger. Many (such as the program counter increment) happen with each and every clock tick, and are only overridden with an instruction.
What I was speaking of are what were termed 'RISCops' by AMD -- meaning a CISC instruction like:
add
would be translated into its RISC equivalent for execution in the Opteron's core:
load
load
add
store
Of course pipelining ends up breaking even these down into the operations of shuffling bits into and around registers until the actual 'add' takes place; then moving the result back to a register, which is in turn moved to cache, and if it's really lucky, back to main memory.
The number of operations within the instruction (setting address pins, wait for ready, read data pins, store value in register, etc, etc.) are of course still there. And the number of these operations has only increased with AMD putting the entire memory controller on the die; life used to be so much simpler... just set the pins and wait for the memory controller to do its job...
the die space you "win" with a smaller instruction decode stage doesnt make up for the space you lose having to add enormous caches because of the increased bandwidth your RISC instructions take. save a few % in instruction decode and lose tons of % in added cache to make up for it.
This isn't the problem you seem to believe -- at least not for a RISC design. A VLIW design, however, is another story entirely. VLIW (ie Itanium) != RISC; VLIW needs massive amounts of cache (and bandwidth).
On a RISC chip, the amount of die size increase due to the instruction cache is negligible compared to the die shrink from reduced instruction decode. And in terms of actual usage, instruction caching is a tiny fraction of the space taken; data cache is (overwhelmingly) the majority holder -- and data takes up the same amount of space reguardless of the chip paradigm.
RISC looked very "n3at0" in the late 80s as it appeared CISC was running out of steam, but we learned a lot since then. a lot of the assumptions which were the foundation of RISC design turned out to be not true in the long term.
CISC did run out of steam. Entirely. The only vestigal part of a CISC design that exists today is the programmer's instruction set -- but after the programmer's interface has been passed, everything is entirely in RISC country. A CISC uop is the CPU's RISC core execution instruction. The only place CISC exists is to the programmer -- it doesn't exist at all after the instruction has been chopped up into RISC instrucitons for execution. There is no CISC vs. RISC war; RISC won -- and won so convincingly that the only popular CPU that even looks like a RISC chip anymore is x86 -- but it only looks like a CISC chip to the ignorant who choose to delude themselves into believing that CISC still has relevancy. CISC chips are notoriously difficult (and often impossible) to pipeline; one of the key goals of the RISC model was to make pipelining almost trivial -- which is the biggest reason why nearly all modern chips (including x86) are, at their core, RISC designs (with a bit of circuitry to chop CISC instructions into a series of RISC instructions).
That's not to say that there aren't elements of both; one of the key goals of a CISC design was to have the assembly act much like a higher-level language like C. On other side of the coin, RISC doesn't provide high-level instructions at the assembly level -- the developer isn't supposed to be writing in assembly -- compiling the code from a higher-level language such as C was the intended path for RISC machines. RISC chip design assumes a good, optimizing compiler would generate fast code (so much for that assumption)...
And as for your contention about a RISC instruction being very complex compared to a CISC uop... RISC instructions (such as 'add', 'load', 'store', or 'is greater') can't be made more atomic. The 'complex' instructions of a PPC, MIPS, Alpha, or SPARC processor aren't a RISC instruction at all -- but rather an attempt to provide a way for developers to use the 'new gee-whiz-bang SIMD idea'. Since a RISC chip assumes the use of a compiler, then compilers would have to add support to SIMD operations -- but the timeline to get compilers to support SIMD was so long that the decision was made to make a high-level (CISC) series of instructions and bolt them onto the RISC core; in this way the new SIMD features could be used immediately, rather than years down the road. Considering the time it took compiler developers to support SIMD outside of inline assembly, this decision seems to have been well-justified.
I'm well aware there are few programs that are 100% static and linear. There is a lot to be said for runtime optimization; all I'm saying is there needs to be more done at compiler time instead.
now you want compilers to emit u-ops to make your life easier. and you hardware guys wonder why we call you unhinged?
You realize this argument goes both ways, right? That turf war aside, emiting a 'u-op' as you put it, is exactly what a compiler for a 'RISC' processor does, because there are no u-ops -- this is one of the key characteristics of a RISC processor. It's not like it's something that isn't done; x86 is not the entire universe, or even close to 1% of it. Most of the world's CPU's are a RISC machine, and a RISC cpu's compiler dispatches the equivalent of a CISC u-op.
And it isn't really a case of making my life any easier-- run-time optimization isn't going away. But there are costs involved with doing optimizations at runtime rather than at compile time. First is the consumption of electricity, and there's the closely tied generation of heat from the extra circuitry. It significantly increases the size of the CPU die, the transistor count, etc. In fact, that's the whole reason the RISC methodology came about -- at the time, it was noticed that the instruction decode stage was taking up some-odd 17-20% of the CPU -- and most of those transistors did nothing but suck power and produce heat 99.999% of the time. By making the compiler smarter, and the chip dumber, chip costs, chip complexity, power consumption, heat produced, transistor count, and cost were all slashed -- with no drop in performance.
People care about how long the battery lasts on their portable devices, how hot their notebook gets in their lap, how much cooling is required to keep a rack of servers running, things like that.
Taking that much more effort ONCE at compile time is cheaper (for everybody involved) when contrasted to doing the same optimization trillions of times while executing the program. There are far more negative consequences that come as a result of having the hardware optimize code -- not that it doesn't have its uses (as you stated, not all programs are static and linear); but that doesn't excuse a substantial portion of what is being offloaded to the CPU for optimization.
The Itanium takes the offloading tasks to the compiler a bit too far; you miss out on the optimizations that can really only be done at execution time. Most of the other complexity problems with Itanium compilers are more related to its VLIW design than the Itanium itself; there are few who are familiar with writing a VLIW compiler, because it's a more difficult problem to wrap one's head around.
A pure comiler-optimized execution isn't really a practical thing; but compilers can (and should) be doing more, as they have a much better opprotunity to take a larger view of the code.
The fact is that in either case, the algorithm to implement a given optimization is nearly the same in either case -- The only substantial difference is in its implementation, and the corresponding tradeoffs. Obviously, I believe if a compiler can do the particular optimization, it should be doing it-- not the CPU.
It doesn't take additional energy at runtime if the optimization is done by the compiler. It does require energy each time the optimization is executed during a program's run -- which is fairly non-trivial, espescially over time.
This doesn't matter much to those who will only be programming to a 'PC' plugged into a wall. But for those who make any kind of battery-powered, consumer, or embedded device, the extra energy consumption is a very big deal, as are the extra costs involved with a larger die, higher transistor count, and larger amount of heat dissapated.
Hey, I was talking about Load/Store in general.
Not the problems that the PPC's implementation has.
One favorite is that while the PPC is 'RISC', it has a larger number of instructions than an Opteron; but since 'RISC' is usually slapped on any load/store architecture, it still is considered a 'RISC' chip.
x86_64: load 64 bit constant
1 instruction = 10 bytes to load an 8 byte value
You mean one instruction that the program issues. A modern 'CISC' chip (such as the x86_64) accepts the one instruction; that doesn't mean that only one instruction is executed, and that only 18 bytes of memory get used to perform the operation. The CPU has to then translate the programs 'instruction' into the actual instructions that the CPU executes, using a much larger number of internal registers (and memory) than is visible through software. The PowerPC (and to a greater extent, VLIW chips) expose this to the software level. But just because an x86 doesn't expose this to the developer doesn't mean that it isn't happening.
Of course, this isn't as apparent with an operation as simple as 'load'. It (rapidly) becomes apparent the moment you start using instructions that do a load, operation, store, (and more!) all in one instruction.
Which brings me back to my point of hardware being forced to do things that the compiler should have been doing in the first place. There's nothing like having to translate each 'input' instruction into multiple real instructions to be executed.
load/store is a pita.
Sure, if you're on the software side of the road.
On the hardware side of things, it's GREAT.
It's funny hearing compiler guys complain about how woefully hard it is to create a good optimizing compiler for ; yet the same group will gleefully throw the task at hardware designers and tell them that it's much easier to handle the same code optimization in instruction decode.
Riight. Let's compare the difference in resources a compiler has to toss at a problem, and compare that to what a subsystem within the CPU die has. It's also quite wonderful to hear people who have no clue how to design silicon telling hardware guys that they need to take a compiler class (something most 'new' silicon designers do, in fact, take).
Don't complain about how hard it is to make an optimizing compiler, until you've been tasked with designing hardware to do the same job -- the difference being that the compiler has megabytes of memory and all the time it needs, wheras the hardware has a few bits, and a few hundred picoseconds.
Yes, there are some (and they are few) optimizations that really are only doable on the CPU core -- but there are far, far too many optimizations that should be done at compile time, that the CPU has to optimize/schedule/re-order instead.
You forgot to mention the emnity of those who enjoy Radio-Controlled hobbies (be it R/C Aircraft, cars, boats, robots), whom are also not small in number.
Man, you gotta be hating that post...
Then you get modded as 'informative' for informing the clueless that you were joking.
You forgot to mention that the 'Soft Updates' vs. 'Journaling' argument ends in a draw most of the time anyway; both have strengths and weaknesses, and there's a tremendous amount of overlap in the end result. The difference isn't exactly earth-shattering. It's almost like the AltiVec vs. SSE vs. 3DNow! arguments; each has strengths and weaknesses.
How about virtual channels on a sound card? I do not need to run a software multiplexer to run multiple applications on my sound card with FreeBSD.
Think about this carefully; Either the sound card handles multiple sources in hardware, or you must be using a software multiplexer to handle multiple applications.
Just because you haven't been exposed to it doesn't mean that it's not there.
Personally, I choose to spend a few pennies more for hardware that doesn't require software multiplexing; and after I've done that, it doesn't matter what OS I'm running.
On a side note, I recall that the sound systems in FreeBSD and Linux are of a common origin: The 'old' Open Sound System was the standard for Linux audio, and as I recall, the same was true of FreeBSD.
And one company did the development for many of those first drivers: 4front technologies.
So go ahead and gloat about FreeBSD's audio; its roots are the same as that in Linux.
The flaw of the argument is also quite typical:
Just because the IETR gets funding doesn't mean that other forms of energy development is going to even slow down.
It's not only possible, but desirable to fund many different energy projects; simply trying to throw more resources at any particular problem doesn't necessarily mean that it will get finished any faster.
The greenpeace argument depends on the belief that somehow all scientists are equal, and you can take any metallurgist, and he'll magically be an immediate expert in nuclear physics. The fact is that each area of energy development is highly specialized; taking decades to learn the dicipline; you can't just take the people working on the ITER and move them to solar power, and expect them to work their best; first you insult them by telling them their life's work is worth nothing, then you force them to do something they don't like.
It would also have a terrible effect on scientific morale; why start a promising new branch of research at all; you won't be able to prove your theories anyway!
Yeah; because I'm not guilty of that ;)
Even the worst fixed-wing hangar queen doesn't need near the maintenance of its helicopter equivalent.
Isn't that redundant? Isn't the equivalent of the most maintenance-intensive aircraft therefore the most maintenance-intensive helicopter?
Not that the meaning is lost: The most maintenance-intensive airplane still doesn't need much compared to a helicopter that needs the least maintenance.
Which also brings up why a helicopter needs more maintenance: Unlike an airplane, a helicopter is several thousand parts trying despearately to get away from each other.
I'm not going to argue with your points; they are fairly good ones. I'll not bother talking about the merits of a BSD based firewall vs. a Linux one, because such conversations generally degenerate into territorial pissings.
If a user knows how to run and setup a Linux firewall, it's a better idea to stick with a Linux firewall; the 'superiority' of BSD over the Linux solution is arguable at best; however one thing that should be beyond argument is that if you know how to set up and use a Linux firewall, you're better off making use of that experience/knowledge than you would be making a frenzied (and quite possibly poor) firewall by using the BSD tools improperly.
After that, if you are so inclined, learn to implement a firewall using one of the BSD's.
And, of course, the reverse is also quite true.
But I'm suprised I haven't seen anybody mention 'shorewall' (at least on the Linux side)
that will be the end of free content on the web.
./) I don't have to donate to Slashdot; I choose to support SlashDot.
Well, at least free for-profit media, like ZDNet and CNN Online. Most blogs, etc are run at the cost of the blogger. Microsoft pays for their own site, and doesn't resort advertising as a means of funding the website. (Sure, they have ads for their own products/services, but since they are paying themselves to put their own ad on their own site, the money never leaves the company.)
The NY Times has a for-fee service. So do many, many other publications.
And I already pay to receive Slashdot without ads. (As well as to support
The fact of the matter is that there is a large (and growing) market where people are willing to pay more for a product and/or service just to avoid advertisements.
And the advertising world is reeling in horror to find that more and more people are actually paying the publishers to keep advertising out of their product. They simply cannot understand that the public does not want to receive 'exciting new offers' from 'partner compnaies'. They are at the receiving end of a very public slap in the face, as an increasing number of consumers tell them their presence is neither desired, appreciated, or even tolerated.
The market is working fine -- people are paying to have ads removed, which is exactly what the advertising agencies dissaprove of. What makes things even worse is that many informed individuals are removing the ads without paying the publisher. -- And, of course, they spread FUD that it's the beginning of the end of the 'free' internet, something that isn't going to happen -- the fact is that the internet 'media' market itself is going to change, and the 'for-profit' news media may no longer be 'free', but I imagine it will lead to the adoption of blogging as a source of the kind of information that the traditional 'for-profit' agencies currently hold.
And the transition is already currently underway. The fact is that the consumer is voting with their pocketbooks; they are voting against advertising, and media megacorporations.
So the advertisers are doing what they know how to do-- spread disinformation that is a partial-truth at best, while making every effor to ignore/distract from any fact that doesn't mesh with their carefully-crafted propaganda.
The primary thing being there's a difference between being 'perfectly good' and being 'outstanding'.
Firefox is a decent browser, better than IE.
But Opera is a better browser, so much so that I had no problem paying for it, and getting my money's worth out of it.
With FireFox and IE, you get what you paid for; and considering neither cost anything, it's not difficult. (Never forget Microsoft offered IE for zero cost from the beginning).
With Opera, you also get what you pay for. Sure, it costs more than 'zero dollars', but you get more too.
That's what cookes are actually for.
But I certainly don't approve of cookies from advertisers that never expire (well, not in my lifetime, at least). I don't like them keeping stats on what pages I view; I don't care for 'targeted' advertising.
I certainly don't approve of cookies that note that (hypothetically), I've been looking at Toyota's web site, and stragely enough for the next week I get Honda propaganda banner ads.
I honestly view advertising as propaganda; an almost-truth whose point is to twist the reader's perception of reality.
And I'm even more sick of 'Marketers' who think that I'm some kind of brainless ATM machine they can just make withdrawls from.
Case in point: I will never buy or use a product that is advertised via SPAM. I will never use a credit card from a company that fills my mailbox with an application I did not specifically and explicitly request.
When I want to refinance some sort of loan, I will go to a bank or credit union -- one that doesn't jack up my rates by advertising constantly. It's definately not something I'd even consider doing in any way other than 'in person'.
I also take a perverse pleasure in how much money advertising and/or 'marketing' is spent trying to get me to buy something I don't want and don't need.
For that matter, I usually take technical specifications with a sizeable grain of salt -- and usually find myself justified by how overstated they are; polluted by marketers.
Even 'consumer' sites (like the Consumer's Union, which publishes Consumer Reports) that claim to never take advertising money, or reduced cost items for testing -- have rather obvious biases. Case in point: Honda makes high quality products; there's no doubt of that.
But looking at the 'reporting' offered, it seems plausible that if low-grade ice cream were to have a Honda logo slapped on it, the reviewers would find the ice cream to be higher quality than Ben & Jerry's; you just have to get used to chewing on the chunks of ice, and the rancid smell it has.
And, like I said -- I have nothing against Honda; it's just that even 'consumer' groups are heavily influenced by marketers, and some companies generate a teflon shell around them -- and an identical flaw that would villify another maker's product will just slide off.
Easy: Dependancy handling is better. Better metapackaging. An utter lack of library conflicts and/or mismatches. Customization of each and every package on the system.
It handles new/old configuration files in a much more sane way than Debian does (which in turn handles config files much better than RPM does). Configuration of the entire system, daemons, library depends, inits, etc. -- considerably better than what SuSE and Red Hat offer, nicer than Debian too. And I haven't even discussed 'slots' -- which lets you install multiple versions of the same package (like gcc, GNOME, KDE, autoconf, whatever), and it allows the user to manage them in a much more sane way, as well as with considerably less effort.
Portage also has more packages, as well as a higher number of those packages that actually work compared with precompiled distros; there's something innately cool about having a distro with a larger software selection than Debian (unstable, which has more packages than stable), SuSE, and various flavors of Red Hat; the icing on the cake is that these packages actually work without any fuss.
I got fed up with binary packages that simply wouldn't work at all; would immediately segfault, library dependancies that were unresolvable, etc. (And this was with 'stable' releases of various distros) While portage doesn't eliminate them entirely, it happens far, far less.
(That is, unless the user happens to think that things like his 'l337' -O7337 --fsuper-l33t-0pt1m1z4t1on will always result in faster, more stable code. But even then -- at least he was able to choose to shoot himself in the face.)
Honestly -- I've had far fewer problems with my Gentoo systems than I have had with any of the precompiled distros; far less frustration, etc. And isn't that why people try out (and switch to) different/new distros -- because they are sick of what they had been using?
Right, gentoo was better and all the people that thought dumping real package management in favor of "make" was a huge step back are obviously just jelous.
.deb packages is obscene. I maintain and build RPM's professionally; it's all I do every single day. Package management is, quite literally, what I eat and breathe.
Remarkably inaccurate. The complete and total *JOKE* that is RPM and
I shell into my build machines, and build the packages there; SuSE, Red Hat, Debian, what have you. I tried going back to a precompiled-package based desktop system; that lasted about three days before I canned the whole idea and replaced the binary-package distro with Gentoo. Portage (and Gentoo) is quite simply the most elegant Linux package manager/distro I've used -- And I've used every major distro for the past ten years.
Although I must admit I frequently end up mixing up 'apt-get,' 'emerge,' 'dpkg,' and 'rpm,' among others; I typically use the wrong one (ie. dpkg on an RPM system, emerge on a debian system, rpm on a Gentoo system, etc.)
Frankly, people whining about it taking too long to build a system haven't actually tried it. Just set it to build friday evening before leaving work, come back Monday to a fully-functioning system, configured exactly the way you want it to be. I guess that wouldn't work out well for someone primarily interested in browsing porn or playing video games; but I use mine to get real work done. Any and all updates are rebuilt transparently (ie. low process priority) in the background, usually taking less than 10 minutes per day (gotta keep the computer busy during that lunch break!) The only exception to that rule is when there is a major KDE or GNOME release (which is about every... 3-4 months? Wow! I guess I'll have to let emerge run overnight... And unlike the poor saps using a binary distro, it's built to MY specifications. And I also have no problems keeping my home machine updated -- and it's physically turned OFF most of the time.
The only real downside of running Gentoo is you actually have to know how you want your system to be configured. It's great for somebody who actually knows what they are doing. Gentoo isn't for people who want choices made for them.
So for jealosy-- sure... I guess if you define it in some strange way, I'm jealous of the chains that binary packages force upon their users. I really get upset when I have to wander through a dark, dimly lit cave to look into the prison that RPM and Debian users have.
But mainly, I'm pissed that the prisoners consider their cage 'real package management'. Portage is real package management; in fact, it's a model that most people looking to replace RPM and Debian packages took to; Portage is quite capable of building (and using/handling) binary packages (yes, even RPM's).
But, in the end, I get paid to build binary packages for these users, because they are too stubborn to admit that their beloved package systems, while slightly updated since their conception, are still extremely primitive beasts, little more than a glorified tarball (or CPIO archive). I'm not at all jealous of the other distros. In fact, I pity their users greatly, and want to show them a better way.
Try packing potato chips at Frito-Lay factory for a couple of years because nobody else would hire you.
Getting a job is one thing. Being paid well is another matter entirely; espescially in this job market.