Why would you by a "web printer" if at the same time you want to block its access to or from the internet?
Let's just see what we are talking about here:
- the is a printer whose purpose is to allow direct printing from the web
- the direct printing from the web is done through the HP ePrintCenter which is a service hosted by HP and which accepts the print jobs.
- your printer merly connects to HP ePrintCenter to pull jobs from there are do any other tasks it is being told to do
So if you in any way block the access from your printer to HP ePrintCenter, then you effectivly block your pritner's ability to print (or at least to use the web printing, I don't know if these printers can also do local printing), and in that case, why did you buy this printer in first place?
I guess you misunderstand how these printers work. HP has an internet platform called HP ePrintCenter. Jobs from other sources are sent to that HP site and your printer pulls the jobs from there. So no one will try to connect directly to your printer, but your printer will try to connect to the internet to find jobs to print.
No, that's wrong. What killed the Alpha was HP's business decision to drop the Alpha in favour of the Itanium. The Itanium while not so much a success in terms of units sold, was nevertheless in incredible success in the hype it created and cause most of the competing processors (PARISC, Alpha, MIPS) to abandon the market even before the Intanium shipped! Only Sun with the Sparc and IBM with their Power architecture didn't follow the hype and continued with their processors.
NIS had a significant benefit in having control on the Etehreal name and web site. In fact, they have a daughter company called Ethereal software http://www.etherealsoft.com/ for which the business consists in providing services aroung Ethereal. By having control of the Ethereal name and web site, they have a very distinct advantage in promoting their services compared to other companies that would provide services around Ethereal. I can very well understand why they didn't want to give up the name Etehreal as giving up the name might mean the death of "Ethereal Software".
Marcel
Fixing security issues and improving coding style to avoid security issues has been a very bog concern in the Etehreal/Wireshark project over that last couple of years. for instance, unsafe string operations are now no longer tolerated in the code (e.g. the strxxx functions). A couple of people have run various source code analyzers against Ethereal/Wireshark, and each time, the developers where quick in fixing the issues found. Even for coverty, the statistics look very good compared to most other open source projects: http://scan.coverity.com/ Also, given the rather quick release cycle, the fixes quickly make it into releases. So all in all, Etehreal/Wireshark is a very good project regarding security.
Please when you read the article, don't forget who is behind the study. This is one of those typical statistical claims that people use to push their products. In this case, it is a company specialized in helping people to make their patent filings and they try to use statistics to scare people making them think that their patent filings might be invalid due to mistakes and thus hope they use the services of the company. If you really want reliable statistics on the number of patent filings with mistakes and on the consequences off those mistakes, you should never trust such claims from a company who uses them purely for marketing purposes. This is a bit similar to Microsoft's TCO claims on Windows versus Linux.
I simply say that the source of these statistics is biased and as such the statistics are unreliable. They might or might or might not be true, but I would certainly not trust them.
The feature to allow different types of names in one file system is not unique to Microsoft. In fact, Novell NetWare has the feature of what they call "name spaces" since the release of NetWare 386. The difference however is that with NetWare, this was a feature included in the file system design whereas for Microsoft, it was a cludge added at the time Windows 95 was developped.
The original Posix subsystem that Microsoft provided was rather limited and therefore not very useful. However a company called Internix create a software package that built upon the Posix subsystem but provided a complete Unix like environment with shell and all the standard tools. A couple of years ago, Microsoft bought Internix and now provides the software for free to Windows users. Their main purpose of the software is to allow people using applications that run on Unix to easily migrate their application to Windows using the Posix subsystem. One of the main examples of such a use is Microsoft's own Hotmail service which originally ran on Unix and which Microsoft later migrated to Windows using the Posix personality of Windows to keep all the existing code and scripts.
The author of the article was much more prudent. He said one of the most widely used formats. The person who submitted the story thought he could improve on that by dropping the "one of".
Beside the cachae considerations which were discussed by numerous people here, there is one aspect that hasn't been mentioned. The reason why hyperthreading was introduced in first place was to reduce the "idle" time of the processor. The Pentium 4 class processors have an extremely long pipeline and this often leads to pipeline stalls. E.g. the processing of an instruction cannot proceed because it depends on the result of a previous instruction. The idea of hyperthreading is that whenever there is a potential pipeline stall, the processor switches to the other thread which hopefully can continue its executon because it isn't stalled by some dependency. Now most pipeline stalls occur when the code being executed isn't optimized for Pentium 4 class processors. However the better Pentium 4 optimized your code is, the less pipeline stalls you have and the better your CPU utilisation is with a single thread.
Re:How does this compare to RC5-64?
on
RSA-640 Factored
·
· Score: 4, Informative
You are completely off track here and made 2 huge mistakes in your comparison:
1) The number RSA-640 has 193 *decimal* digits, but 640 bits (as the number in RSA-640 indicates).
2) You are comparing symetric key suzes (RC5-64 = 64 bit) with assymetric key sizes (RSA-640 640 bit). You can't compare these key sizes directly. Assymetric key sizes are much bigger than symetric key sizes for the same level of security. So you are trying to compare numebrs that simply cannot be compared.
Ulrich Drepper certainly is an important contributer of OSS by being the GLIBC maintainer. However specifically the glibc project is often a huge source of problems because of all the "magic" glibc tries to do in its headers. For the last few version of GCC, all this "magic" actually causes the compiler to produce worse code compared to if the header files would just restrict themselves to define the appropriate macros and prototypes. More than once, the GCC folks have to strugly to get newer versions of GCC to work with older versions glibc because of all the cruft in it.
I think before criticizing maintainers for other platforms where GCC is ported, he should look at how much special work his own project causes for GCC and see if he can do his own contributions to making GCC development easier by simplifying the glibc headers.
As far as inlining is cencerned, the heuristics in GCC 4.0 have significantly changed, especially to fight astronomous compilation times in some pathological cases. However GCC 4.0 still has a lot of tuning knobs for inlining, and if you suspect inlining changes to be responsible for the performance difference, then playing with the inlining parameters might restore the old performance.
Before coming to the actual topic of my message, I just wanted to point out that this is a 2 year old test from April 2003. So the age of the test alone should make the results of limited value today.
However I would like to comment on how these kind of tests are performed in general. Maybe this will outrage you, but I make the bold claim that Veritest is not to blame for the test being biased. In fact, tests like these work like follows: - Microsoft has its own labs where they continuesly test their own products and competing products for performance and they try to find special scenarios where indeed their product is indeed better than the competition. Once they have developped such a scenario, they pay some testing company to do the tests according to the scenario devised by Microsoft. The testing company then just does the job its payed for and performed the tests accodring to the scenario imposed to them. Of course, they get the same results as Micrsoft and they can in all good conscience certify that in the giving scenario, the MS product is indeed faster than the competing product. So in the end, the testing company just did their job, e.g. run a Benchmark in a very particular scenario which was imposed to them. The testing company did in now way favour MS in the results. They didn't have to because the testing conditions were already biased.
Just to show how this has always been common practice, take the case of (I think it was) Netcraft a couple of years ago. They were commissioned by MS to do a benchmark which proved that Active Direcotry was faster than Novell's eDirectory. At about the same time, Novell commissioned the same company to do a benchmark that proved eDirectory to be faster than Active Directory. Of course, the testing scenarios for both cases were different. The testing company faithfully published the 2 results. E.g. they published that their benchmark proved Active Directory to be faster than eDirectory, and the published the results proving eDirectory to be faster than Active Directory.
Unlike some people my think, the GCC developers are actually responsive to feedback if it is done in a helpful way. For instance, a performance degradation like reported by you is considered a bug by the GCC develoeprs, and what you should do in that case is submit a proper bug report, and the GCC develoeprs will look at it.
The recommended compiler for linux 2.6.x is the main compiler which was used when linux 2.6 was released. The linux developers don't want to officially switch compilers in mid term of a version because that would be a potential additional source of bugs. It does not necessarily mean that newer GCC version would be less good. It's just that it might produce code that would behave differently for whatever reason and it would make development more difficult.
A much better indicator on GCC quality is to see what versions various Linux distributions actually use. For instance, if you take SuSE pro 9.3, it uses GCC 3.3.5.
Most of the work for AMD64 support in GCC was spondored by AMD, but actually executed by Jan Hubicka (SuSE). Other companies were involved as well as shown on the AMD64 web site http://www.amd64.org/ As for GCC 4.0 being slower than 3.4 in the benchmarks shown, maybe it's just because of the issue described in the following message: http://gcc.gnu.org/ml/gcc/2005-04/msg01733.html
It seems that certain types of 64 bit floating point code suffer from some stupid optimizations done in the GLIB header files. I think it is worthwhile reading the following message for people needing fastest possible floating point code on AMB64 processors: http://gcc.gnu.org/ml/gcc/2005-04/msg01733.html
The only way to guarantee compatibility with existing code is to never change the compiler and simply stop compiler development. That way, you are sure that things won't change and that programs never change. However whenever you change something to the compiler, there is always the potential for programs to break. Of course, you can limit the breakage by keeping around some non standard features or by keeping a certain level of bug compatibility. However this is not always easy, and it also requires more development resources that especially in the case of GCC might not always be available.
While sometimes decisions to drop some non standard features may be debatable, a lot of changes that caused some upset of the users where nevertheless difficult to avoid. Let's just take a few examples:
1) strict aliasing. Strict aliasing is quite an essential feature when it comes to be able to implement a number of optimizations where you need to know whether a certain variable may or may not change in some piece of code. The instroduction of strict aliases caused a lot of upset when it was first enabled by default in GCC 2.95. Therefore, it was temporarily disabled by default in later revisions of GCC 2.95 and was only made default again in GCC 3.0. With options like this, you have to enable them some day or people will keep writing erronous code and certain optimizations will never be able to be done.
2) C++ changes in GCC 3.0. With GCC 3.x, there was a clear desire from the GCC developers to move towards C++ standard compliance. Unfortunately, prior GCC versions were rather far away from the C++ standard and thus breakage of existing programs relying on older non standard behaviour was unavoidable
3) The move towards more C++ standard compliance went on with further versions in the GCC 3.x family. The probably most important step was GCC 3.4 where the old Bison based inadequate C++ parser was replaced by a completely new handwritten parser which was written based on the C++ standard and not based on the limitations that the old parser might have had. Given that a number of C++ programs still relied on the old parser accepting non standard code, the new parser rejected this code.
Actually, you could consider EGCS as an intermediate version between GCC 2 and 3. After GCC 2.7, the most important GCC developers jumped ship and started the EGCS development based on the original GCC code, but introducing many new optimization ideas. After this, the original GCC development died. There was still a version 2.8, but that was not very popular. GCC 2.7.x however had a rather long carreer as system compiler for Linux kernels and for some time, the Linux kernel code depended on quirks of this compiler making it incompatible with EGCS or GCC 2.95 or later.
As EGCS became more and more popular, the FSF approached the EGCS steeing comitee and proposed them to become the official GCC project. This lead to one intermediate release GCC 2.95 which was kind of the last version of the EGS code. After this, the GCC developers made some important changes to GCC leading to GCC 3.0. The main target for GCC 3.0 was better C++ support, but unfortunately, the architecture changes inside GCC lead to a major slowdown of the compiler while not making any significant change in the generated code quality. That is why GCC 3.0 did not generate too much enthusiam among developers (except for some C++ developers which finally got features that had been missing before).
All in all, while from the version number point of view EGCS was labelled as GCC 2.9x, it was actually different enough from the old GCC 2 that you could consider it another major version between 2 and 3. As such, there is not really such a change of development speed between major new versions.
I think there is always a misconception between what people think that i586 and i686 should mean and what GCC actually interprets it as being. For GCC, i586 is just an alias for Pentium, e.g. Intel's original Pentium processor, and i686 is an alias for Pentiumpro, eg. Intel's original Pentium pro processors. For these options, GCC tries to create optimal code for the corresponding Intel processors, but nor necessarily for any more or less compatible processors from other manufacturers. Maybe a lot of people don't know it, but GCC has actually a very rich set of processor selections and instead of just choosing between the old i386, i486, i586 and i686 settings, you can much more precisely specify what exact chaip you are using. For details see http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/i386-a nd-x86_002d64-Options.html#i386-and-x86_002d64-Opt ions
As for CMOV being the only useful addition since the i486, I have to disagree. For integer code this may be true, but for floating point code there is a very important addition with the FCOMI, FCOMIP, FUCOMI and FUCOMIP instructions. This instructions allows floating point comparisions which directly set the main processor flags and therefore can directly be fllowed by conditional branch instructions. The old FCOM family of instrustions only set the coprocessor flags and you need a time consuming sequence of instructions to transfer the coprocessor flags to the processor flags in order to be able to make conditional branches based on floating point comparisions. Also, just like the CMOVcc instruction for interger registers, there are the equivalent FCOMVcc instructions for floating point registers.
Apple keeps their own development branch of GCC. They have patches and functionality in their version that do not exist in the official GCC. So Apple's GCC 4.0 is slightly different from the official GCC 4.0.
Slashdot Mirror
Back in 2004 I've read a quite interresting article on ARM. http://news.cnet.com/The-unheralded-monopoly/2010-1006_3-5262581.html As you can see, the strong position of the ARM is not new, maybe just a bit more visible these days.
Why would you by a "web printer" if at the same time you want to block its access to or from the internet? Let's just see what we are talking about here: - the is a printer whose purpose is to allow direct printing from the web - the direct printing from the web is done through the HP ePrintCenter which is a service hosted by HP and which accepts the print jobs. - your printer merly connects to HP ePrintCenter to pull jobs from there are do any other tasks it is being told to do So if you in any way block the access from your printer to HP ePrintCenter, then you effectivly block your pritner's ability to print (or at least to use the web printing, I don't know if these printers can also do local printing), and in that case, why did you buy this printer in first place?
I guess you misunderstand how these printers work. HP has an internet platform called HP ePrintCenter. Jobs from other sources are sent to that HP site and your printer pulls the jobs from there. So no one will try to connect directly to your printer, but your printer will try to connect to the internet to find jobs to print.
No, that's wrong. What killed the Alpha was HP's business decision to drop the Alpha in favour of the Itanium.
The Itanium while not so much a success in terms of units sold, was nevertheless in incredible success in the hype it created and cause most of the competing processors (PARISC, Alpha, MIPS) to abandon the market even before the Intanium shipped! Only Sun with the Sparc and IBM with their Power architecture didn't follow the hype and continued with their processors.
NIS had a significant benefit in having control on the Etehreal name and web site. In fact, they have a daughter company called Ethereal software http://www.etherealsoft.com/ for which the business consists in providing services aroung Ethereal. By having control of the Ethereal name and web site, they have a very distinct advantage in promoting their services compared to other companies that would provide services around Ethereal. I can very well understand why they didn't want to give up the name Etehreal as giving up the name might mean the death of "Ethereal Software". Marcel
Fixing security issues and improving coding style to avoid security issues has been a very bog concern in the Etehreal/Wireshark project over that last couple of years. for instance, unsafe string operations are now no longer tolerated in the code (e.g. the strxxx functions). A couple of people have run various source code analyzers against Ethereal/Wireshark, and each time, the developers where quick in fixing the issues found. Even for coverty, the statistics look very good compared to most other open source projects:
http://scan.coverity.com/
Also, given the rather quick release cycle, the fixes quickly make it into releases. So all in all, Etehreal/Wireshark is a very good project regarding security.
Marcel
Please when you read the article, don't forget who is behind the study.
This is one of those typical statistical claims that people use to push their products. In this case, it is a company specialized in helping people to make their patent filings and they try to use statistics to scare people making them think that their patent filings might be invalid due to mistakes and thus hope they use the services of the company.
If you really want reliable statistics on the number of patent filings with mistakes and on the consequences off those mistakes, you should never trust such claims from a company who uses them purely for marketing purposes. This is a bit similar to Microsoft's TCO claims on Windows versus Linux.
I simply say that the source of these statistics is biased and as such the statistics are unreliable. They might or might or might not be true, but I would certainly not trust them.
Marcel
The feature to allow different types of names in one file system is not unique to Microsoft. In fact, Novell NetWare has the feature of what they call "name spaces" since the release of NetWare 386. The difference however is that with NetWare, this was a feature included in the file system design whereas for Microsoft, it was a cludge added at the time Windows 95 was developped.
Marcel
Just to complete the information you gave:
The original Posix subsystem that Microsoft provided was rather limited and therefore not very useful. However a company called Internix create a software package that built upon the Posix subsystem but provided a complete Unix like environment with shell and all the standard tools.
A couple of years ago, Microsoft bought Internix and now provides the software for free to Windows users. Their main purpose of the software is to allow people using applications that run on Unix to easily migrate their application to Windows using the Posix subsystem. One of the main examples of such a use is Microsoft's own Hotmail service which originally ran on Unix and which Microsoft later migrated to Windows using the Posix personality of Windows to keep all the existing code and scripts.
Marcel
The author of the article was much more prudent. He said one of the most widely used formats. The person who submitted the story thought he could improve on that by dropping the "one of".
Marcel
Beside the cachae considerations which were discussed by numerous people here, there is one aspect that hasn't been mentioned.
The reason why hyperthreading was introduced in first place was to reduce the "idle" time of the processor. The Pentium 4 class processors have an extremely long pipeline and this often leads to pipeline stalls. E.g. the processing of an instruction cannot proceed because it depends on the result of a previous instruction. The idea of hyperthreading is that whenever there is a potential pipeline stall, the processor switches to the other thread which hopefully can continue its executon because it isn't stalled by some dependency. Now most pipeline stalls occur when the code being executed isn't optimized for Pentium 4 class processors. However the better Pentium 4 optimized your code is, the less pipeline stalls you have and the better your CPU utilisation is with a single thread.
Marcel
Have you tried Pathscale compilers http://www.pathscale.com/ekopath.html? They seem to give quite decent performance on AMD64 chips.
You are completely off track here and made 2 huge mistakes in your comparison:
1) The number RSA-640 has 193 *decimal* digits, but 640 bits (as the number in RSA-640 indicates).
2) You are comparing symetric key suzes (RC5-64 = 64 bit) with assymetric key sizes (RSA-640 640 bit). You can't compare these key sizes directly. Assymetric key sizes are much bigger than symetric key sizes for the same level of security. So you are trying to compare numebrs that simply cannot be compared.
Marcel
Ulrich Drepper certainly is an important contributer of OSS by being the GLIBC maintainer. However specifically the glibc project is often a huge source of problems because of all the "magic" glibc tries to do in its headers. For the last few version of GCC, all this "magic" actually causes the compiler to produce worse code compared to if the header files would just restrict themselves to define the appropriate macros and prototypes. More than once, the GCC folks have to strugly to get newer versions of GCC to work with older versions glibc because of all the cruft in it.
I think before criticizing maintainers for other platforms where GCC is ported, he should look at how much special work his own project causes for GCC and see if he can do his own contributions to making GCC development easier by simplifying the glibc headers.
Marcel
Well, I think the article kind of explains it:
2 movie critics work out a common list based on their personal favourites.
Marcel
As far as inlining is cencerned, the heuristics in GCC 4.0 have significantly changed, especially to fight astronomous compilation times in some pathological cases. However GCC 4.0 still has a lot of tuning knobs for inlining, and if you suspect inlining changes to be responsible for the performance difference, then playing with the inlining parameters might restore the old performance.
Marcel
Before coming to the actual topic of my message, I just wanted to point out that this is a 2 year old test from April 2003. So the age of the test alone should make the results of limited value today.
However I would like to comment on how these kind of tests are performed in general.
Maybe this will outrage you, but I make the bold claim that Veritest is not to blame for the test being biased. In fact, tests like these work like follows:
- Microsoft has its own labs where they continuesly test their own products and competing products for performance and they try to find special scenarios where indeed their product is indeed better than the competition.
Once they have developped such a scenario, they pay some testing company to do the tests according to the scenario devised by Microsoft.
The testing company then just does the job its payed for and performed the tests accodring to the scenario imposed to them. Of course, they get the same results as Micrsoft and they can in all good conscience certify that in the giving scenario, the MS product is indeed faster than the competing product. So in the end, the testing company just did their job, e.g. run a Benchmark in a very particular scenario which was imposed to them. The testing company did in now way favour MS in the results. They didn't have to because the testing conditions were already biased.
Just to show how this has always been common practice, take the case of (I think it was) Netcraft a couple of years ago. They were commissioned by MS to do a benchmark which proved that Active Direcotry was faster than Novell's eDirectory. At about the same time, Novell commissioned the same company to do a benchmark that proved eDirectory to be faster than Active Directory. Of course, the testing scenarios for both cases were different.
The testing company faithfully published the 2 results. E.g. they published that their benchmark proved Active Directory to be faster than eDirectory, and the published the results proving eDirectory to be faster than Active Directory.
Marcel
Unlike some people my think, the GCC developers are actually responsive to feedback if it is done in a helpful way. For instance, a performance degradation like reported by you is considered a bug by the GCC develoeprs, and what you should do in that case is submit a proper bug report, and the GCC develoeprs will look at it.
Marcel
The recommended compiler for linux 2.6.x is the main compiler which was used when linux 2.6 was released. The linux developers don't want to officially switch compilers in mid term of a version because that would be a potential additional source of bugs. It does not necessarily mean that newer GCC version would be less good. It's just that it might produce code that would behave differently for whatever reason and it would make development more difficult.
b rowse_frm/thread/c2da87604102e689/5d754728f97e5105
The dicussion about recommended GCC versions of the Linux kernel regularly pops up on the kernel mailing list. For instance, you can see one such a discussion here:
http://groups-beta.google.com/group/linux.kernel/
A much better indicator on GCC quality is to see what versions various Linux distributions actually use. For instance, if you take SuSE pro 9.3, it uses GCC 3.3.5.
Marcel
Most of the work for AMD64 support in GCC was spondored by AMD, but actually executed by Jan Hubicka (SuSE). Other companies were involved as well as shown on the AMD64 web site http://www.amd64.org/
As for GCC 4.0 being slower than 3.4 in the benchmarks shown, maybe it's just because of the issue described in the following message:
http://gcc.gnu.org/ml/gcc/2005-04/msg01733.html
Marcel
It seems that certain types of 64 bit floating point code suffer from some stupid optimizations done in the GLIB header files. I think it is worthwhile reading the following message for people needing fastest possible floating point code on AMB64 processors:
http://gcc.gnu.org/ml/gcc/2005-04/msg01733.html
Marcel
The only way to guarantee compatibility with existing code is to never change the compiler and simply stop compiler development. That way, you are sure that things won't change and that programs never change.
However whenever you change something to the compiler, there is always the potential for programs to break.
Of course, you can limit the breakage by keeping around some non standard features or by keeping a certain level of bug compatibility. However this is not always easy, and it also requires more development resources that especially in the case of GCC might not always be available.
While sometimes decisions to drop some non standard features may be debatable, a lot of changes that caused some upset of the users where nevertheless difficult to avoid. Let's just take a few examples:
1) strict aliasing.
Strict aliasing is quite an essential feature when it comes to be able to implement a number of optimizations where you need to know whether a certain variable may or may not change in some piece of code. The instroduction of strict aliases caused a lot of upset when it was first enabled by default in GCC 2.95. Therefore, it was temporarily disabled by default in later revisions of GCC 2.95 and was only made default again in GCC 3.0. With options like this, you have to enable them some day or people will keep writing erronous code and certain optimizations will never be able to be done.
2) C++ changes in GCC 3.0. With GCC 3.x, there was a clear desire from the GCC developers to move towards C++ standard compliance. Unfortunately, prior GCC versions were rather far away from the C++ standard and thus breakage of existing programs relying on older non standard behaviour was unavoidable
3) The move towards more C++ standard compliance went on with further versions in the GCC 3.x family. The probably most important step was GCC 3.4 where the old Bison based inadequate C++ parser was replaced by a completely new handwritten parser which was written based on the C++ standard and not based on the limitations that the old parser might have had. Given that a number of C++ programs still relied on the old parser accepting non standard code, the new parser rejected this code.
Marcel
Actually, you could consider EGCS as an intermediate version between GCC 2 and 3.
After GCC 2.7, the most important GCC developers jumped ship and started the EGCS development based on the original GCC code, but introducing many new optimization ideas. After this, the original GCC development died. There was still a version 2.8, but that was not very popular. GCC 2.7.x however had a rather long carreer as system compiler for Linux kernels and for some time, the Linux kernel code depended on quirks of this compiler making it incompatible with EGCS or GCC 2.95 or later.
As EGCS became more and more popular, the FSF approached the EGCS steeing comitee and proposed them to become the official GCC project. This lead to one intermediate release GCC 2.95 which was kind of the last version of the EGS code. After this, the GCC developers made some important changes to GCC leading to GCC 3.0. The main target for GCC 3.0 was better C++ support, but unfortunately, the architecture changes inside GCC lead to a major slowdown of the compiler while not making any significant change in the generated code quality. That is why GCC 3.0 did not generate too much enthusiam among developers (except for some C++ developers which finally got features that had been missing before).
All in all, while from the version number point of view EGCS was labelled as GCC 2.9x, it was actually different enough from the old GCC 2 that you could consider it another major version between 2 and 3. As such, there is not really such a change of development speed between major new versions.
Marcel
I think there is always a misconception between what people think that i586 and i686 should mean and what GCC actually interprets it as being.a nd-x86_002d64-Options.html#i386-and-x86_002d64-Opt ions
For GCC, i586 is just an alias for Pentium, e.g. Intel's original Pentium processor, and i686 is an alias for Pentiumpro, eg. Intel's original Pentium pro processors. For these options, GCC tries to create optimal code for the corresponding Intel processors, but nor necessarily for any more or less compatible processors from other manufacturers.
Maybe a lot of people don't know it, but GCC has actually a very rich set of processor selections and instead of just choosing between the old i386, i486, i586 and i686 settings, you can much more precisely specify what exact chaip you are using. For details see http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/i386-
As for CMOV being the only useful addition since the i486, I have to disagree. For integer code this may be true, but for floating point code there is a very important addition with the FCOMI, FCOMIP, FUCOMI and FUCOMIP instructions. This instructions allows floating point comparisions which directly set the main processor flags and therefore can directly be fllowed by conditional branch instructions. The old FCOM family of instrustions only set the coprocessor flags and you need a time consuming sequence of instructions to transfer the coprocessor flags to the processor flags in order to be able to make conditional branches based on floating point comparisions.
Also, just like the CMOVcc instruction for interger registers, there are the equivalent FCOMVcc instructions for floating point registers.
Marcel
Apple keeps their own development branch of GCC. They have patches and functionality in their version that do not exist in the official GCC. So Apple's GCC 4.0 is slightly different from the official GCC 4.0.
Marcel