A couple of companies ago, we needed to test some PCI hardware via emulation. The emulation of our board ran at about 1% of real speed (which is actually pretty good for that kind of thing) so we needed PCs in which the other components - CPUs, chipsets, etc. - also ran that slowly. We found a couple of companies that specialize in making the slowest PCs for just this purpose, and they compete very aggressively. "We're slower than they are! You should buy ours!" It was rather amusing.
Less amusing was the fact that they couldn't actually deliver the kinds of systems we wanted (450GX) at a low enough speed. It turns out that trying to turn _down_ the clock involves many of the same challenges as turning it up, and some of the components didn't take well to the low clock speeds. "We couldn't make it slow enough to satisfy the customer."
Yes, I know this would violate the rules of the contest. I also know that I'm a little off-topic, but hopefully this is also funny enough that I'll get to keep my karma points.;-)
As I recall, the QPL owes its current form largely to the uproar caused by the original license among the "gimme free stuff" crowd - who obviously liked it enough to want it, but not enough to pay for it. Would this particular conflict have occurred with the original QPL, or is it an artifact of the pressure to come up with something acceptable to the GPL bigots in the context of still trying to run a business?
I'm not (just) trolling here. I'm genuinely curious whether this is a self-inflicted wound.
>Minimal EXE would not let you tell 'truly compiled' from 'pseudocode+interpreted' approach
True enough, but not quite for the reasons you state. What you need to look at is the executable plus whatever libraries it links to, and how much that increases system memory usage. Some examples:
If a VB executable is statically linked with a large runtime library that could otherwise be shared with other VB executables, it's a hog.
If a VB executable is dynamically linked with a large runtime library but it's the only executable on that system using that library, it's still a hog.
If a VB executable is dynamically linked with a large runtime library that is actually shared with a whole bunch of other VB executables, it's not a hog.
If a VB executable is linked with a small subset of a runtime library, whether statically or dynamically, it's not a hog.
And so on. I think the secondary issue here is what typically happens for VB executables and C executables. On most systems, pretty much everything uses the C runtime, so its memory cost is amortized across a bunch of programs. Another poster has pointed out that VB executables can be dynamically linked to get the same effect in the right environment, which is nice, but that they are often statically linked with a large runtime and are, therefore, hogs. Hogs slow down your system by consuming resources even if they themselves don't seem particularly slow.
Getting back to the original issue, which performs better: Java or VB? I don't know the answer, actually. My point is that the PHBs who complain about Java performance and then use VB don't know either, and that's stupid.
But how efficient are those executables? I can think of several ways to generate an executable from VB:
Just toss the interpreter plus the original code into a "pseudo-executable".
Compile the original code into some intermediate form and toss in an interpreter for that.
Actually compile the original code, and toss in or link to a run-time library.
None but the last approach offers any significant promise of being comparable to the same functionality implemented in C/C++, and even then it depends a lot on the complexity and quality of implementation of the runtime.
One experiment would be to see how large a very minimal VB executable would be: if it's really big, chances are that they're "cheating" and they're probably using one of the first two approaches. I don't use VB myself, or else I'd do the experiment myself and post the results.
This comes as no surprise to me. The advantage VB has over other scripting languages is that it has a reasonable learning curve. People who would rather be focusing on something else can very quickly learn how to do simple stuff in VB, and as their skills improve the language still supports their new needs up to a fairly high semantic level. I know quite a few companies whose basic development methodology is to string OLE/COM/ActiveX components together with VB, and it actually works quite well for them.
For contrast, consider something like C++. This is simply not an appropriate choice as a first language for someone new to programming. People (ab)using C++ without having a decent grasp of programming (particularly modularity/OO aspects) first have caused more pain and frustration for their better-trained fellows than I care to think about. In this group I include the designers of the most common C++ class library - MFC, which by itself has done more to turn people off C++ than even the language's own nastiness could do. This relative inaccessibility explains C++'s place behind VB.
As an aside, is perl a good choice as a first language? Personally, I don't think perl is a good choice for much of anything, but I suspect that even the most ardent perl advocate would admit perl isn't likely to appeal to first-time users. It's not meant to. (Python, on the other hand, would IMO make a very good first or teaching language.)
Java's low position on the list is best explained by three things: its relative youth, lack of proper support for certain types of programming, and performance. The youth issue is pretty self-explanatory. As for lack of support, here are some thoughts:
The first issue is platforms. You'd think you could find a JVM on just about anything, but you'd be surprised. For example, even though an MS JVM exists Windows CE, the manufacturer of the particular device I own (a Sharp TriPad, same as a Vadem Clio) didn't see fit to make that available and I've had no luck finding one elsewhere. So much for Java on that platform.
Support for the latest version of Java is often lacking. Java 2.0 Platform is still pretty much a Windows/Solaris thing even after all this time. Admittedly, this is mostly a library issue, but as long as Sun makes it difficult for someone else to provide equivalent libraries this will remain an issue.
Lastly, while Java may be great for applets, some aspects of Java make it difficult to use for standalone applications of any complexity. In the real world, programmers often need to interface with in-house libraries. The fact that these interfaces are probably C-oriented is a minor issue. The major issue is that Java doesn't provide a decent way to interface to these libraries even if they were also in Java. Stupid.
I think the performance issue is mostly BS. Sure, an interpreted or incrementally-compiled language such as Java will never be as fast as a fully-compiled language, but with modern technology the difference is very small. The weird thing is, the same PHBs who can't get "Java is slow" out of their heads have no qualms about using VB. What's up with that?
>Thanks to Irina Krush. She will take away Garry's title someday.
Not likely. Krush is vastly stronger than any of us, but that doesn't mean she's stronger than Kasparov. Like him or hate him - and I'm not exactly a fan myself - the objective evidence indicates that Kasparov is the strongest player in the world today and probably the strongest ever. Even the loss to Deep(er) Blue doesn't change that, because DB was tuned specifically to play against Kasparov and would fare worse than Kasparov if both were to play in a round-robin with the other 14 top players. It's not uncommon for a less-skilled player to maintain a winning record against one of their betters because of style issues, but it doesn't change their relative strengths.
It's possible that IK could someday be better than Kasparov. In fact, that's highly likely since she's younger and chess ability under tournament/championship conditions does seem to fade a bit with advanced age. What's more interesting is the question of whether IK might someday be the best player in the world[1]. Yeah, it's possible. However, it's also possible that any of a thousand other players - from Anand to Morozevich to Khalifman to Xie Jun - could raise their own abilities and forever stay above her. Remember, they're also highly disciplined professionals capable of analysis just as deep as IK's. Statistically, the chances that IK will ever be the best player in the world are slim.
[1] One of the English chess columnists - Miles, I think - has written a far better piece than I ever could about the difference between being the best player and being world champion. It's somewhere on www.chesscafe.com IIRC.
>We need to commend her on her efforts she put a ton of work into the game! She contributed months and months of painstaking, in-depth analysis. Thanks, Irina!
Absolutely. The above comments about her ability aside, her devotion and passion and work ethic are highly commendable. She did a great job as "team captain" for the world.
>>When the first RISC machines came out, superscalar execution hadn't been invented yet. > >Some processors (Cray for one) had been doing this years before RISC came out.
There's a big difference between vector operations and true superscalarity. Also, RISC vs. CISC only makes sense from the point where instruction sets were truly complex and there was a choice to be made; many early architectures were RISC of necessity.
>Once all those youngsters get older, they will be used to the UNIX paradigm of programming and anyone who's programmed in UNIX will find that the Windows method of doing thing will make their flesh crawl.
Actually, I think this touches on the real reason behind most of the posts here. People tend to think that the way they learned is the way things should be, and hate having to change paradigms - even when the new paradigms are better (and I'm not saying which are). We've all met FORTRAN or BASIC or assembler programmers who think OOP is for wimps, haven't we? Many of the posts here have exactly the same boorish tone, and are equally misguided.
IMO, the mistake is letting people get too comfortable with one model before exposing them to another. Give programmers both UNIX and Windoze, and maybe a third, from an early point. Let them decide which they prefer after they've had a chance to gain some perspective instead of getting them stuck in the first model they learned.
Both the Ars Technica article and the MSU paper to which it refers are very well done, providing an excellent introduction to material covered in greater depth in Hennesy And Patterson's[1] Computer Architecture: A Quantitative Approach.
My one quibble is that the AT author gives the basic performance formula in what I consider an "upside down" form - time/program rather than work/second - which I think makes it harder to understand some of the later points.
Like Ditzel, I pine for a return to the days when true RISC architectures existed. The principles involved haven't really changed, and I think some later "evolution" has been misguided. See my recent posts in the "Intel Athlon-Killer" article for more details if you're interested.
[1] I can never remember which letters in which name get doubled, or which one was at Berkeley and which at Stanford. Apologies for any errors on either count.
>The whole idea with RISC is to make instructions so basic that they can (almost) all be completed in a single processor cycle.
I don't think that's the whole idea of RISC. The basic RISC philosophy, as elucidated most excellently in H&P, is to maximize instructions per second, and if that means a small sacrifice in work per instruction that's OK. Single-cycle execution is probably the most powerful means available to achieve this goal, but there are many others - superscalarity, deep pipelines, reordering, branch prediction, etc. - that apply regardless of how many cycles instructions take.
As happens way too often,/. managed to lose my first response to this, while giving every appearance of having accepted it. *sigh*
>What you describe is essentially the initial MIPS project started by Hennessy at Stanford.
I'm glad someone noticed.;-) Basically I haven't seen much in subsequent processor designs to counter the excellent arguments H&P put forth in their book regarding How It Should Be Done.
>Most delay slots are never filled
Obviously, this can vary a lot, but according to the studies I've seen a single delay slot can be filled with something besides a NOP >80% of the time for most kinds of code. The important thing is that a NOP is no worse than a stall, except that the stall usually has a lot more wasted circuitry associated with it.
Yes, dynamic scheduling can do "better" than static, but at what cost? Does the improvement make up for the additional complexity and limitation of clock rate? More importantly, are there other things that can be done with that real estate which provide even better bang for the buck?
The basic formula for CPU performance, from Hennessy and Patterson, is:
WPI * IPC * CPS
WPI = Work Per Instruction
IPC = Instructions Per Cycle
CPS = Cycles Per Second
Classical CISC architectures tried to maximize WPI, and this limited the other two factors. RISC was mostly intended to maximize CPS, intentionally sacrificing WPI to do so. Pipelining, superscalarity, and branch prediction are all targeted toward increasing IPC in different ways. VLIW and EPIC improve either WPI or ICP depending on how you look at it.
All of these approaches to improving performance tend to have characteristic challenges associated with them. In the current case, you have to deal with the fact that massively superscalar architectures require an instruction stream that keeps all the functional units fed. That means that compilers have to try to resolve data dependencies and competition for functional units, either of which would cause a stall, and also deal with branches which cause bubbles in almost any architecture. It's a very tough problem, which is why chip designers turn to second-order tricks such as speculative/predicated execution and VLIW/EPIC.
Personally, I think that's all a trap because it causes chip complexity to skyrocket and undermines the very idea of RISC. If I were designing a chip, my goal would be to crank the frequency sky-high and make the compiler (or a translating front-end processor such as Transmeta is rumored to be working on) do most of the worrying about how instructions get scheduled. In particular, I'd go for:
A moderate number of moderately pipelined functional units, with fully exposed pipelines including whatever delay slots are necessary.
Instructions that specify the functional unit, without on-chip dependency checking and such. If the compiler screws up and issues an instruction before its operands are ready, tough for them.
Very limited branch hinting. No branch prediction, no speculative execution.
Lots of on-chip cache, because there's no way memory will keep up. If the tag-check logic can't be made fast enough, maybe an explicit stack or scratchpad on-chip.
Moderating the previous post down as "Flamebait" is one of the worst abuses of moderation I've seen lately. I might accept "Redundant" since many others have also commented on the "preemptive vapor" aspect of Intel's announcement, though I think this post does a better job than most of explaining how the trick actually works.
The fact is that only a fool or a lunatic or someone paid by Intel could fail to see that the announcement has nothing to do with delivering a better product to consumers. The goal here is purely to squash AMD, and if AMD filed for bankruptcy tomorrow we would almost certainly never see the promised Intel chip. The amazing thing is that Intel, already under scrutiny from the FTC, would dare do anything so blatantly anti-competitive.
>>Apple controls firewire > >IEEE 1394 is an international standard. It is not controlled by any one company.
Actually, this could stand some clarification. P1394 is an IEEE standard which anyone can use without licensing fees, but "Firewire" is an Apple trademark. That's why Sony, for example, refers to P1394 as iLink instead.
Apple's fees for using the "Firewire" name are IMO justified by their investment in making that name appealing to consumers. Also, their fees are very modest ($1 per unit, IIRC) and above-board. By contrast, the "Intel tax" on USB is just as real and much more substantial, but hidden in the form of additional motherboard component cost. Also, Intel's grip is not just on the name but on the technology itself, which they will never allow to become a true open standard. Intel's idea of openness is to blackmail companies that depend on them for other products into making false shows of "broad industry support".
It's amazing to me that anyone here on slashdot, where people bash BSD and Red Hat because they're not "open" enough, would play into Intel's hands so willingly. Intel is the ultimate proprietary-everything company, worse even than M$.
>Firewire has TONS of gates and takes a lot of silicon to make a chip.
This cost argument for USB vs. Firewire is a total red herring, on two levels:
The price difference is tiny. Let's say for the sake of argument that the circuitry for Firewire is 4x as complex as that for USB2 (and that's an exaggeration). That may require one step up in which ASIC family you use, meaning that in high volume we'd be talking about the difference between $2 and $5.
The total complexity isn't really different, it's just the distribution of complexity between hosts and devices. USB allows simpler devices, but requires more complex host hardware.
So, there are circumstances where USB is indeed a win. When?
When the devices you're connecting are cheap enough - say, less than $50 apiece - so that the interconnect component cost is a significant fraction of the total.
When you're connecting a fair number of devices, so that the savings in device components outweighs the extra cost in host components.
When the devices don't need to be shared or act as initiators, which USB can't handle.
As it turns out, this is a perfect justification for using USB1 in a large number of cases. There may even be a few cases where it justifies USB2, but IMO those cases are likely to be rare; generally the devices that would need the extra bandwidth fail the first requirement above (of being cheap enough for interconnect-component cost to matter).
>The simple reason is that the hardware to have my device work on firewire is likely going to cost me over half of the total product cost
This seems like a gross exaggeration. In this age of ASICs, Firewire is not inherently more costly to implement than USB2. The only reason this might appear otherwise is because "USB is already the motherboard" and that's purely a matter of what standard Intel is behind. I'm sorry, but I like to make my choices based on technological advantages rather than Intel marketing muscle.
>Do my keyboard, mouse, or speakers really need to tell me that they have data available, or can I simpley have the host controller poll them at a predefined rate
Polling? Well...yuk. That's all there is to say about that.
>Drives are by nature target devices. Your hard drive doesn't tell your CPU that it has some data it may want, your CPU requests the data.
Actually, many problems in my professional life could be solved a lot more cleanly if SCSI disk-drive and host-adapter vendors supported AEN. While it's true that disks are mostly passive targets, allowing them to act as initiators occasionally - even if only to report error conditions instead of tossing them into the sense data the next time someone happens to issue a command - could be a big win.
>One of the reasons that Firewire drives haven't caught on is that they are expensive. Some of this expense comes form the fact that they are new, and low volume, but there is also unnecessary overhead in firewire for that purpose.
Actually, I'd say the cost is almost entirely because Firewire is new and hence low-volume. SCSI is a fairly complex protocol too, but because it's high-volume implementations are cheap.
>What might Firewire be good for? How about hot plug and play network cards, or having multiple computers talk to the same device.
Shared devices, once the sole province of the high-end enterprise, are moving more and more into the low end. Before long SANs will be commonplace, and at that point a solution that supports them (e.g. Firewire, FC) will have very obvious advantages over one that doesn't (e.g. USB).
>Then again Fibre Channel is also good for this and even faster.
FC is an ugly set of standards, repeating every mistake people should have learned to avoid from previous high-speed-interconnect standards attempts. Yech. Yes, it has high speed, and it has lots of connectivity options and blah blah blah, but all done in such a screamingly inelegant way that it almost doesn't seem worth it.
>Why would you not improve the spec? Or do you think everyone will just drop their USB products, and install firewire?
If you'll go back and read the post to which you were reacting, I was suggesting exactly the opposite, i.e. that USB and Firewire can and should coexist, serving different needs.
Improving USB isn't free. For a start, developing a standard like this consumes a lot of time for a lot of people who could almost certainly be applying their considerable intellectual talents to problems that have not already been solved. Secondly, as another poster pointed out, all sorts of incompatibilities and gotchas tend to creep in when you have multiple versions of a standard. Deploying USB2 in a USB1 world is not a whole heck of a lot less troublesome than deploying Firewire in a USB1 world. I could go on, but those reasons alone seem more than sufficient for now.
>So while firewire might soon leap past USB 2.0 in terms of speed, what devices are there that will require it?
Perhaps no single device will, but assuming that the whole world is a point-to-point topology without any shared communications resources (either media themselves or hubs and their cousins) is a classic mistake. It's not hard at all to think of a configuration where the aggregate bandwith required by all attached devices is greater than either 400Mbps, and therein lies the utility of a faster interconnect.
>OK, I'm actually at the USB 2.0 Devcon right now, and have read the 2.0 proposed spec, so I'll take a stab at refuting these comments:
Thank you for identifying your vested interest. That's all too rare around here.
>>2.Even if USB2 runs at 480Mbps, the Firewire folks aren't exactly standing still. Any raw bandwidth advantage of USB2 is sure to be short-lived at best. >Firewire and USB have too many things that are not in common, they really are not competitors
In other words: yes, Firewire will over the long term retain a significant raw-bandwidth advantage despite very short-term leapfrogging.
I stand corrected on isochrony, power through the connector, and number of hosts. I'm glad someone with more authoritative information was there to correct any incorrect impressions that might have resulted from my earlier post.
>In summary, USB 2.0 looks like it handles a lot of the speed issues that some people had with 1.1.
My question is: what speed issues did people have that would not have been adequately addressed by implementing both USB and Firewire? As many people including yourself have pointed out, there are still and will always be important differences between the two, and "one size fits all" is more often than not a lousy philosophy in computing.
>Like it or not, USB looks to be here for a while
I have nothing against USB in and of itself. My concern is that Firewire already exists and as near as I can tell already addresses the issues which USB2 seems to be trying to address (as compared to USB1). I happen to dislike reinvented wheels; I would have been much happier if the USB folks had let USB do what USB does best, and let Firewire do what Firewire does best, and go off to do other more useful things with their time. Competition is great, but there's plenty in both technical areas already. Pushing USB into the Firewire "problem space" is just an attempt by Intel to squash competition in the high-speed interconnect market by leveraging their position as the largest PC chipset manufacturer.
Just a few observations/questions regarding comparisons with Firewire.
The usb.org article only claims "120-240Mbps". It's not clear where the ign.com article came up with 480Mbps.
Even if USB2 runs at 480Mbps, the Firewire folks aren't exactly standing still. Any raw bandwidth advantage of USB2 is sure to be short-lived at best.
There's lots of blather in the USB2 announcement about supporting video cameras etc. but IIRC USB doesn't support the isochronous transfers which are usually considered necessary to serve those markets. Did I miss something?
Another useful Firewire feature that USB doesn't seem to have is providing power through the same connector used for communications. Again, I may have missed it.
I don't remember how many devices USB supports, but I suspect it's less than Firewire.
I know that USB-based host-to-host networking exists, but it's not clear to me whether it's really as well suited to that task as Firewire. In particular, I wonder how much asymmetry between hosts and devices (a la initiators and targets in SCSI) is built into the protocol, and how round-trip latency compares to other technologies.
Similarly, I'd like seeing a comparison of how automagically reconfiguration happens when devices are added or removed using each technology.
With any luck, someone more clueful can fill in the blanks above.
Overall, Firewire still looks like a generally superior technology in its niche, while the USB folks should have been content with their own separate niche (lower-bandwidth peripherals such as keyboards, mice, joysticks and modems that don't need advanced features such as isochronous transfers).
BTW, I don't actually use Firewire and have no interest beyond the aesthetic in promoting it. My employer is thoroughly committed to (ick) FC.
>Solution: Use the MMU to isolate software components from each other
Great idea! And I'm not just saying that because I pretty much suggested the same thing in one of my own posts.;-) Now...when are the hardware designers going to give us hardware on which MMU manipulation isn't such a performance-killing pain in the ass? Better granularity would be nice too.
>The grand majority of your project time should be spent in the design phases
I agree with you, but only if you're using an expansive definition of "design phase". IMX one of the biggest problems on projects is that people think "design" refers only to sitting in a big conference room, away from any computers, drawing a bunch of crap on a whiteboard. WRONG A functional design process is iterative, alternating between sessions in the big whiteboard room and sessions actually trying things out or modeling performance or doing something else to get the hard facts needed to make the whiteboard sessions productive.
One of the biggest problems with most programmers is the sick desire never to write code that doesn't go into the product. That means no prototypes, no simulations, no test programs, etc. Another favorite quote from Brooks is "plan to throw one away; you will anyway." Perhaps one measure of a well-run project would be how much of the code written did not end up in the release.
Slashdot Mirror
>Makes you wonder why the hell something like this wasn't invented years ago.
It was. Telebit was doing this 15 years ago, and I most sincerely doubt they were anywhere near the first.
A couple of companies ago, we needed to test some PCI hardware via emulation. The emulation of our board ran at about 1% of real speed (which is actually pretty good for that kind of thing) so we needed PCs in which the other components - CPUs, chipsets, etc. - also ran that slowly. We found a couple of companies that specialize in making the slowest PCs for just this purpose, and they compete very aggressively. "We're slower than they are! You should buy ours!" It was rather amusing.
;-)
Less amusing was the fact that they couldn't actually deliver the kinds of systems we wanted (450GX) at a low enough speed. It turns out that trying to turn _down_ the clock involves many of the same challenges as turning it up, and some of the components didn't take well to the low clock speeds. "We couldn't make it slow enough to satisfy the customer."
Yes, I know this would violate the rules of the contest. I also know that I'm a little off-topic, but hopefully this is also funny enough that I'll get to keep my karma points.
As I recall, the QPL owes its current form largely to the uproar caused by the original license among the "gimme free stuff" crowd - who obviously liked it enough to want it, but not enough to pay for it. Would this particular conflict have occurred with the original QPL, or is it an artifact of the pressure to come up with something acceptable to the GPL bigots in the context of still trying to run a business?
I'm not (just) trolling here. I'm genuinely curious whether this is a self-inflicted wound.
True enough, but not quite for the reasons you state. What you need to look at is the executable plus whatever libraries it links to, and how much that increases system memory usage. Some examples:
And so on. I think the secondary issue here is what typically happens for VB executables and C executables. On most systems, pretty much everything uses the C runtime, so its memory cost is amortized across a bunch of programs. Another poster has pointed out that VB executables can be dynamically linked to get the same effect in the right environment, which is nice, but that they are often statically linked with a large runtime and are, therefore, hogs. Hogs slow down your system by consuming resources even if they themselves don't seem particularly slow.
Getting back to the original issue, which performs better: Java or VB? I don't know the answer, actually. My point is that the PHBs who complain about Java performance and then use VB don't know either, and that's stupid.
But how efficient are those executables? I can think of several ways to generate an executable from VB:
None but the last approach offers any significant promise of being comparable to the same functionality implemented in C/C++, and even then it depends a lot on the complexity and quality of implementation of the runtime.
One experiment would be to see how large a very minimal VB executable would be: if it's really big, chances are that they're "cheating" and they're probably using one of the first two approaches. I don't use VB myself, or else I'd do the experiment myself and post the results.
For contrast, consider something like C++. This is simply not an appropriate choice as a first language for someone new to programming. People (ab)using C++ without having a decent grasp of programming (particularly modularity/OO aspects) first have caused more pain and frustration for their better-trained fellows than I care to think about. In this group I include the designers of the most common C++ class library - MFC, which by itself has done more to turn people off C++ than even the language's own nastiness could do. This relative inaccessibility explains C++'s place behind VB.
As an aside, is perl a good choice as a first language? Personally, I don't think perl is a good choice for much of anything, but I suspect that even the most ardent perl advocate would admit perl isn't likely to appeal to first-time users. It's not meant to. (Python, on the other hand, would IMO make a very good first or teaching language.)
Java's low position on the list is best explained by three things: its relative youth, lack of proper support for certain types of programming, and performance. The youth issue is pretty self-explanatory. As for lack of support, here are some thoughts:
I think the performance issue is mostly BS. Sure, an interpreted or incrementally-compiled language such as Java will never be as fast as a fully-compiled language, but with modern technology the difference is very small. The weird thing is, the same PHBs who can't get "Java is slow" out of their heads have no qualms about using VB. What's up with that?
>Thanks to Irina Krush. She will take away Garry's title someday.
Not likely. Krush is vastly stronger than any of us, but that doesn't mean she's stronger than Kasparov. Like him or hate him - and I'm not exactly a fan myself - the objective evidence indicates that Kasparov is the strongest player in the world today and probably the strongest ever. Even the loss to Deep(er) Blue doesn't change that, because DB was tuned specifically to play against Kasparov and would fare worse than Kasparov if both were to play in a round-robin with the other 14 top players. It's not uncommon for a less-skilled player to maintain a winning record against one of their betters because of style issues, but it doesn't change their relative strengths.
It's possible that IK could someday be better than Kasparov. In fact, that's highly likely since she's younger and chess ability under tournament/championship conditions does seem to fade a bit with advanced age. What's more interesting is the question of whether IK might someday be the best player in the world[1]. Yeah, it's possible. However, it's also possible that any of a thousand other players - from Anand to Morozevich to Khalifman to Xie Jun - could raise their own abilities and forever stay above her. Remember, they're also highly disciplined professionals capable of analysis just as deep as IK's. Statistically, the chances that IK will ever be the best player in the world are slim.
[1] One of the English chess columnists - Miles, I think - has written a far better piece than I ever could about the difference between being the best player and being world champion. It's somewhere on www.chesscafe.com IIRC.
>We need to commend her on her efforts she put a ton of work into the game! She contributed months and months of painstaking, in-depth analysis. Thanks, Irina!
Absolutely. The above comments about her ability aside, her devotion and passion and work ethic are highly commendable. She did a great job as "team captain" for the world.
>133 Mhz x 64 bit = 1 Gb/s
My calculator says that 133*64 equals 8512, not 1000 or 1024. Try again.
>>When the first RISC machines came out, superscalar execution hadn't been invented yet.
>
>Some processors (Cray for one) had been doing this years before RISC came out.
There's a big difference between vector operations and true superscalarity. Also, RISC vs. CISC only makes sense from the point where instruction sets were truly complex and there was a choice to be made; many early architectures were RISC of necessity.
>Once all those youngsters get older, they will be used to the UNIX paradigm of programming and anyone who's programmed in UNIX will find that the Windows method of doing thing will make their flesh crawl.
Actually, I think this touches on the real reason behind most of the posts here. People tend to think that the way they learned is the way things should be, and hate having to change paradigms - even when the new paradigms are better (and I'm not saying which are). We've all met FORTRAN or BASIC or assembler programmers who think OOP is for wimps, haven't we? Many of the posts here have exactly the same boorish tone, and are equally misguided.
IMO, the mistake is letting people get too comfortable with one model before exposing them to another. Give programmers both UNIX and Windoze, and maybe a third, from an early point. Let them decide which they prefer after they've had a chance to gain some perspective instead of getting them stuck in the first model they learned.
Both the Ars Technica article and the MSU paper to which it refers are very well done, providing an excellent introduction to material covered in greater depth in Hennesy And Patterson's[1] Computer Architecture: A Quantitative Approach.
My one quibble is that the AT author gives the basic performance formula in what I consider an "upside down" form - time/program rather than work/second - which I think makes it harder to understand some of the later points.
Like Ditzel, I pine for a return to the days when true RISC architectures existed. The principles involved haven't really changed, and I think some later "evolution" has been misguided. See my recent posts in the "Intel Athlon-Killer" article for more details if you're interested.
[1] I can never remember which letters in which name get doubled, or which one was at Berkeley and which at Stanford. Apologies for any errors on either count.
>The whole idea with RISC is to make instructions so basic that they can (almost) all be completed in a single processor cycle.
I don't think that's the whole idea of RISC. The basic RISC philosophy, as elucidated most excellently in H&P, is to maximize instructions per second, and if that means a small sacrifice in work per instruction that's OK. Single-cycle execution is probably the most powerful means available to achieve this goal, but there are many others - superscalarity, deep pipelines, reordering, branch prediction, etc. - that apply regardless of how many cycles instructions take.
As happens way too often, /. managed to lose my first response to this, while giving every appearance of having accepted it. *sigh*
;-) Basically I haven't seen much in subsequent processor designs to counter the excellent arguments H&P put forth in their book regarding How It Should Be Done.
>What you describe is essentially the initial MIPS project started by Hennessy at Stanford.
I'm glad someone noticed.
>Most delay slots are never filled
Obviously, this can vary a lot, but according to the studies I've seen a single delay slot can be filled with something besides a NOP >80% of the time for most kinds of code. The important thing is that a NOP is no worse than a stall, except that the stall usually has a lot more wasted circuitry associated with it.
Yes, dynamic scheduling can do "better" than static, but at what cost? Does the improvement make up for the additional complexity and limitation of clock rate? More importantly, are there other things that can be done with that real estate which provide even better bang for the buck?
- WPI * IPC * CPS
Classical CISC architectures tried to maximize WPI, and this limited the other two factors. RISC was mostly intended to maximize CPS, intentionally sacrificing WPI to do so. Pipelining, superscalarity, and branch prediction are all targeted toward increasing IPC in different ways. VLIW and EPIC improve either WPI or ICP depending on how you look at it.WPI = Work Per Instruction
IPC = Instructions Per Cycle
CPS = Cycles Per Second
All of these approaches to improving performance tend to have characteristic challenges associated with them. In the current case, you have to deal with the fact that massively superscalar architectures require an instruction stream that keeps all the functional units fed. That means that compilers have to try to resolve data dependencies and competition for functional units, either of which would cause a stall, and also deal with branches which cause bubbles in almost any architecture. It's a very tough problem, which is why chip designers turn to second-order tricks such as speculative/predicated execution and VLIW/EPIC.
Personally, I think that's all a trap because it causes chip complexity to skyrocket and undermines the very idea of RISC. If I were designing a chip, my goal would be to crank the frequency sky-high and make the compiler (or a translating front-end processor such as Transmeta is rumored to be working on) do most of the worrying about how instructions get scheduled. In particular, I'd go for:
Moderating the previous post down as "Flamebait" is one of the worst abuses of moderation I've seen lately. I might accept "Redundant" since many others have also commented on the "preemptive vapor" aspect of Intel's announcement, though I think this post does a better job than most of explaining how the trick actually works.
The fact is that only a fool or a lunatic or someone paid by Intel could fail to see that the announcement has nothing to do with delivering a better product to consumers. The goal here is purely to squash AMD, and if AMD filed for bankruptcy tomorrow we would almost certainly never see the promised Intel chip. The amazing thing is that Intel, already under scrutiny from the FTC, would dare do anything so blatantly anti-competitive.
>>Apple controls firewire
>
>IEEE 1394 is an international standard. It is not controlled by any one company.
Actually, this could stand some clarification. P1394 is an IEEE standard which anyone can use without licensing fees, but "Firewire" is an Apple trademark. That's why Sony, for example, refers to P1394 as iLink instead.
Apple's fees for using the "Firewire" name are IMO justified by their investment in making that name appealing to consumers. Also, their fees are very modest ($1 per unit, IIRC) and above-board. By contrast, the "Intel tax" on USB is just as real and much more substantial, but hidden in the form of additional motherboard component cost. Also, Intel's grip is not just on the name but on the technology itself, which they will never allow to become a true open standard. Intel's idea of openness is to blackmail companies that depend on them for other products into making false shows of "broad industry support".
It's amazing to me that anyone here on slashdot, where people bash BSD and Red Hat because they're not "open" enough, would play into Intel's hands so willingly. Intel is the ultimate proprietary-everything company, worse even than M$.
This cost argument for USB vs. Firewire is a total red herring, on two levels:
- The price difference is tiny. Let's say for the sake of argument that the circuitry for Firewire is 4x as complex as that for USB2 (and that's an exaggeration). That may require one step up in which ASIC family you use, meaning that in high volume we'd be talking about the difference between $2 and $5.
- The total complexity isn't really different, it's just the distribution of complexity between hosts and devices. USB allows simpler devices, but requires more complex host hardware.
So, there are circumstances where USB is indeed a win. When?- When the devices you're connecting are cheap enough - say, less than $50 apiece - so that the interconnect component cost is a significant fraction of the total.
- When you're connecting a fair number of devices, so that the savings in device components outweighs the extra cost in host components.
- When the devices don't need to be shared or act as initiators, which USB can't handle.
As it turns out, this is a perfect justification for using USB1 in a large number of cases. There may even be a few cases where it justifies USB2, but IMO those cases are likely to be rare; generally the devices that would need the extra bandwidth fail the first requirement above (of being cheap enough for interconnect-component cost to matter).>The simple reason is that the hardware to have my device work on firewire is likely going to cost me over half of the total product cost
This seems like a gross exaggeration. In this age of ASICs, Firewire is not inherently more costly to implement than USB2. The only reason this might appear otherwise is because "USB is already the motherboard" and that's purely a matter of what standard Intel is behind. I'm sorry, but I like to make my choices based on technological advantages rather than Intel marketing muscle.
>Do my keyboard, mouse, or speakers really need to tell me that they have data available, or can I simpley have the host controller poll them at a predefined rate
Polling? Well...yuk. That's all there is to say about that.
>Drives are by nature target devices. Your hard drive doesn't tell your CPU that it has some data it may want, your CPU requests the data.
Actually, many problems in my professional life could be solved a lot more cleanly if SCSI disk-drive and host-adapter vendors supported AEN. While it's true that disks are mostly passive targets, allowing them to act as initiators occasionally - even if only to report error conditions instead of tossing them into the sense data the next time someone happens to issue a command - could be a big win.
>One of the reasons that Firewire drives haven't caught on is that they are expensive. Some of this expense comes form the fact that they are new, and low volume, but there is also unnecessary overhead in firewire for that purpose.
Actually, I'd say the cost is almost entirely because Firewire is new and hence low-volume. SCSI is a fairly complex protocol too, but because it's high-volume implementations are cheap.
>What might Firewire be good for? How about hot plug and play network cards, or having multiple computers talk to the same device.
Shared devices, once the sole province of the high-end enterprise, are moving more and more into the low end. Before long SANs will be commonplace, and at that point a solution that supports them (e.g. Firewire, FC) will have very obvious advantages over one that doesn't (e.g. USB).
>Then again Fibre Channel is also good for this and even faster.
FC is an ugly set of standards, repeating every mistake people should have learned to avoid from previous high-speed-interconnect standards attempts. Yech. Yes, it has high speed, and it has lots of connectivity options and blah blah blah, but all done in such a screamingly inelegant way that it almost doesn't seem worth it.
>Why would you not improve the spec? Or
do you think everyone will just drop their USB
products, and install firewire?
If you'll go back and read the post to which you were reacting, I was suggesting exactly the opposite, i.e. that USB and Firewire can and should coexist, serving different needs.
Improving USB isn't free. For a start, developing a standard like this consumes a lot of time for a lot of people who could almost certainly be applying their considerable intellectual talents to problems that have not already been solved. Secondly, as another poster pointed out, all sorts of incompatibilities and gotchas tend to creep in when you have multiple versions of a standard. Deploying USB2 in a USB1 world is not a whole heck of a lot less troublesome than deploying Firewire in a USB1 world. I could go on, but those reasons alone seem more than sufficient for now.
>So while firewire might soon leap past
USB 2.0 in terms of speed, what devices are there
that will require it?
Perhaps no single device will, but assuming that the whole world is a point-to-point topology without any shared communications resources (either media themselves or hubs and their cousins) is a classic mistake. It's not hard at all to think of a configuration where the aggregate bandwith required by all attached devices is greater than either 400Mbps, and therein lies the utility of a faster interconnect.
>OK, I'm actually at the USB 2.0 Devcon right now, and have read the 2.0 proposed spec, so I'll take a stab at refuting these comments:
Thank you for identifying your vested interest. That's all too rare around here.
>>2.Even if USB2 runs at 480Mbps, the Firewire folks aren't exactly standing still. Any raw bandwidth advantage of USB2 is sure to be short-lived at best.
>Firewire and USB have too many things that are not in common, they really are not competitors
In other words: yes, Firewire will over the long term retain a significant raw-bandwidth advantage despite very short-term leapfrogging.
I stand corrected on isochrony, power through the connector, and number of hosts. I'm glad someone with more authoritative information was there to correct any incorrect impressions that might have resulted from my earlier post.
>In summary, USB 2.0 looks like it handles a lot of the speed issues that some people had with 1.1.
My question is: what speed issues did people have that would not have been adequately addressed by implementing both USB and Firewire? As many people including yourself have pointed out, there are still and will always be important differences between the two, and "one size fits all" is more often than not a lousy philosophy in computing.
>Like it or not, USB looks to be here for a while
I have nothing against USB in and of itself. My concern is that Firewire already exists and as near as I can tell already addresses the issues which USB2 seems to be trying to address (as compared to USB1). I happen to dislike reinvented wheels; I would have been much happier if the USB folks had let USB do what USB does best, and let Firewire do what Firewire does best, and go off to do other more useful things with their time. Competition is great, but there's plenty in both technical areas already. Pushing USB into the Firewire "problem space" is just an attempt by Intel to squash competition in the high-speed interconnect market by leveraging their position as the largest PC chipset manufacturer.
With any luck, someone more clueful can fill in the blanks above.
Overall, Firewire still looks like a generally superior technology in its niche, while the USB folks should have been content with their own separate niche (lower-bandwidth peripherals such as keyboards, mice, joysticks and modems that don't need advanced features such as isochronous transfers).
BTW, I don't actually use Firewire and have no interest beyond the aesthetic in promoting it. My employer is thoroughly committed to (ick) FC.
>Solution: Use the MMU to isolate software components from each other
;-) Now...when are the hardware designers going to give us hardware on which MMU manipulation isn't such a performance-killing pain in the ass? Better granularity would be nice too.
Great idea! And I'm not just saying that because I pretty much suggested the same thing in one of my own posts.
>Windows 2000 is the MOST modular OS I know of.
Then you need to broaden your horizons. NT actually does OK, I'll grant, but it's no shining example.
>The grand majority of your project time should be spent in the design phases
I agree with you, but only if you're using an expansive definition of "design phase". IMX one of the biggest problems on projects is that people think "design" refers only to sitting in a big conference room, away from any computers, drawing a bunch of crap on a whiteboard. WRONG A functional design process is iterative, alternating between sessions in the big whiteboard room and sessions actually trying things out or modeling performance or doing something else to get the hard facts needed to make the whiteboard sessions productive.
One of the biggest problems with most programmers is the sick desire never to write code that doesn't go into the product. That means no prototypes, no simulations, no test programs, etc. Another favorite quote from Brooks is "plan to throw one away; you will anyway." Perhaps one measure of a well-run project would be how much of the code written did not end up in the release.
>You need to understand how the industry really works.
Bravo! That was absolutely hilarious, partly because it's all true. My hat is off to you.