Let's stop with these stupid, internal os holy wars. We're all in the same boat (be it BSD,Linux hell even HURD) and all against micro$oft.
While I'm all for holding back the OS holy wars, please remember that we're NOT all just "Against Microsoft."
Characterizing this movement as solely an anti-Microsoft sentiment devalues our platforms. After all, we're not OS/2, MacOS, or any of the non-free Unices. We're free, open software, and that's what's important.
Carmack has enough money laying around and a great enough reputation as someone who is more interested in technical truth than anything else to go and do something silly like be bought off.
Yeah, but what if 9 years and 11 months of that 10 year development effort were spent playing Wolfenstein 3D, Doom, Doom 2, Quake and Quake 2, and then they crammed that last month?
You too can have your own discussion thread. This may be THE MOST IMPORTANT POST YOU EVER MAKE!Pay careful attention, and then punch Reply to This.
Post this message as a followup to the post by the first author listed below.
That post, move the list of names up by one, and place your name at the bottom of the list.
To ensure success, make sure to place a reference to how GNOME, KDE, vi, Emacs, Qt, GTK+, Linux, *BSD or Windows 'sucks' or 'rules' as compared to one of the others. Be creative. "*BSD rules and vi sucks!"
As long as people keep following up to these posts, we'll create an ever growing cascade of followups! Instant discussion threads of your very own! Just imagine the IPO possibilities!!!?!!!?!?!???
Often,/. links to other sites of interest that have nothing to do with news reporting. Rather, they link right to where it's happening, rather than the people that are talking about it and predigesting it for us.
And don't forget such juicy "news as it happens" tidbits such as the Gentlemen's Flamewar between ESR and RMS.
I work at TI. I've never worn a tie here, and I rarely see anyone ever wear a tie. (Mostly the management up in the stratosphere on the org-chart.)
And as for dress down Friday being every day? Hmm... less see... Tennis shoes, black denim shorts, E3 conference T-shirt and an Intellivision baseball cap. That's what I'm wearing right now in my cubicle, as I peck away at this Ultra 2 while I wait for a simulation to finish.
Isn't this the exact behavior that SCSI disconnects are supposed to help?
I'm pretty sure the kernel doesn't block waiting for the I/O to complete. It issues the request to the device and puts the blocked task to sleep while it goes about handling Everything Else TM.
Now, in the case of IDE, if both drives are on the same IDE chain, you're going to block waiting for the device driver. If they're on different chains, then they can run independently.
I would be inclined to agree with you, if it weren't for the fact that the PHBs and bean counters are trying to pick between NT and Linux.
If the management types are asking the question "NT or Linux", then why shouldn't the Linux community be interested in any data that could sway somebody's answer?
The "right way", of course, is to pick the OS and software that does exactly what you need, etc. etc. Unfortunately, for arbitrarily complex real world situations, with arbitrarily complex management, personnel and customer pressures, there isn't always the time to find the "perfect" system. So, instead people rely on benchmarks, press reviews, word-of-mouth, etc. And also, unfortunately, management often trusts the word of the outside world more than the word of its own employees. (Sometimes, there are seemingly rational reasons for doing so, such as "suppliers X, Y, and Z provide more solutions for platform A than platform B, which is more important to me than the fact that Frank prefers platform B because 'he likes it better,'" neverminding the reasons why Frank might like it better.) And so, monitoring the press and actually responding constructively (eg. fixing performance problems, etc) is a good thing.
The key, of course, is to keep sight of what matters. Lets not get trapped into optimizing things that don't actually matter. For instance, optimizing Apache for utter speed while compromising stability would be a bad thing. Or worse, bloating the kernel with benchmark specific tweaks, etc. (After all, isn't that how Microsoft attains its legendary (lack of) stability?) Remember, while these sorts of highly-publicized benchmarks may point out some weak points, they also could just be serving as chaff to block the real threats from our radar screen.
Perhaps that was the idea you were trying to get across, AC?
F666G, w/ Integer BASIC enabled: Mini Assembler. You are correct.
FAA6G. You weren't sure whether I was in Integer or Applesoft BASIC. The prompt was an Applesoft BASIC prompt, although it doesn't matter. FAA6G reboots the Apple.
And now some 6502 trivia... What does the hex sequence 2C 30 C0 assemble to, and what does that instruction do on an Apple ][?
It'd be cool if Woz were INFP. Then we'd have something cool in common (aside from a love for hacking, that is).
I'm INFP/INTP... depending on mood or situation. More INTP in work matters, INFP in daily life.
The confused can go to www.keirsey.com to be suitably enlightened. (Or, if you're into the more traditional Meyers-Briggs (sp?) tests, you can find out there too. I think there's a x-based version called xmbti, but I don't remember for sure.)
It'd be cool if he were INFP. Then we'd have something cool in common (aside from a love for hacking, that is).
I'm INFP/INTP... depending on mood or situation. More INTP in work matters, INFP in daily life.
The confused can go to www.keirsey.com to be suitably enlightened. (Or, if you're into the more traditional Meyers-Briggs (sp?) tests, you can find out there too. I think there's a x-based version called xmbti, but I don't remember for sure.)
Actually, the drive recalibration you refer to was pretty common amongst alot of floppy drives. Every hear a PC recal the drive when it can't read a sector? Brrr-RRRRt!
The IWM (which I heard expanded to the "Incredible Woz Machine") was little more than a state-machine driven by some TTL gates and a PROM on the old Apple ]['s. (Somewhere in my vast collection of 'stuff', I have the schematics and PROM dump for upgrading from the 13-sector '5+3' format to the 16-sector '6+2' format.) But, it was a heck of a lot cheaper than the microcontroller-driven floppies of the day.
One drawback, of course, is that your CPU had to run at exactly NTSC colorburst divided by 3.5 in order for it to work. The various CPU speedup chips that came later all slowed down to this speed (1.023MHz) when accessing the disk.:-)
Another legend has it that the infernal Apple ][ memory map was much, much closer to being linear in the original design, but it required a couple more chips. Woz, interested in saving some $$, designed these chips out, introducing the world to the Venetian Blind fade effect so common in Apple ][ programs.
Ahh, the memories come rushing back... I could babble for hours on the intricasies of the Apple ][ hardware (but I won't).
Applesoft BASIC was written by Microsoft. Part of Apple's deal w/ MS was to rename the Microsoft basic to Applesoft. Dunno if they had to pay extra for that, but considering that most of the machines of the day had MS basic but few proclaimed "Microsoft" directly, this makes some amount of sense.
Heck, why not run your voiceband modem on the voice line and get that extra few KB per second? :-) (You'd have to have an ISP that lets you do it, of course...)
Now that gives me the privacy heebee geebees. (Someone, go moderate up the parent to this post.)
I hope that anonymizers start playing a more prominent role in such a society, otherwise requiring cryptographically strong signatures on everything will become a rather effective tool for oppression.
Of course, such a system will only really work if people protect their digital signatures much better than anything else they currently protect. For goodness sakes, our ATM accounts are protected by a 4-digit PIN, and my credit cards are protected by my mother's maiden name. *sheesh* Then again, if we're forced to use biometric data gathered with standardized, regulated machines in order to generate digital signature data, a digital signature is as good as or better than a fingerprint.
Well, the device does DES and RSA, implying there's alot of good communications infrastructure, and that the encryption cores themselves are largely decoupled from the rest of the design. At least, that's what I'd hope they did, since it would make the part more valuable overall: You could plop the encryption cores into other chips that had different communication requirements easily, and you could drop different encryption cores into this chip easily.
If that's the case, then we can reuse all the communication bits, and replace the DES core with an RC5 key-crunching core. This is alot like the way d.net clients share the most of the same block management and network communication code between the DES and RC5 cores it has internally -- the key cruncher is actually a small (yet very important) part of the overall problem.
The natural question for many/.'ers that also participate in distributed.net is whether or not this will be useful for crunching keys.
I'm guessing, in it's base form, the device is tuned for (en|de)crypting large volumes of data with a fixed key, and that key reloads are expensive. Translation: It won't help a d.net-style keysearching effort much as-is.
Does anyone have more information on this to confirm or deny this conjecture?
Also, is anyone out there crazy enough (and skilled enough w/ VHDL) to hack this device into the world's fastest RC5 block cruncher? :-) Places like MOSIS will fab "educational" and "prototype" designs in small quantities for reasonable prices.
Actually, having an optimized compiler does impact the bottom line (moreso on some platforms than others).
In Intel's case, it's largely psychological. Already, people go with Intel because they feel that it's gotta be faster/better/etc because they're the company driving the platform, whether that is actually true. Bits like this serve to reinforce that image.
Also, consider that the entire RISC paradigm was made possible by compiler technology. Surely you weren't expecting people to hand-code major applications all in assembly code, were you? To an application writer on modern machinery, the performance you get from your compiler IS the performance you get from the architecture and the chip. If you can improve the performance from software, that's less silicon area that you need to spend on the problem, which translates into smaller die sizes, higher yields, and therefore lower prices, higher margins and happier customers.
And then there's the more exotic architectures, such as the one I work on at my day job -- the TMS320C6000 family VLIW DSPs. A good compiler is an absolute must for such a beast, and the absence of one would make the platform more of a computer science curiousity than a successful DSP. VLIWs work by moving all of the pipeline management out of silicon and into the compiler, making the compiler one of the most important components of the system. Intel's EPIC platform presents a similar situation.
Therefore, don't underestimate the power of good compilers to increase the value of a given processor platform. They're part of the essential infrastructure which keeps a platform supported and raises it to new heights, and in the case of Intel's x86, they serve as an additional tool in their arsenal for differentiating and improving their platform over the competition -- other x86 vendors and RISC vendors.
I've seen architectures that were very good and/or clever architectures but were difficult to program by hand. Lack of good tools support sent these to an undeserved early grave. The early VLIWs fell into this category (Multiflow's Trace is remembered as having the world's slowest compiler -- a victom of being ahead of its time), as did some DSPs (such as the 320C80 family... sniffle).
Now, one of the angles on Intel's move that I missed earlier is that improving GCC's x86 performance in general (whether or not it applies specifically to Intel's x86 flavor) is that it can help x86 *nix's (including Linux) to eat their way into the RISC-dominated workstation market. I can see this being very important to Intel's bottom line, since servers and engineering workstations are high-margin items. And so, the plot thickens... :-)
EGCS will become GCC. If I recall correctly, when EGCS is "finished", it will be released as GCC 3.0. In the meantime, EGCS releases are numbered as GCC 2.9x and EGCS 1.x in parallel, it appears.
Poke around egcs.cygnus.com for the complete scoop, as I'm sure I don't have my facts 100% straight (although I have them close).
This is true for GCC 2.8. There's a new Sparc back-end in EGCS which should bring GCC into the latter half of the 90's finally.
One nice thing about the new back end is that it actually understands the Ultra-Sparc's scheduling requirements so that it can actually get four instructions issued each cycle. When you lump in the Haifa scheduler technology as well as the advanced pointer analysis and so on, I think 3.0 will shape up to be a much stronger contender.
In the meantime, I'd expect EGCS's performance numbers to still lag Sun's SparcWorks compiler for a little while, based on the following reasons:
EGCS is still not widely deployed, and so there isn't alot of feedback available for tuning it.
EGCS is still a work-in-progress, and many new bits are being added. It'll be awhile before they're all well-adjusted to work together. (Optimizations are NOT as linearly independent of each other as many would wish.)
The SparcWorks compiler still has a few other features that are missing from EGCS, such as cache-based optimization. These can really help certain classes of programs.
Finally, the benchmarks will always be skewed if we only consider SPEC. The Sun compilers are very much SPEC-oriented compilers, from what I've seen. While Sun may have a large lead on SPEC benchmarks, the real-world difference is quite a bit smaller, I'm sure.
So that's about it. I can't really comment on the C++ differences, except to say that I would imagine alot of the binary bloat comes from GCC having to "roll its own" exception handling and infrastructure, whereas Sun probably offloads alot of that to proprietary, platform-specific libraries.
It would appear Intel is trying to keep its x86 flavor more attractive than other x86 flavors by stacking the compilers in its favor as well. I might be cynical, but I think that Intel is banking on getting a few of the ducats that people are saving on Open-Source Software by having them upgrade to an Intel x86 instead of an AMD or Cyrix part.
After all, the compiler supports Intel-specific optimizations, so why not?
The problem, of course, is the fact that AMD and Cyrix probably do not have the resources to fund/promote similar efforts, so this does end up being a means for Intel to un-level the playing field.
On the bright side, alot of x86-specific tweaks will help all x86 variants, not just Intel's x86s. (For instance, register allocation that understands the highly non-orthogonal IA32 register file would be a big step forward for all x86's. There was an interesting paper in MICRO-31 about that, IIRC. Also, scheduling to avoid AGIs and other hazards generally helps all flavors.) So, the picture isn't as bad as the paragraph above might have painted.
Nonetheless, if you want AMD-specific tweaks to GCC, then why don't you see if you can contribute to the tweaking effort? Even if all that means is beta-testing proposed changes on your machine for robustness and performance improvements, it'll still help. Poke around egcs.cygnus.com and ask what's up.
(The dots are for spacing, since PRE tags aren't allowed.
Basically, VMS begat CP/M -- VMS for the 16-bit minis, CP/M for the 8-bit micros -- and CP/M begat DOS. Win16 and Win32 built up on DOS, and WinNT inherited from Win32 and from VMS directly.
Slashdot Mirror
While I'm all for holding back the OS holy wars, please remember that we're NOT all just "Against Microsoft."
Characterizing this movement as solely an anti-Microsoft sentiment devalues our platforms. After all, we're not OS/2, MacOS, or any of the non-free Unices. We're free, open software, and that's what's important.
--Joe--
Carmack has enough money laying around and a great enough reputation as someone who is more interested in technical truth than anything else to go and do something silly like be bought off.
--Joe--
Yeah, but what if 9 years and 11 months of that 10 year development effort were spent playing Wolfenstein 3D, Doom, Doom 2, Quake and Quake 2, and then they crammed that last month?
--
You too can have your own discussion thread. This may be THE MOST IMPORTANT POST YOU EVER MAKE! Pay careful attention, and then punch Reply to This .
As long as people keep following up to these posts, we'll create an ever growing cascade of followups! Instant discussion threads of your very own! Just imagine the IPO possibilities!!!?!!!?!?!???
- Anonymous Coward
- Anonymous Coward
- Anonymous Coward
- MEEPT!
- Mr Z
--Joe--
Often, /. links to other sites of interest that have nothing to do with news reporting. Rather, they link right to where it's happening, rather than the people that are talking about it and predigesting it for us.
And don't forget such juicy "news as it happens" tidbits such as the Gentlemen's Flamewar between ESR and RMS.
--Joe--
I work at TI. I've never worn a tie here, and I rarely see anyone ever wear a tie. (Mostly the management up in the stratosphere on the org-chart.)
And as for dress down Friday being every day? Hmm... less see... Tennis shoes, black denim shorts, E3 conference T-shirt and an Intellivision baseball cap. That's what I'm wearing right now in my cubicle, as I peck away at this Ultra 2 while I wait for a simulation to finish.
Who says engineering can't be fun?
--Joe--
Isn't this the exact behavior that SCSI disconnects are supposed to help?
I'm pretty sure the kernel doesn't block waiting for the I/O to complete. It issues the request to the device and puts the blocked task to sleep while it goes about handling Everything Else TM.
Now, in the case of IDE, if both drives are on the same IDE chain, you're going to block waiting for the device driver. If they're on different chains, then they can run independently.
--Joe--
I would be inclined to agree with you, if it weren't for the fact that the PHBs and bean counters are trying to pick between NT and Linux.
If the management types are asking the question "NT or Linux", then why shouldn't the Linux community be interested in any data that could sway somebody's answer?
The "right way", of course, is to pick the OS and software that does exactly what you need, etc. etc. Unfortunately, for arbitrarily complex real world situations, with arbitrarily complex management, personnel and customer pressures, there isn't always the time to find the "perfect" system. So, instead people rely on benchmarks, press reviews, word-of-mouth, etc. And also, unfortunately, management often trusts the word of the outside world more than the word of its own employees. (Sometimes, there are seemingly rational reasons for doing so, such as "suppliers X, Y, and Z provide more solutions for platform A than platform B, which is more important to me than the fact that Frank prefers platform B because 'he likes it better,'" neverminding the reasons why Frank might like it better.) And so, monitoring the press and actually responding constructively (eg. fixing performance problems, etc) is a good thing.
The key, of course, is to keep sight of what matters. Lets not get trapped into optimizing things that don't actually matter. For instance, optimizing Apache for utter speed while compromising stability would be a bad thing. Or worse, bloating the kernel with benchmark specific tweaks, etc. (After all, isn't that how Microsoft attains its legendary (lack of) stability?) Remember, while these sorts of highly-publicized benchmarks may point out some weak points, they also could just be serving as chaff to block the real threats from our radar screen.
Perhaps that was the idea you were trying to get across, AC?
--Joe--
I thought SWIM was the version that was in the Mac, and IWM was the version in the Apple ][GS.
Or am I smokin' clovers?
--Joe--
F666G, w/ Integer BASIC enabled: Mini Assembler. You are correct.
FAA6G. You weren't sure whether I was in Integer or Applesoft BASIC. The prompt was an Applesoft BASIC prompt, although it doesn't matter. FAA6G reboots the Apple.
And now some 6502 trivia... What does the hex sequence 2C 30 C0 assemble to, and what does that instruction do on an Apple ][?
--Joe--
It'd be cool if Woz were INFP. Then we'd have something cool in common (aside from a love for hacking, that is).
I'm INFP/INTP ... depending on mood or situation. More INTP in work matters, INFP in daily life.
The confused can go to www.keirsey.com to be suitably enlightened. (Or, if you're into the more traditional Meyers-Briggs (sp?) tests, you can find out there too. I think there's a x-based version called xmbti, but I don't remember for sure.)
--Joe--
It'd be cool if he were INFP. Then we'd have something cool in common (aside from a love for hacking, that is).
I'm INFP/INTP ... depending on mood or situation. More INTP in work matters, INFP in daily life.
The confused can go to www.keirsey.com to be suitably enlightened. (Or, if you're into the more traditional Meyers-Briggs (sp?) tests, you can find out there too. I think there's a x-based version called xmbti, but I don't remember for sure.)
--Joe--
I meant, of course, the infernal Apple ][ display memory map, which was interleaved 3 or 4 different ways depending on which mode you were in.
(And, there were 8-byte holes every 120 bytes that you could use for program variables. How nice.)
Bonus Apple ][ command sequence trivia: What does THIS do? (Hint: Either Language Card or both sets of BASIC ROMs required.)
] INT> CALL -151
* F666G
!
Or this?
] CALL -151* FAA6G
--Joe
--
Actually, the drive recalibration you refer to was pretty common amongst alot of floppy drives. Every hear a PC recal the drive when it can't read a sector? Brrr-RRRRt!
The IWM (which I heard expanded to the "Incredible Woz Machine") was little more than a state-machine driven by some TTL gates and a PROM on the old Apple ]['s. (Somewhere in my vast collection of 'stuff', I have the schematics and PROM dump for upgrading from the 13-sector '5+3' format to the 16-sector '6+2' format.) But, it was a heck of a lot cheaper than the microcontroller-driven floppies of the day.
One drawback, of course, is that your CPU had to run at exactly NTSC colorburst divided by 3.5 in order for it to work. The various CPU speedup chips that came later all slowed down to this speed (1.023MHz) when accessing the disk. :-)
Another legend has it that the infernal Apple ][ memory map was much, much closer to being linear in the original design, but it required a couple more chips. Woz, interested in saving some $$, designed these chips out, introducing the world to the Venetian Blind fade effect so common in Apple ][ programs.
Ahh, the memories come rushing back... I could babble for hours on the intricasies of the Apple ][ hardware (but I won't).
--Joe--
Woz wrote Integer BASIC.
Applesoft BASIC was written by Microsoft. Part of Apple's deal w/ MS was to rename the Microsoft basic to Applesoft. Dunno if they had to pay extra for that, but considering that most of the machines of the day had MS basic but few proclaimed "Microsoft" directly, this makes some amount of sense.
--Joe--
Heck, why not run your voiceband modem on the voice line and get that extra few KB per second? :-) (You'd have to have an ISP that lets you do it, of course...)
--Joe--
Now that gives me the privacy heebee geebees. (Someone, go moderate up the parent to this post.)
I hope that anonymizers start playing a more prominent role in such a society, otherwise requiring cryptographically strong signatures on everything will become a rather effective tool for oppression.
Of course, such a system will only really work if people protect their digital signatures much better than anything else they currently protect. For goodness sakes, our ATM accounts are protected by a 4-digit PIN, and my credit cards are protected by my mother's maiden name. *sheesh* Then again, if we're forced to use biometric data gathered with standardized, regulated machines in order to generate digital signature data, a digital signature is as good as or better than a fingerprint.
--Joe--
What's stopping you from having three of these chips, do to Triple DES at the full rate that one chip does DES?
(Ok, other than cost and board real-estate...)
--Joe--
Well, the device does DES and RSA, implying there's alot of good communications infrastructure, and that the encryption cores themselves are largely decoupled from the rest of the design. At least, that's what I'd hope they did, since it would make the part more valuable overall: You could plop the encryption cores into other chips that had different communication requirements easily, and you could drop different encryption cores into this chip easily.
If that's the case, then we can reuse all the communication bits, and replace the DES core with an RC5 key-crunching core. This is alot like the way d.net clients share the most of the same block management and network communication code between the DES and RC5 cores it has internally -- the key cruncher is actually a small (yet very important) part of the overall problem.
Ah, isn't 'open source' fun?
--Joe--
The natural question for many /.'ers that also participate in distributed.net is whether or not this will be useful for crunching keys.
I'm guessing, in it's base form, the device is tuned for (en|de)crypting large volumes of data with a fixed key, and that key reloads are expensive. Translation: It won't help a d.net-style keysearching effort much as-is.
Does anyone have more information on this to confirm or deny this conjecture?
Also, is anyone out there crazy enough (and skilled enough w/ VHDL) to hack this device into the world's fastest RC5 block cruncher? :-) Places like MOSIS will fab "educational" and "prototype" designs in small quantities for reasonable prices.
--Joe--
Actually, having an optimized compiler does impact the bottom line (moreso on some platforms than others).
In Intel's case, it's largely psychological. Already, people go with Intel because they feel that it's gotta be faster/better/etc because they're the company driving the platform, whether that is actually true. Bits like this serve to reinforce that image.
Also, consider that the entire RISC paradigm was made possible by compiler technology. Surely you weren't expecting people to hand-code major applications all in assembly code, were you? To an application writer on modern machinery, the performance you get from your compiler IS the performance you get from the architecture and the chip. If you can improve the performance from software, that's less silicon area that you need to spend on the problem, which translates into smaller die sizes, higher yields, and therefore lower prices, higher margins and happier customers.
And then there's the more exotic architectures, such as the one I work on at my day job -- the TMS320C6000 family VLIW DSPs. A good compiler is an absolute must for such a beast, and the absence of one would make the platform more of a computer science curiousity than a successful DSP. VLIWs work by moving all of the pipeline management out of silicon and into the compiler, making the compiler one of the most important components of the system. Intel's EPIC platform presents a similar situation.
Therefore, don't underestimate the power of good compilers to increase the value of a given processor platform. They're part of the essential infrastructure which keeps a platform supported and raises it to new heights, and in the case of Intel's x86, they serve as an additional tool in their arsenal for differentiating and improving their platform over the competition -- other x86 vendors and RISC vendors.
I've seen architectures that were very good and/or clever architectures but were difficult to program by hand. Lack of good tools support sent these to an undeserved early grave. The early VLIWs fell into this category (Multiflow's Trace is remembered as having the world's slowest compiler -- a victom of being ahead of its time), as did some DSPs (such as the 320C80 family... sniffle).
Now, one of the angles on Intel's move that I missed earlier is that improving GCC's x86 performance in general (whether or not it applies specifically to Intel's x86 flavor) is that it can help x86 *nix's (including Linux) to eat their way into the RISC-dominated workstation market. I can see this being very important to Intel's bottom line, since servers and engineering workstations are high-margin items. And so, the plot thickens... :-)
--Joe--
EGCS will become GCC. If I recall correctly, when EGCS is "finished", it will be released as GCC 3.0. In the meantime, EGCS releases are numbered as GCC 2.9x and EGCS 1.x in parallel, it appears.
Poke around egcs.cygnus.com for the complete scoop, as I'm sure I don't have my facts 100% straight (although I have them close).
--Joe--
This is true for GCC 2.8. There's a new Sparc back-end in EGCS which should bring GCC into the latter half of the 90's finally.
One nice thing about the new back end is that it actually understands the Ultra-Sparc's scheduling requirements so that it can actually get four instructions issued each cycle. When you lump in the Haifa scheduler technology as well as the advanced pointer analysis and so on, I think 3.0 will shape up to be a much stronger contender.
In the meantime, I'd expect EGCS's performance numbers to still lag Sun's SparcWorks compiler for a little while, based on the following reasons:
So that's about it. I can't really comment on the C++ differences, except to say that I would imagine alot of the binary bloat comes from GCC having to "roll its own" exception handling and infrastructure, whereas Sun probably offloads alot of that to proprietary, platform-specific libraries.
--Joe--
It would appear Intel is trying to keep its x86 flavor more attractive than other x86 flavors by stacking the compilers in its favor as well. I might be cynical, but I think that Intel is banking on getting a few of the ducats that people are saving on Open-Source Software by having them upgrade to an Intel x86 instead of an AMD or Cyrix part.
After all, the compiler supports Intel-specific optimizations, so why not?
The problem, of course, is the fact that AMD and Cyrix probably do not have the resources to fund/promote similar efforts, so this does end up being a means for Intel to un-level the playing field.
On the bright side, alot of x86-specific tweaks will help all x86 variants, not just Intel's x86s. (For instance, register allocation that understands the highly non-orthogonal IA32 register file would be a big step forward for all x86's. There was an interesting paper in MICRO-31 about that, IIRC. Also, scheduling to avoid AGIs and other hazards generally helps all flavors.) So, the picture isn't as bad as the paragraph above might have painted.
Nonetheless, if you want AMD-specific tweaks to GCC, then why don't you see if you can contribute to the tweaking effort? Even if all that means is beta-testing proposed changes on your machine for robustness and performance improvements, it'll still help. Poke around egcs.cygnus.com and ask what's up.
--Joe--
At least, not directly or completely. But, it is in WinNT's heritage.
From what I recall, the family tree looks something like this:
VMS--
(The dots are for spacing, since PRE tags aren't allowed.
Basically, VMS begat CP/M -- VMS for the 16-bit minis, CP/M for the 8-bit micros -- and CP/M begat DOS. Win16 and Win32 built up on DOS, and WinNT inherited from Win32 and from VMS directly.
--Joe--