So, I think the community is doing pretty well giving geek-interfaces for geek tools
I think this is a decent segway into the issue of what is "usable", or a "good UI". That term means different things to different levels of computer users. For newbies, it generally means something pretty looking and idiot-proof. That's all well and good if the only people using the box are newbies who don't want to try to change anything, if all they want is a fancy typewriter. Problem is, idiot-proofing removes a huge amount of control from the user. Which frustrates advanced users who want to change something but can't because all the customizability was removed in order to make it "easier to use". That "easier to use" UI is actually harder to use for anything other than the most basic of tasks. But if you throw in a lot of options, you confuse the person who just wants something simple.
I think what we might see, and perhaps *ought* to see, is an emergence of different yet well-designed GUIs to fit the very different needs of very different users. You'll have the traditional Mac approach of making it as simple as possible at the expense of any sort of user control; you'll have the pack-as-much-control-as-possible-even-if-its-ugly- as-hell approach; and probably some syntheses of the two. This way you don't frustrate the computer-illiterate who don't give a damn about how the box works as long as they can type their Word documents and read email, and you don't frustrate the control freaks who don't want or need to have their hand held. Maybe you'll have one interface with two modes - Standard and Advanced - which allow for both extremes.
To address the point made in the article - that Open Source has not been all that successful at interfaces usable by the "average" person, while small companies do it regularly - I think that this may be where commercial involvement in Open Source can be a great boon. The commercial guys are the ones with all the experience in designing user interfaces for the masses. If such companies do the research and contribute good UIs towards the OSS movement, this concern should be quickly taken care of.
you decide - the Unabomber, or Al Gore?
on
Author Unknown
·
· Score: 3
A most excellent site has several quotes that come from either the Unabomber's manifesto, or Al Gore's book "Earth in the Balance". It's suprisingly hard to tell the difference between the two. Give it a try:
The Great Idea (tm) that Transmeta had was that by doing the instruction decode in software, they decouple the requirements of legacy instruction sets from the hardware implementation. This allows them to use the latest and greatest in hardware design techniques, and even change the internal instruction set to get more performance. They then just tweak the Code Morphing software to recognize the new internal instructions, as you mentioned.
The big reason why not to code directly for Transmeta's internal instructions is that you'd have no market share. x86 is around yet almost solely because of the "golden handcuffs" of backwards compatibility.
There's also the fact that if you were to code directly for the VLIW internal instructions, you still need to use the code morpher (that's just the way the chip works), so you probably wouldn't derive any benefit. And even if you could bypass the morpher, then you would be depriving yourself of the optimization techniques the morpher uses to improve performance.
Taking this further, Transmeta *could* release a "static" external instruction set that the Code Morphing software translates into whatever the current native set is. Then we don't need other architectures *at all*. All we need is to use this static external instruction set. We don't even have to worry about being compatible with future releases of Transmeta, since the Code Morphing software takes care of that.
1.What Transmeta is doing isn't truly emulation, at least as it is traditionally known. In, say, a Pentium III, the chip uses hardware to decode x86 into a series of internal RISC-like operations. This decoder hardware is a huge beast, taking up a tremendous percentage of the overall silicon and is responsible for most of the power consumption issues. In Crusoe, however, Transmeta moved most of the decode functions to a low-level software layer. Which, being software, has the *potential* to inhibit performance, though saving power. However, they suddenly don't have this huge hardware decoder to deal with, and so can devote that silicon to extra execution units (integer, FP, etc). Which will help increase performance significantly. Whether this is {enough/not enough/more than enough} to compensate is an interesting question, which I don't really think any of us have enough info to truly answer just yet. Also keep in mind that the decode hardware a la PIII can have a negative effect on the sorts of clock rates you can achieve, so moving it to software may help with that as well. Complex decode hardware also forces a larger branch penalty in case of a branch misprediction.
2. Not only can they devote extra silicon to execution rather than simply decoding, but doing the software translation to native VLIW adds further performance benefits. The first of which is this: it allows Crusoe to perform optimizations on the incoming code which would be impossible with a purely hardware chip.
One of the biggest of these is dead code elimination. x86 compilers commonly save a variable out to memory, then load it back in shortly thereafter - this is because of the very limited number of official, or "architected" x86 registers. The compiler thus ensures that it always has the correct register values. Much of the time, though, the load is unnecessary because the register wasn't modified (the compiler was just being conservative). Transmeta's Code Morphing software can detect these situations and actually remove unneeded loads, something that no purely hardware solution can match. And loads tend to be a big performance inhibitor; due to the long memory latencies, as well as the fact that loads typically start long dependency chains, where subsequent instructions require the load to finish before they can start.
There are several other compiler-like tricks that the Transmeta software can (and does) perform in realtime (and with runtime data that compilers don't possess) that can greatly speed up the performance of code.
3. Also, consider this: traditional x86 chips have had to decode instructions every time they execute. This is a pretty big overhead. Crusoe actually caches intructions in decoded, optimized form in a hardware "translation cache". This means that while yes, you do a software decode once, which could be slower than a hardware decode, you only have to do it that one time, versus every time with hardware decode. Thus the cost of software decode is amortized over many many cycles, and might actually be more efficient than hardware. (think about it: 99.99% of the time you're going to be executing native, optimized VLIW instructions coming from the translation cache. Only the remaining small bit of time do you actually have to decode).
4. There is also something to be said for the fact that this chip is targeted at the mobile arena. It's not meant to be the desktop/server powerhouse. The needs of mobile consumers are different. Mobile uses typically use only a small fraction of the processor's capabilities, so even *if* the Transmeta chip was slightly less strong on benchmark performance vs a PIII, it's overwhelming superiority in power consumption still makes it a big win, since you can't notice the slight performance difference anyway. Probably the most taxing thing you might do with the laptop is play DVDs or something similar, which the benchmarks show Crusoe handles just as well as a PIII - and at a fraction of the power.
Oh, and just as a side note: CISC instructions are most certainly not "relatively quick to translate". One big reason behind Crusoe's existence is that CISC decode/translation is a difficult, long-latency operation, that uses a lot of hardware. Mostly because of the variable-length instructions, which forces the processor to use a largely serial decode process. Which eliminates the primary advantage - parallel processing - of hardware. Said decode hardware could be put to better uses. MMX/3DNow instructions are probably easier to translate, being a newer, cleaner extension to the instruction set. Execution may very well be more difficult than standard x86, but the translation itself shouldn't be that bad.
I think a lot of it comes down to lack of role models. I mean, think of it, how many female geek heroes do you have?
I'm not so sure that the lack of women is because of a lack of role models. Now, I'm not female, so I can't really speak for women. But, as far as myself, I didn't get into computers because I saw some "geek role model", and think "oh I want to be like them". I got into computers at first because I thought they were fun, and decided to go into comp. engineering because it was interesting and I thought I could do some cool stuff with that. My reasoning was based on what I might be able to do and what I'd learn; not who else was doing the same things (and to be honest I never really knew much of anything about anyone in the field until after getting into college).
I think it may be a "boys and their toys" kind of thing that interests a lot of guys in computers. Most of the guys I've talked to in computer engineering say it was games that first got them interested. Problem is most of the games are oriented towards guys, so I don't know if girls get as much exposure to doing interesting things on the computer at an early age. With the emergence of online chat and all, maybe that will help girls get more interested early, so they will consider computer fields as career options(most of the online chat fans I know in RL are women, not men). Or maybe some other "killer app" will emerge.
and many times the first child is the hacker (not just in a computer sense).
this may have more to do with personality (and the desire of the first child to please the parents and the second not to be like the first
I think you're right on with that...a lot of firstborn ppl I know tend to be like that (including my family, where I, the oldest, am into computers; my sister, the second oldest, has no interest whatsoever; and my brother, the youngest, has some interest)
There may also be a societal thing at work here. There's this saying "boys and their toys" which I've heard a lot of females toss around when guys get around tools, electronics, etc. I think the same thing happens with guys and computers - it becomes a toy for a lot of us (which is how a lot of the comp. engineering students I know came to like computers - thru games). Maybe some of the girls out there see the guys messing with it and come to associate it as a guy's toy (especially with all the guy-oriented computer games out there), and thus something they probably wouldn't be interested in (without giving it the proper chance to see if they'd actually like it?)
something HAS to be done when 20 Million people work this way, and yes, it needs to be regulated.
Just because lots of people work from home does NOT mean it has to be regulated. OSHA has its value, and its place, but the home is not that place. Government is there to protect people from each other, not to protect people from themselves. If someone wants to have an ergonomically incorrect home, such is their right. This isn't the same situation as, say, an office building, where the location/equipment is provided by the employer and you have to work there. If the employee choses their home over an ergonomically safe workplace, then that is their choice and the government has no business causing trouble. I think OSHA realized they'd just be creating a mess, rather than actually helping workers, and so decided not to go with the proposal.
If OSHA were to do what they had proposed, it would have been bad for both employees and employers. Employees would have to have their homes invaded to make sure everything was ergonomically correct, etc. Employers would have to do these checks to prevent frivolous litigation, and nobody would be any better off.
I wonder where all the pressure came from. Citizens? Or the business lobby? Given the fact that the two politicians that were quoted were Republicans, it must have been mostly from the business side. If you doubt corporate power, getting this blown away in one day should make you think otherwise.
The pressure probably came from both. I know if I were telecommuting (which is a distinct possibility once I graduate from college) I wouldn't want to have to deal with all sorts of regulatory crap just so I could work in my own home. I'm sure businesses didn't like the idea either.
And on a tangential note, the fact that the politicians were Republicans does not mean that the pressure was from business. Many Republicans would oppose it simply as part of their opposition to excessive government regulation.
Oh, and just FYI it wasn't blown away in one day. It's been several weeks since the proposal was put out.
John said that if OS X lived up to its promise, he would adopt it as his primary OS for development and general use.
It appears it has. He is obviously very happy with it and the next id game will be written for the Cocca API and will only run under OS X with no backwards compatibility.
This is not a good thing for Windows, but great news for 'nix users and Mac gamers everywhere.
Actually, the deal is that the future id games will still support Windows, Linux, etc. The difference is that the only *Mac* operating system that will be supported is OS X (so OS8/9 users would have to upgrade to run the next id game).
Think about it: id isn't going to throw away its primary source of revenues - Windows games.
Not necessarily...I for one am not convinced that the AC is a Linux user (he/she very well may be, but not necessarily). I know longtime Mac users (read, MacOS, who don't run linux because they don't like the UI) who bitch about the sole mouse button thing. The reason being this:
Sure, MacOS will work with just one mouse button. It was designed such that one mouse button is all that is *necessary*. But for contextual menus, this requires the pressing of a key while clicking. This is the sort of thing *better* done with a second mouse button, rather than requiring the user to reach for the keyboard and perform two tasks at once. That way, ppl with one button can still do it the old way, but those with two buttons don't have to.
So, yes, you only *need* one button, but two makes life (or at least, MacOS) a little easier.
As a bonus, two buttons make it a little easier on converts from Windows or other multi-button environments. However, this is just a bonus, not the reason for thinking Macs should come with a second mouse button.
An aside: I find some of the Slashdot response interesting. We're a bit schizophrenic. We are bananas about privacy issues and here is the state taking aciton against a company that makes a device that is used to illegally violate privacy and we, er, go bananas!
I don't think it's schizophrenic at all. Slashdotters are "bananas" about privacy issues, and also about the state raiding a legitimate store. I think the reason is that the two issues are but different facets of the same coin: freedom. Privacy is a form of freedom - freedom to communicate with whoever you wish in private, and freedom to conduct personal matters without intrusion from the state or others.
Similarly, there is a feeling that people should have the freedom to conduct a legitimate business without having to worry about the government raiding them, totally disrupting their business, on the *suspicion* of misconduct (and since there has been no evidence presented to the/. readers of any wrongdoing by Ramsey, merely a claim by the government, the assumption is that little or no real evidence exists).
And not simply that, but that the state is under no legal obligation to make amends to you for lost business if the state turns out to be wrong. They simply return the seized items years later, when they are useless, and you, who have committed no crime, are most definitely screwed. There is a certain fairness issue here. At least when the goverment seizes property to say, build a highway, they are required to give you fair compensation. With these search and seizures, there is no such thing. And I think that's what bothers a lot of people, is that innocent people have no recourse when they find themselves in these situations.
While this is a travesty, it is also why companies should always have a couple of backups, and at least one off-site.
Still, the point is that one shouldn't have to create backups for the sole purpose of avoiding getting screwed by overzealous feds.
Remember, kids: The feds aren't omnipotent. If you squirrel away enough backups, they won't be able to grab them all and you can get back into business with a few emergency sub-$1000 computers from Best Buy. The feds almost never look for off-site backups.
But still, they might look.
Of course, the issue here is that the devices being sold were illegal under US law. If you don't like the law, that's one thing, but criticising law enforcement is like criticising fire for burning down your house after you left those candles burning.
It has not been established that Ramsey et al. were selling any illegal devices, merely that the Feds *suspect* they were, and seized various items. The criticism is not for the agents' carrying out of the law, but, as I see it, for two things. The first problem is the inappropriate manner in which they handled the situation, and the second is the law itself. The agents are at fault for the first, but clearly not the second.
It's ridiculous that they would not allow the proprietor of Ramsey to tally what was being seized at the time. There is no legitimate reason for the feds to refuse that basic request. Allowing it does no harm to the fed's case, nor does it interfere with the seizure. It does, however, allow the business to know what was taken, and to have documentation of the event. The only reason the feds would have to deny this request is if they knew they were acting improperly and wished to deny the accused evidence that could be used in a subsequent lawsuit against the feds. That, or the agents were just being assholes.
I also think that for such seizures, the judge who issues the search warrant ought to appoint an attorney, who will accompany the agents to the location to be searched. Said attorney is then responsible for informing the accused of their rights and acting on their behalf during this process (since clearly the agents are not acting in the accused's interests, and since chances are the accused doesn't have a lawyer on hand at the time of the raid). This might help prevent some of the abuses.
Almost all civil law could be rewritten in a single sentence, with a massive improvement to the legal system and corresponding improvements in accessibility, affordability, fairness and justice:
It is a breach of civil law to commit any act against another person which most reasonable people would consider to be unacceptable, and the person who commits that act may be required by a court of law to pay reasonable compensation to the person they have wronged.
One big problem with this sort of solution is that the law becomes even more arbitrary than it is. At least with the current system (convoluted POS though it may be) the laws are for the most part spelled out. This allows one to at least have some potential of knowing what acts are legal and what not. With a system of what "most reasonable people would consider unacceptable", you have no way of knowing if a given action is within the bounds of law until you do it, and someone takes you to court. What seems perfectly reasonable to one person may be totally inappropriate to another. There are obvious instances of this - controversial issues such as abortion, affirmative action programs, gun control, teaching of evolution in public schools, etc. Even relatively non-contentious issues often have quite a bit of interpretation that varies widely between individuals. Your solution would create a system in which nobody was really sure what the law was, and would likely be abused.
Furthermore, such a system would be inconsistent. It would be inconsistent between different areas/groups of people, as different groups of people have different ideas. Your trial would now depend much more heavily on who you got on your jury - as now, the jury is not simply acting as a decider of whether your actions were against a predefined piece of law, but rather are defining the content of the law as they felt it should be. It would also be inconsistent in time - what was legal yesterday may suddenly be illegal today with a shift in public opinion (which can be rather fickle at times). One of the strengths of the legal system we have is that it is relatively stable, and there are defined methods of changing the law should one have a problem with it. Your solution would lead to what is basically mob rule.
Also, how would your solution provide equal justice to all, even in theory? It would be awfully difficult, if not impossible. For example, it would effectively eliminate the separation of church and state, as the law would now be heavily dependent on the religious views of whatever group happened to be your jury and judge.
There are simply too many problems with the sort of solution you offer. The law needs to be specific enough that its intent is clear, and to ensure consistency and fairness.
Could AMD theoretically place a different frontend on the Athlon to make it a PPC chip?
Presumably so. The decoder might actually be simpler than the x86 one. Doing so would likely require some modifications to the back end also (even though the CPU works in internal ops, it has to write results to memory of only whole x86 -or in our theoretical version, PPC - instructions, not these ops. After all, what does having executed half an instruction mean from the program's point of view?) Though, if you did this then the Athlon is still essentially hindered by having to do a PPC->internal op translation. Plus, the choice of what to put in your core depends on what sort of code you expect to be running. It could be that PPC code has different characteristics than x86, and so the core should be modified to be more efficient at running PPC...you can see this could end up becoming more of an entire redesign rather than just "slap-a-different-front-end-on-it". But if you don't care about efficiency quite so much, the modifications to run PPC might not be all *that* terrible.
And, is this the type of idea that the Crusoe processor is going to have - i.e. modulating the frontend on a chip so it can run many architectures?
Essentially. The difference (AFAIK, as Transmeta hasn't officially said anything yet) with Crusoe is that it consists of a hardware part and a software part. The software part is responsible for decoding the instructions and telling the hardware what to do. The presumed benefit is that since the decoding is in software, it can be programmed to handle any instruction set pretty easily; and that this means you don't have to spend tons of transistors on complex decode logic like in the Athlon. So Crusoe should be less expensive to build.
However, software is normally slower than hardware. Transmeta's bet is probably that the savings in the decode logic will allow them to make the chip faster, offsetting the performance penalty of doing software-decode. Also, not having all that decode hardware should decrease the power consumption of Crusoe as compared with the Athlon and similar chips. Transmeta has hinted that Crusoe will be aimed at the mobile computing market, so this makes some sense.
If we're discussing the Win9x vs MacOS "reliability' issue, in my experience Windows has actually been pretty stable (uptimes easily a few weeks, which is as long as I've gone without booting to whatever other OS I may have installed at the moment...typically NT or Linux). Well, I should say Win95 OSR2 or Win98 are pretty stable...the original Win95 was so damn buggy it was ridiculous. Whenever I've used MacOS (most recently, running 8.6) I've had lots of stability problems, to the point that I swear Macs just hate me:-p
But then, there is the configuration factor you mentioned at work here too. My Win98 machine is pretty solid, with not too many modifications from standard setup. The Macs I use (for some of my music classes at school) may or may not be set up all that well, as I have no idea of the competence, or lack thereof, of the Mac admins.
I personally wonder how much of the grief that gets blamed on Windows is due to Windows, and how much due to poor quality hardware. On machines with quality components, I've rarely had any sort of troubles with Windows. Things start getting shaky once you start with some of the really cheap hardware, though, in my experience. I do have to give M$ credit (*gasp*) in the sheer volume of supported hardware they have, and yet maintain a reasonable level of stability.
Apple does have the advantage of a relatively small set of hardware to support. So I would hope they would be able to get a decent OS on it:-) OS X does seem like it might actually be pretty good, though I haven't had the chance to use it a whole lot.
It is true that the PPC has condition code registers, and that having more than one is better than just having a single CC register. But...
The thing that one should note is that, from a CPU design point, condition code registers are often a Bad Thing(tm) - as are instruction "side effects" in general (condition codes being one example). Particularly with superscalar, out-of-order CPUs. They add complexity to the processor's attempts to re-order instructions on the fly. This is in part because the CC regs tend to create additional dependencies between instructions, and often the CC register(s) become a bottleneck. Also, when the CPU tries to reorder instructions, it has to worry not only about whether the reordering will clobber a needed result, but also whether a moved instruction's side effects will do something unintended (ie the moved instruction changes the condition code, and so may not be able to be moved without upsetting the code semantics). These factors tend to constrain the CPU's out-of-order execution unnecessarily, leading to less optimal performance.
Most processors try to avoid CC regs, since they are a centralized resource that can easily become a bottleneck when multiple compares come close together. For example, MIPS (as most RISC CPUs) doesn't use CC regs; if you want to check a condition, there is a compare instruction which will set the value of an integer register. Since said integer register can be any of the many integer regs, rather than a small set of particular registers, there generally aren't the bottlenecking problems like with condition codes. Condition codes are really a CISC-ish thing anyway, and in general RISC processors avoid them.
Adding additional CC registers helps somewhat with loosening that bottleneck, but is really a bit of a kludge around a nasty instruction set artifact in PPC. Not exactly something you'd want to "retrofit" onto an x86 CPU (which has more than its share of nasty instruction set issues already).
I hate to be the discordant note here, especially with all the great suggestions as to the Top Ten, but...
Has it occurred to anyone else that we may be taking this whole "geek" thing a bit far? I mean, sure, there have been a good number of geniuses, of which many were oppressed or ignored, etc. But it seems as if we're slapping this "geek" label on anyone who made a name for themselves in a non-"popular" area. Especially if they were ignored at first, or oppressed at some point (which many were). It's as if we're this big self-conscious group looking for validation, saying "hey look! so-and-so-genius was ignored and unpopular, so hey I'm like them!". This, despite the fact that we know so little about the lives (especially of a personal nature) of many of these millenial "geeks". We don't know, and often don't have the information to make a good educated guess, as to whether they would have even agreed with the label.
I guess this kinda ties into what I see as a certain ambiguity as to the meaning of the word "geek" today. You've got some people using it to refer to any unpopular or outcast person; others who use it to refer to just about any intelligent and usually motivated individual; and some who mean some mix of the two. How to know which is meant?
So, my question to you all is, am I making any sense here? Does anyone else see something a little odd in this latching onto every genius and referring to them as a "geek" (whatever that means)? Anyone think I'm full of hot air (if so, do try to enlighten me:-)
(BTW, I'm an engineer not a pyschoanalyst, so forgive any psycho-babble:-p )
So I agree that the RIAA is going after the makers of the tools rather than the users, but c'mon - putting Napster in the same broad category as other file transfer mechanisms doesn't really make a point, does it?
Actually, I believe it does make a point. Napster is designed to help people trade mp3s. This applies to all mp3s, not just pirated ones. While it can be used to commit illegal acts (ie copyright infringement) it is not the sole (or necessarily primary) purpose of the Napster service. There are plenty of legal mp3s out there (and some of them are actually quite good). What the users do with this ability is the responsibility of the user, not Napster. They might use it to trade illegal mp3s, but they may just as well be trading legal ones. Much like the crowbar and crowbar manufacturers. You may use it to smash in someone's head, or you may use it for a legal purpose.
On the other hand, a lockpick is clearly designed with the sole intent of breaking into areas one shouldn't be in. There isn't any real, legal use of lockpicks (at least, not without stretching the imagination). Napster and lockpicks are not really in the same ballpark.
They imply that the speed advantage has something to do with clock-rate, and of course, it has nothing to do with that
Well, it does have *some* to do with it...though the Athlon is simply a better design which accounts for more of the performance increase.
The thing is, for the average Joe (and apparently the author of the article), clock rate == performance. Now, this isn't strictly true, as we know, but since AMD has to sell to Joe it has to play the MHz game by one-upping Intel's clock rates. Which is why the 750 MHz speed is important - psychologically as well as for performance.
He concluded that while the reduced L2 cache speed DOES affect some things, clock rate is way more important. This suprised me, the L2 cache speed reduction affected it very minimally.
Well, this is probably because the Athlons have a rather hefty 128KB of L1 cache...so for most apps your data can easily be held in the L1 (after all, a Celeron has an 128KB L2). Therefore most of the time you're not even going to be needing to access the L2, so the increase in L2 latency won't show up too much.
If the 750MHz Athlon was benchmarked on some server or maybe scientific code (which tends to make more use of the higher-level caches, due to the apps' larger data sets) then we'd probably see a bigger performance hit. The desktop-oriented benchmarks in the Anandtech review, however, don't stress the caches that much.
Exactly right. Basically, the Alpha design philosophy is to get their performance from the clock rate. So they partition the work of the CPU into tiny pipeline stages, which allows really high clock rates. On the other extreme, you get the PPC designers. They decide to do a lot of work each clock cycle. The result is that the amount of logic in each of their pipe stages dictates a much slower clock rate. Modern x86 chips tend to be somewhere in-between in philosophy.
Neither design philosophy is necessarily better than the other, performance-wise. Though going for MHz is better from a marketing standpoint:-)
Certainly, multimedia apps do benefit from caches. I may have given the wrong impression in my previous post (which was rather rushed because I was trying to finish it before I had to go out). If I did mislead, I apologize.
As you have said, certainly the programs that process the data will benefit from the cache. This is true of almost any program one is likely to run, and multimedia apps are no different in that respect.
However, that is less true with some multimedia data. Yes, the data does benefit from a cache. The thing with heavy multimedia use is that the amount of data you have to get to the CPU is so much greater than for most other apps. And the turnover of data is greater. Caches work best with the most localized code and data - ie the stuff that gets accessed repeatedly. Caches are effective because if you access something 100,000 times, and 99,999 of those accesses are from the fast cache and only the first 1 is from the slow main memory, the *average* memory access latency as seen by the program is the cache latency, not main memory latency. Thing is that the multimedia data tends to stay around for a shorter period of time, so the main memory access has a greater effect on the average latency. So maybe the average comes out to 2 or 3 times cache latency instead (still *far* better than no cache, but less effective than the more localized non-media data). Also, the greater volume of data you have to get from memory may mean that the memory just can't supply the data fast enough to the CPU. Improving the bandwidth of the memory can help this (this is the approach Rambus takes), or lowering the memory latency (a la PC133). That's why Intel moved the PII family to a 100MHz bus a while back - the 66MHz wasn't able to supply data to the CPU fast enough. And similarly with the Coppermines moving to 133MHz.
I'm not saying (and didn't say) that the rest of the computer ought to be as fast as the CPU speed. The technical reasons you mentioned are very much going to prevent that. And besides, there's probably a diminishing return as you approach equality between CPU and memory speeds. What I am saying is that in the end you have to try to keep everything balanced, so that no one part becomes too large of a bottleneck. Which means improving I/O speeds as well as CPU speeds.
And just FYI, I'm not into the conspiracy theory thing either:-)
If a computer were only as fast as its (sp) slowest component, then we wouldn't have any need for L1 or L2 or disk cache, would we? Engineers have been working for years to ensure that computers aren't brought to their digital knees by their slowest components.
Sure, engineers have been trying to work around these problems for years, in order to minimize the effect of the slow components on overall performance. For instance, many of the design tricks for CPU design involve trying to mask memory latency (ie caches, load bypassing, load forwarding, etc). But the fact is that you can only do so much to minimize these effects. They still present a bottleneck, and still impact performance. That's why Intel is pushing Rambus, and Via et al. are pushing PC133 SDRAM - because memory is still a significant bottleneck.
And caches as we know them today are only effective because much of the data used in present apps has a high degree of locality - ie the same few pieces of data get used repeatedly, so caches make sense. But the trend is heading towards more and more multimedia stuff. And multimedia (for example, video or audio) tends to have streaming data types - you process the data once, and don't use it again. Thus caches aren't all that effective for a lot of multimedia processing. In order to gain significant performance, memory bandwidth/latency problems need to be addressed.
Of course, one problem is that I/O doesn't get the glory that, say, CPU design does, so you don't have as many people wanting to work on it. I/O has been the neglected child of computer engineering since the days of Seymour Cray (who had some great quote that I can't seem to remember:), and continues to be.
Sure, it would be nice if everything was as fast as the CPU, but that ain't gonna happen
Maybe not. But if you improved the memory speeds by 10%, I'd bet you get better performance than by increasing CPU clock by 10%.
Increasing the processor speed can only gain you so much. Problem is, for a lot of apps, half of the work that needs to be done is I/O, the other half computation. So you get diminishing returns from increasing CPU speeds, because that 50% of the work from I/O isn't going any faster. Even if your CPU was 10^10000 GHz, if you can't get the data to the CPU fast enough, it doesn't matter.
Slashdot Mirror
So, I think the community is doing pretty well giving geek-interfaces for geek tools
- as-hell approach; and probably some syntheses of the two. This way you don't frustrate the computer-illiterate who don't give a damn about how the box works as long as they can type their Word documents and read email, and you don't frustrate the control freaks who don't want or need to have their hand held. Maybe you'll have one interface with two modes - Standard and Advanced - which allow for both extremes.
I think this is a decent segway into the issue of what is "usable", or a "good UI". That term means different things to different levels of computer users. For newbies, it generally means something pretty looking and idiot-proof. That's all well and good if the only people using the box are newbies who don't want to try to change anything, if all they want is a fancy typewriter. Problem is, idiot-proofing removes a huge amount of control from the user. Which frustrates advanced users who want to change something but can't because all the customizability was removed in order to make it "easier to use". That "easier to use" UI is actually harder to use for anything other than the most basic of tasks. But if you throw in a lot of options, you confuse the person who just wants something simple.
I think what we might see, and perhaps *ought* to see, is an emergence of different yet well-designed GUIs to fit the very different needs of very different users. You'll have the traditional Mac approach of making it as simple as possible at the expense of any sort of user control; you'll have the pack-as-much-control-as-possible-even-if-its-ugly
To address the point made in the article - that Open Source has not been all that successful at interfaces usable by the "average" person, while small companies do it regularly - I think that this may be where commercial involvement in Open Source can be a great boon. The commercial guys are the ones with all the experience in designing user interfaces for the masses. If such companies do the research and contribute good UIs towards the OSS movement, this concern should be quickly taken care of.
A most excellent site has several quotes that come from either the Unabomber's manifesto, or Al Gore's book "Earth in the Balance". It's suprisingly hard to tell the difference between the two. Give it a try:
s man/Gore.htm
http://ourworld.compuserve.com/homepages/ken_cros
The Great Idea (tm) that Transmeta had was that by doing the instruction decode in software, they decouple the requirements of legacy instruction sets from the hardware implementation. This allows them to use the latest and greatest in hardware design techniques, and even change the internal instruction set to get more performance. They then just tweak the Code Morphing software to recognize the new internal instructions, as you mentioned.
:-)
The big reason why not to code directly for Transmeta's internal instructions is that you'd have no market share. x86 is around yet almost solely because of the "golden handcuffs" of backwards compatibility.
There's also the fact that if you were to code directly for the VLIW internal instructions, you still need to use the code morpher (that's just the way the chip works), so you probably wouldn't derive any benefit. And even if you could bypass the morpher, then you would be depriving yourself of the optimization techniques the morpher uses to improve performance.
Taking this further, Transmeta *could* release a "static" external instruction set that the Code Morphing software translates into whatever the current native set is. Then we don't need other architectures *at all*. All we need is to use this static external instruction set. We don't even have to worry about being compatible with future releases of Transmeta, since the Code Morphing software takes care of that.
They have...it's called x86
I said there was no text :-)
There's more to consider here...
1.What Transmeta is doing isn't truly emulation, at least as it is traditionally known. In, say, a Pentium III, the chip uses hardware to decode x86 into a series of internal RISC-like operations. This decoder hardware is a huge beast, taking up a tremendous percentage of the overall silicon and is responsible for most of the power consumption issues. In Crusoe, however, Transmeta moved most of the decode functions to a low-level software layer. Which, being software, has the *potential* to inhibit performance, though saving power. However, they suddenly don't have this huge hardware decoder to deal with, and so can devote that silicon to extra execution units (integer, FP, etc). Which will help increase performance significantly. Whether this is {enough/not enough/more than enough} to compensate is an interesting question, which I don't really think any of us have enough info to truly answer just yet. Also keep in mind that the decode hardware a la PIII can have a negative effect on the sorts of clock rates you can achieve, so moving it to software may help with that as well. Complex decode hardware also forces a larger branch penalty in case of a branch misprediction.
2. Not only can they devote extra silicon to execution rather than simply decoding, but doing the software translation to native VLIW adds further performance benefits. The first of which is this: it allows Crusoe to perform optimizations on the incoming code which would be impossible with a purely hardware chip.
One of the biggest of these is dead code elimination. x86 compilers commonly save a variable out to memory, then load it back in shortly thereafter - this is because of the very limited number of official, or "architected" x86 registers. The compiler thus ensures that it always has the correct register values. Much of the time, though, the load is unnecessary because the register wasn't modified (the compiler was just being conservative). Transmeta's Code Morphing software can detect these situations and actually remove unneeded loads, something that no purely hardware solution can match. And loads tend to be a big performance inhibitor; due to the long memory latencies, as well as the fact that loads typically start long dependency chains, where subsequent instructions require the load to finish before they can start.
There are several other compiler-like tricks that the Transmeta software can (and does) perform in realtime (and with runtime data that compilers don't possess) that can greatly speed up the performance of code.
3. Also, consider this: traditional x86 chips have had to decode instructions every time they execute. This is a pretty big overhead. Crusoe actually caches intructions in decoded, optimized form in a hardware "translation cache". This means that while yes, you do a software decode once, which could be slower than a hardware decode, you only have to do it that one time, versus every time with hardware decode. Thus the cost of software decode is amortized over many many cycles, and might actually be more efficient than hardware. (think about it: 99.99% of the time you're going to be executing native, optimized VLIW instructions coming from the translation cache. Only the remaining small bit of time do you actually have to decode).
4. There is also something to be said for the fact that this chip is targeted at the mobile arena. It's not meant to be the desktop/server powerhouse. The needs of mobile consumers are different. Mobile uses typically use only a small fraction of the processor's capabilities, so even *if* the Transmeta chip was slightly less strong on benchmark performance vs a PIII, it's overwhelming superiority in power consumption still makes it a big win, since you can't notice the slight performance difference anyway. Probably the most taxing thing you might do with the laptop is play DVDs or something similar, which the benchmarks show Crusoe handles just as well as a PIII - and at a fraction of the power.
Oh, and just as a side note: CISC instructions are most certainly not "relatively quick to translate". One big reason behind Crusoe's existence is that CISC decode/translation is a difficult, long-latency operation, that uses a lot of hardware. Mostly because of the variable-length instructions, which forces the processor to use a largely serial decode process. Which eliminates the primary advantage - parallel processing - of hardware. Said decode hardware could be put to better uses. MMX/3DNow instructions are probably easier to translate, being a newer, cleaner extension to the instruction set. Execution may very well be more difficult than standard x86, but the translation itself shouldn't be that bad.
I think a lot of it comes down to lack of role models. I mean, think of it, how many female geek heroes do you have?
I'm not so sure that the lack of women is because of a lack of role models. Now, I'm not female, so I can't really speak for women. But, as far as myself, I didn't get into computers because I saw some "geek role model", and think "oh I want to be like them". I got into computers at first because I thought they were fun, and decided to go into comp. engineering because it was interesting and I thought I could do some cool stuff with that. My reasoning was based on what I might be able to do and what I'd learn; not who else was doing the same things (and to be honest I never really knew much of anything about anyone in the field until after getting into college).
I think it may be a "boys and their toys" kind of thing that interests a lot of guys in computers. Most of the guys I've talked to in computer engineering say it was games that first got them interested. Problem is most of the games are oriented towards guys, so I don't know if girls get as much exposure to doing interesting things on the computer at an early age. With the emergence of online chat and all, maybe that will help girls get more interested early, so they will consider computer fields as career options(most of the online chat fans I know in RL are women, not men). Or maybe some other "killer app" will emerge.
and many times the first child is the hacker (not just in a computer sense).
:-) Any thoughts?
this may have more to do with personality (and the desire of the first child to please the parents and the second not to be like the first
I think you're right on with that...a lot of firstborn ppl I know tend to be like that (including my family, where I, the oldest, am into computers; my sister, the second oldest, has no interest whatsoever; and my brother, the youngest, has some interest)
There may also be a societal thing at work here. There's this saying "boys and their toys" which I've heard a lot of females toss around when guys get around tools, electronics, etc. I think the same thing happens with guys and computers - it becomes a toy for a lot of us (which is how a lot of the comp. engineering students I know came to like computers - thru games). Maybe some of the girls out there see the guys messing with it and come to associate it as a guy's toy (especially with all the guy-oriented computer games out there), and thus something they probably wouldn't be interested in (without giving it the proper chance to see if they'd actually like it?)
Just my speculation, of course
something HAS to be done when 20 Million people work this way, and yes, it needs to be regulated.
Just because lots of people work from home does NOT mean it has to be regulated. OSHA has its value, and its place, but the home is not that place. Government is there to protect people from each other, not to protect people from themselves. If someone wants to have an ergonomically incorrect home, such is their right. This isn't the same situation as, say, an office building, where the location/equipment is provided by the employer and you have to work there. If the employee choses their home over an ergonomically safe workplace, then that is their choice and the government has no business causing trouble. I think OSHA realized they'd just be creating a mess, rather than actually helping workers, and so decided not to go with the proposal.
If OSHA were to do what they had proposed, it would have been bad for both employees and employers. Employees would have to have their homes invaded to make sure everything was ergonomically correct, etc. Employers would have to do these checks to prevent frivolous litigation, and nobody would be any better off.
I wonder where all the pressure came from. Citizens? Or the business lobby? Given the fact that the two politicians that were quoted were Republicans, it must have been mostly from the business side. If you doubt corporate power, getting this blown away in one day should make you think otherwise.
The pressure probably came from both. I know if I were telecommuting (which is a distinct possibility once I graduate from college) I wouldn't want to have to deal with all sorts of regulatory crap just so I could work in my own home. I'm sure businesses didn't like the idea either.
And on a tangential note, the fact that the politicians were Republicans does not mean that the pressure was from business. Many Republicans would oppose it simply as part of their opposition to excessive government regulation.
Oh, and just FYI it wasn't blown away in one day. It's been several weeks since the proposal was put out.
John said that if OS X lived up to its promise, he would adopt it as his primary OS for development and general use.
It appears it has. He is obviously very happy with it and the next id game will be written for the Cocca API and will only run under OS X with no backwards compatibility.
This is not a good thing for Windows, but great news for 'nix users and Mac gamers everywhere.
Actually, the deal is that the future id games will still support Windows, Linux, etc. The difference is that the only *Mac* operating system that will be supported is OS X (so OS8/9 users would have to upgrade to run the next id game).
Think about it: id isn't going to throw away its primary source of revenues - Windows games.
Easy to spot the linux folk
Not necessarily...I for one am not convinced that the AC is a Linux user (he/she very well may be, but not necessarily). I know longtime Mac users (read, MacOS, who don't run linux because they don't like the UI) who bitch about the sole mouse button thing. The reason being this:
Sure, MacOS will work with just one mouse button. It was designed such that one mouse button is all that is *necessary*. But for contextual menus, this requires the pressing of a key while clicking. This is the sort of thing *better* done with a second mouse button, rather than requiring the user to reach for the keyboard and perform two tasks at once. That way, ppl with one button can still do it the old way, but those with two buttons don't have to.
So, yes, you only *need* one button, but two makes life (or at least, MacOS) a little easier.
As a bonus, two buttons make it a little easier on converts from Windows or other multi-button environments. However, this is just a bonus, not the reason for thinking Macs should come with a second mouse button.
An aside: I find some of the Slashdot response interesting. We're a bit schizophrenic. We are bananas about privacy issues and here is the state taking aciton against a company that makes a device that is used to illegally violate privacy and we, er, go bananas!
/. readers of any wrongdoing by Ramsey, merely a claim by the government, the assumption is that little or no real evidence exists).
I don't think it's schizophrenic at all. Slashdotters are "bananas" about privacy issues, and also about the state raiding a legitimate store. I think the reason is that the two issues are but different facets of the same coin: freedom. Privacy is a form of freedom - freedom to communicate with whoever you wish in private, and freedom to conduct personal matters without intrusion from the state or others.
Similarly, there is a feeling that people should have the freedom to conduct a legitimate business without having to worry about the government raiding them, totally disrupting their business, on the *suspicion* of misconduct (and since there has been no evidence presented to the
And not simply that, but that the state is under no legal obligation to make amends to you for lost business if the state turns out to be wrong. They simply return the seized items years later, when they are useless, and you, who have committed no crime, are most definitely screwed. There is a certain fairness issue here. At least when the goverment seizes property to say, build a highway, they are required to give you fair compensation. With these search and seizures, there is no such thing. And I think that's what bothers a lot of people, is that innocent people have no recourse when they find themselves in these situations.
While this is a travesty, it is also why companies should always have a couple of backups, and at least one off-site.
Still, the point is that one shouldn't have to create backups for the sole purpose of avoiding getting screwed by overzealous feds.
Remember, kids: The feds aren't omnipotent. If you squirrel away enough backups, they won't be able to grab them all and you can get back into business with a few emergency sub-$1000 computers from Best Buy. The feds almost never look for off-site backups.
But still, they might look.
Of course, the issue here is that the devices being sold were illegal under US law. If you don't like the law, that's one thing, but criticising law enforcement is like criticising fire for burning down your house after you left those candles burning.
It has not been established that Ramsey et al. were selling any illegal devices, merely that the Feds *suspect* they were, and seized various items. The criticism is not for the agents' carrying out of the law, but, as I see it, for two things. The first problem is the inappropriate manner in which they handled the situation, and the second is the law itself. The agents are at fault for the first, but clearly not the second.
It's ridiculous that they would not allow the proprietor of Ramsey to tally what was being seized at the time. There is no legitimate reason for the feds to refuse that basic request. Allowing it does no harm to the fed's case, nor does it interfere with the seizure. It does, however, allow the business to know what was taken, and to have documentation of the event. The only reason the feds would have to deny this request is if they knew they were acting improperly and wished to deny the accused evidence that could be used in a subsequent lawsuit against the feds. That, or the agents were just being assholes.
I also think that for such seizures, the judge who issues the search warrant ought to appoint an attorney, who will accompany the agents to the location to be searched. Said attorney is then responsible for informing the accused of their rights and acting on their behalf during this process (since clearly the agents are not acting in the accused's interests, and since chances are the accused doesn't have a lawyer on hand at the time of the raid). This might help prevent some of the abuses.
Almost all civil law could be rewritten in a single sentence, with a massive improvement to the legal system and corresponding improvements in accessibility, affordability, fairness and justice:
It is a breach of civil law to commit any act against another person which most reasonable people would consider to be unacceptable, and the person who commits that act may be required by a court of law to pay reasonable compensation to the person they have wronged.
One big problem with this sort of solution is that the law becomes even more arbitrary than it is. At least with the current system (convoluted POS though it may be) the laws are for the most part spelled out. This allows one to at least have some potential of knowing what acts are legal and what not. With a system of what "most reasonable people would consider unacceptable", you have no way of knowing if a given action is within the bounds of law until you do it, and someone takes you to court. What seems perfectly reasonable to one person may be totally inappropriate to another. There are obvious instances of this - controversial issues such as abortion, affirmative action programs, gun control, teaching of evolution in public schools, etc. Even relatively non-contentious issues often have quite a bit of interpretation that varies widely between individuals. Your solution would create a system in which nobody was really sure what the law was, and would likely be abused.
Furthermore, such a system would be inconsistent. It would be inconsistent between different areas/groups of people, as different groups of people have different ideas. Your trial would now depend much more heavily on who you got on your jury - as now, the jury is not simply acting as a decider of whether your actions were against a predefined piece of law, but rather are defining the content of the law as they felt it should be. It would also be inconsistent in time - what was legal yesterday may suddenly be illegal today with a shift in public opinion (which can be rather fickle at times). One of the strengths of the legal system we have is that it is relatively stable, and there are defined methods of changing the law should one have a problem with it. Your solution would lead to what is basically mob rule.
Also, how would your solution provide equal justice to all, even in theory? It would be awfully difficult, if not impossible. For example, it would effectively eliminate the separation of church and state, as the law would now be heavily dependent on the religious views of whatever group happened to be your jury and judge.
There are simply too many problems with the sort of solution you offer. The law needs to be specific enough that its intent is clear, and to ensure consistency and fairness.
Could AMD theoretically place a different frontend on the Athlon to make it a PPC chip?
Presumably so. The decoder might actually be simpler than the x86 one. Doing so would likely require some modifications to the back end also (even though the CPU works in internal ops, it has to write results to memory of only whole x86 -or in our theoretical version, PPC - instructions, not these ops. After all, what does having executed half an instruction mean from the program's point of view?) Though, if you did this then the Athlon is still essentially hindered by having to do a PPC->internal op translation. Plus, the choice of what to put in your core depends on what sort of code you expect to be running. It could be that PPC code has different characteristics than x86, and so the core should be modified to be more efficient at running PPC...you can see this could end up becoming more of an entire redesign rather than just "slap-a-different-front-end-on-it". But if you don't care about efficiency quite so much, the modifications to run PPC might not be all *that* terrible.
And, is this the type of idea that the Crusoe processor is going to have - i.e. modulating the frontend on a chip so it can run many architectures?
Essentially. The difference (AFAIK, as Transmeta hasn't officially said anything yet) with Crusoe is that it consists of a hardware part and a software part. The software part is responsible for decoding the instructions and telling the hardware what to do. The presumed benefit is that since the decoding is in software, it can be programmed to handle any instruction set pretty easily; and that this means you don't have to spend tons of transistors on complex decode logic like in the Athlon. So Crusoe should be less expensive to build.
However, software is normally slower than hardware. Transmeta's bet is probably that the savings in the decode logic will allow them to make the chip faster, offsetting the performance penalty of doing software-decode. Also, not having all that decode hardware should decrease the power consumption of Crusoe as compared with the Athlon and similar chips. Transmeta has hinted that Crusoe will be aimed at the mobile computing market, so this makes some sense.
If we're discussing the Win9x vs MacOS "reliability' issue, in my experience Windows has actually been pretty stable (uptimes easily a few weeks, which is as long as I've gone without booting to whatever other OS I may have installed at the moment...typically NT or Linux). Well, I should say Win95 OSR2 or Win98 are pretty stable...the original Win95 was so damn buggy it was ridiculous. Whenever I've used MacOS (most recently, running 8.6) I've had lots of stability problems, to the point that I swear Macs just hate me :-p
:-) OS X does seem like it might actually be pretty good, though I haven't had the chance to use it a whole lot.
But then, there is the configuration factor you mentioned at work here too. My Win98 machine is pretty solid, with not too many modifications from standard setup. The Macs I use (for some of my music classes at school) may or may not be set up all that well, as I have no idea of the competence, or lack thereof, of the Mac admins.
I personally wonder how much of the grief that gets blamed on Windows is due to Windows, and how much due to poor quality hardware. On machines with quality components, I've rarely had any sort of troubles with Windows. Things start getting shaky once you start with some of the really cheap hardware, though, in my experience. I do have to give M$ credit (*gasp*) in the sheer volume of supported hardware they have, and yet maintain a reasonable level of stability.
Apple does have the advantage of a relatively small set of hardware to support. So I would hope they would be able to get a decent OS on it
It is true that the PPC has condition code registers, and that having more than one is better than just having a single CC register. But...
The thing that one should note is that, from a CPU design point, condition code registers are often a Bad Thing(tm) - as are instruction "side effects" in general (condition codes being one example). Particularly with superscalar, out-of-order CPUs. They add complexity to the processor's attempts to re-order instructions on the fly. This is in part because the CC regs tend to create additional dependencies between instructions, and often the CC register(s) become a bottleneck. Also, when the CPU tries to reorder instructions, it has to worry not only about whether the reordering will clobber a needed result, but also whether a moved instruction's side effects will do something unintended (ie the moved instruction changes the condition code, and so may not be able to be moved without upsetting the code semantics). These factors tend to constrain the CPU's out-of-order execution unnecessarily, leading to less optimal performance.
Most processors try to avoid CC regs, since they are a centralized resource that can easily become a bottleneck when multiple compares come close together. For example, MIPS (as most RISC CPUs) doesn't use CC regs; if you want to check a condition, there is a compare instruction which will set the value of an integer register. Since said integer register can be any of the many integer regs, rather than a small set of particular registers, there generally aren't the bottlenecking problems like with condition codes. Condition codes are really a CISC-ish thing anyway, and in general RISC processors avoid them.
Adding additional CC registers helps somewhat with loosening that bottleneck, but is really a bit of a kludge around a nasty instruction set artifact in PPC. Not exactly something you'd want to "retrofit" onto an x86 CPU (which has more than its share of nasty instruction set issues already).
I hate to be the discordant note here, especially with all the great suggestions as to the Top Ten, but...
:-)
:-p )
Has it occurred to anyone else that we may be taking this whole "geek" thing a bit far? I mean, sure, there have been a good number of geniuses, of which many were oppressed or ignored, etc. But it seems as if we're slapping this "geek" label on anyone who made a name for themselves in a non-"popular" area. Especially if they were ignored at first, or oppressed at some point (which many were). It's as if we're this big self-conscious group looking for validation, saying "hey look! so-and-so-genius was ignored and unpopular, so hey I'm like them!". This, despite the fact that we know so little about the lives (especially of a personal nature) of many of these millenial "geeks". We don't know, and often don't have the information to make a good educated guess, as to whether they would have even agreed with the label.
I guess this kinda ties into what I see as a certain ambiguity as to the meaning of the word "geek" today. You've got some people using it to refer to any unpopular or outcast person; others who use it to refer to just about any intelligent and usually motivated individual; and some who mean some mix of the two. How to know which is meant?
So, my question to you all is, am I making any sense here? Does anyone else see something a little odd in this latching onto every genius and referring to them as a "geek" (whatever that means)? Anyone think I'm full of hot air (if so, do try to enlighten me
(BTW, I'm an engineer not a pyschoanalyst, so forgive any psycho-babble
So I agree that the RIAA is going after the makers of the tools rather than the users, but c'mon - putting Napster in the same broad category as other file transfer mechanisms doesn't really make a point, does it?
Actually, I believe it does make a point. Napster is designed to help people trade mp3s. This applies to all mp3s, not just pirated ones. While it can be used to commit illegal acts (ie copyright infringement) it is not the sole (or necessarily primary) purpose of the Napster service. There are plenty of legal mp3s out there (and some of them are actually quite good). What the users do with this ability is the responsibility of the user, not Napster. They might use it to trade illegal mp3s, but they may just as well be trading legal ones. Much like the crowbar and crowbar manufacturers. You may use it to smash in someone's head, or you may use it for a legal purpose.
On the other hand, a lockpick is clearly designed with the sole intent of breaking into areas one shouldn't be in. There isn't any real, legal use of lockpicks (at least, not without stretching the imagination). Napster and lockpicks are not really in the same ballpark.
those SPEC95 numbers you wanted to see:
CPU_____________Clock___int95___fp95
Alpha 21264A____700MHz__39.1____68.1
Athlon__________700MHz__31.8____23.8
Athlon__________750MHz__32.8____24.3
Pentium III_____733MHz__31.5____18.0
As an aside, why doesn't Slashdot allow TABLE tags in comments?! It would make the above chart much easier to write/read.
They imply that the speed advantage has something to do with clock-rate, and of course, it has nothing to do with that
Well, it does have *some* to do with it...though the Athlon is simply a better design which accounts for more of the performance increase.
The thing is, for the average Joe (and apparently the author of the article), clock rate == performance. Now, this isn't strictly true, as we know, but since AMD has to sell to Joe it has to play the MHz game by one-upping Intel's clock rates. Which is why the 750 MHz speed is important - psychologically as well as for performance.
He concluded that while the reduced L2 cache speed DOES affect some things, clock rate is way more important. This suprised me, the L2 cache speed reduction affected it very minimally.
Well, this is probably because the Athlons have a rather hefty 128KB of L1 cache...so for most apps your data can easily be held in the L1 (after all, a Celeron has an 128KB L2). Therefore most of the time you're not even going to be needing to access the L2, so the increase in L2 latency won't show up too much.
If the 750MHz Athlon was benchmarked on some server or maybe scientific code (which tends to make more use of the higher-level caches, due to the apps' larger data sets) then we'd probably see a bigger performance hit. The desktop-oriented benchmarks in the Anandtech review, however, don't stress the caches that much.
Exactly right. Basically, the Alpha design philosophy is to get their performance from the clock rate. So they partition the work of the CPU into tiny pipeline stages, which allows really high clock rates. On the other extreme, you get the PPC designers. They decide to do a lot of work each clock cycle. The result is that the amount of logic in each of their pipe stages dictates a much slower clock rate. Modern x86 chips tend to be somewhere in-between in philosophy.
:-)
Neither design philosophy is necessarily better than the other, performance-wise. Though going for MHz is better from a marketing standpoint
I believe the conversion is 2.2 lbs == 1 kg
Certainly, multimedia apps do benefit from caches. I may have given the wrong impression in my previous post (which was rather rushed because I was trying to finish it before I had to go out). If I did mislead, I apologize.
:-)
As you have said, certainly the programs that process the data will benefit from the cache. This is true of almost any program one is likely to run, and multimedia apps are no different in that respect.
However, that is less true with some multimedia data. Yes, the data does benefit from a cache. The thing with heavy multimedia use is that the amount of data you have to get to the CPU is so much greater than for most other apps. And the turnover of data is greater. Caches work best with the most localized code and data - ie the stuff that gets accessed repeatedly. Caches are effective because if you access something 100,000 times, and 99,999 of those accesses are from the fast cache and only the first 1 is from the slow main memory, the *average* memory access latency as seen by the program is the cache latency, not main memory latency. Thing is that the multimedia data tends to stay around for a shorter period of time, so the main memory access has a greater effect on the average latency. So maybe the average comes out to 2 or 3 times cache latency instead (still *far* better than no cache, but less effective than the more localized non-media data). Also, the greater volume of data you have to get from memory may mean that the memory just can't supply the data fast enough to the CPU. Improving the bandwidth of the memory can help this (this is the approach Rambus takes), or lowering the memory latency (a la PC133). That's why Intel moved the PII family to a 100MHz bus a while back - the 66MHz wasn't able to supply data to the CPU fast enough. And similarly with the Coppermines moving to 133MHz.
I'm not saying (and didn't say) that the rest of the computer ought to be as fast as the CPU speed. The technical reasons you mentioned are very much going to prevent that. And besides, there's probably a diminishing return as you approach equality between CPU and memory speeds. What I am saying is that in the end you have to try to keep everything balanced, so that no one part becomes too large of a bottleneck. Which means improving I/O speeds as well as CPU speeds.
And just FYI, I'm not into the conspiracy theory thing either
If a computer were only as fast as its (sp) slowest component, then we wouldn't have any need for L1 or L2 or disk cache, would we? Engineers have been working for years to ensure that computers aren't brought to their digital knees by their slowest components.
:), and continues to be.
Sure, engineers have been trying to work around these problems for years, in order to minimize the effect of the slow components on overall performance. For instance, many of the design tricks for CPU design involve trying to mask memory latency (ie caches, load bypassing, load forwarding, etc). But the fact is that you can only do so much to minimize these effects. They still present a bottleneck, and still impact performance. That's why Intel is pushing Rambus, and Via et al. are pushing PC133 SDRAM - because memory is still a significant bottleneck.
And caches as we know them today are only effective because much of the data used in present apps has a high degree of locality - ie the same few pieces of data get used repeatedly, so caches make sense. But the trend is heading towards more and more multimedia stuff. And multimedia (for example, video or audio) tends to have streaming data types - you process the data once, and don't use it again. Thus caches aren't all that effective for a lot of multimedia processing. In order to gain significant performance, memory bandwidth/latency problems need to be addressed.
Of course, one problem is that I/O doesn't get the glory that, say, CPU design does, so you don't have as many people wanting to work on it. I/O has been the neglected child of computer engineering since the days of Seymour Cray (who had some great quote that I can't seem to remember
Sure, it would be nice if everything was as fast as the CPU, but that ain't gonna happen
Maybe not. But if you improved the memory speeds by 10%, I'd bet you get better performance than by increasing CPU clock by 10%.
Increasing the processor speed can only gain you so much. Problem is, for a lot of apps, half of the work that needs to be done is I/O, the other half computation. So you get diminishing returns from increasing CPU speeds, because that 50% of the work from I/O isn't going any faster. Even if your CPU was 10^10000 GHz, if you can't get the data to the CPU fast enough, it doesn't matter.