This is a one way dump for debugging purposes. You cannot dump the tree, do some transformations on it, and then reimport it again into GCC. That would be the kind of thing that the policy wants to forbid.
You can easily fork GCC, but the problem is maintaining it after the fork, especially if you want to include changes of the mainline GCC after your fork. Beside, it would still be the main GCC that would continue to be used by 99% of the people and so all your efforts are kind of wasted. A far more productive approach on the long run would be to try to make the FSF realize how much their policy is currently blocking GCC development and relax their rules.
GCC has some improvements and may produce a bit faster code, thought not that significantly better. The new tree-saa framework will only be available in the next version of GCC. Still, there are a number improvements to libstdc++ in GCC 3.4 and this could actually make a difference in some of the benchmarks.
You should also note that lately, the GCC developers have put more effort in speeding up libstdc++. You might want to check the GCC 3.4 release notes and the Proceedings of the GCC summit in that context.
Unfortunately, the FSF currently has a rather strict policy regarding GCC development which does not permit implementing features like LLVM. I hope this policy will change some time as currently it seems to be a bit blocking for certain interresting features that could be implemented. See the following discussion for this policy:
http://gcc.gnu.org/ml/gcc/2003-11/msg00402.html
Since GCC 3, the GCC developers have a very strong tendancy to strictly adhere to standards and even to deprecate or remove non standard GCC extensions, especially those that become problematic because they syntactically interfere with newer C99 features. What makes the kernel non portable accross compilers is more the stuff like inline assembly or directives that control where some pieces of code are located in memory. This kind of stuff is inherently non portable, but there is little one can do about it. Note that given GCC is the standard compiler for the Linux platform, Intel has gone so far as to add those GCC extensions that are necessary to compile the kernel. With just a minimum number of patches, icc thus manages to compile the linux kernel.
The Fortran 95 compiler has not been released yet. It is part of the mainline which will become GCC 3.5 or 4.0 depending on what version number they will finally agree on for the next version. The new version is tentatively scheduled for the end of the year. If you want to test it right now, you can always try the weekly development snapshots.
The web site may be using a bit of an ambiguous wording but is not fundamentally wrong. Here are my comments to the article and to various comments you made:
- While the article only mentions the Intel processors from the x86 family, I consider it a big omission not to have mentioned the some earlier Intel processors which lead to the x86 family. There was the 4 bit Intel 4004 processor which is generally considered as the first microprocessor. This was followed by an 8 bit processor, the 8008 which later evolved into the 8080 processor. The 8080 processor was used as a base for CPM, a very popular PC operating system, and the 8080 design was copied by Zilog to create the Z80 processor which was an 8080 clone which could run the same CP/M software. The latest 8 bit processor from the Intel 8080 family was the 8085. After that, they expanded their design to 16 bits and created the 8086. The reason why IBM chose the Intel 8088 processor for their first IBM PC rather than another processor family was precisely because of the already important collection of CP/M software for the 8080 processor, and given the similarity between the 8080 and the 8088, IBM considered it would be easy for software companies to port their programs to the 8088 processor. They also wanted to use CP/M, bit for some reason, they couldn't make a deal with Digital Research, so that they settled for an OS that implemented an exact copy of the CP/M APIs which was MSDOS.
- The reason why the 80186/80188 processors were not popular, in spite of their richer functionality and better performance was the lack of hardware compatibility. In fact, the 80186 came with a number of on chip IO controllers which were implemented in a way that was incompatible with IBM's PC design. So with the 80186 processor, you could not built a fully IBM compatible PC. NEC learned from Intel's errors. The V20 and V30 were hardware compatible with the 8088/8086 processors, but implemented the richer instruction set and performance improvements of the 80186/80188
- The statement that the 80286 was the first "real" processor is of course a very poor formulation. What was new with the 80286 is that it was the first Intel processor with hardware support for multitasking Operating Systems by implementing task descriptor tables and memory protection. Also, the statement of having to "warm boot" to return to real mode is misleading. The reality is that you have to *reset* the processor to return to real mode. Like others already explained, the PC/AT BIOS used a magic flag in CMOS memory to remember the return to real mode and not perform a complete reboot. In the beginning, resetting the 80286 was done with the help of an extra feature built into the keyboard controller. However this was slow. Later people discovered a trick to do a faster reset by deliberately causing a triple fault on the processor. When with C&T the area of chipsets started to emerge, chipset manufacturers built a fast reset feature into their chipsets.
Marcel
Re:Fixed C++ ABI ... finally
on
GCC 3.4.0 Released
·
· Score: 4, Informative
A post above contradicts this, so I may be wrong about this...but I DO think I was remembering the binary incompatibility occurring in the 3.3 series correctly in this case. (My impression is that 3.4 doesn't have too many 'new features' beyond 3.3, but had more of a focus on optimizing the compile speed of 3.3.)
Well, you are wrong in a number of ways:
1) Like you already noticed yourself, GCC doesn't have the even/odd numbered version logic of Linux. Each version number is a release version. Development versions have the next release version with a date attached to the version. The development process is formalized and is described here
2) GCC 3.4 is a regular new version with a number of new features. It is certainly not a minor version with just some compile speed tuning. I would consider the changes from 3.3 to 3.4 bigger than the previous changes from 3.2 to 3.3.
3) The real oddball in the GCC 3.x series is GCC 3.2.x. This is just a bugfix version of GCC 3.1. However as some of the bugs fixed were a major C++ ABI issue and fixing those bugs lead to incompatibility, the GCC developers decicded to exceptionally increment the version number not following the regular release scheme.
I think enough other people have already pointed out that the kind of comparision done in this article is rather useless. Different languages are designed for different uses, and while some languages might favour faster code, other might favour ease of development or portability. Anyway, even when remaining within a same language or language family, the benchmarks are still quite meaningless. For instance when you want to compare the Performance of MSVC++ and GCC. The benchmark has several flaws: - the code is too trivial. It doesn't show how good the compilers really are at optimizing - the code is too library dependent. For instance, in the trig benchmark, only the runtime library is really benchmarked and not the code generated by the compiler itself - for the floating point benchmarks, the options chosen for both compilers do not match. For MSVC++, the options chosen favour speed over accuracy, while the GCC options favour accuracy over speed.
The last point can very easily be illustrated with the trig benchmark. On my computer (P4, 2.8GHz), I get the following results:
1) Options from the article: 10.9s 2) additional option -ffast-math : 6.9s (this option is also a significant win for the double benchmark) 3) options above plus linking with CRT_fp8.o : 2.8s
The last option may need some explanation: Programs compiled by MSVC++ by default set the math coprocessor to 64bit, while GCC programs set it to 80bit. Linking with CRT_fp8.o on Windows platforms makes GCC programs behave like MSVC++ programs and only use 64bit precision. For arithmetic operations, this makes no difference, but the built in transcedental functions become much faster if you reduce the precision of the coprocessor. So all in all, be were able to reduce the speed of the trig benchmark by a factor 3.9 just by changing the compilation options. This is almost exactly the difference seen in the article between the MSVC++ and the GCC results for the trig benchmark.
All in all, for trivial benchmarks like this, if you chose matching compilation options, different compilers give you almost the same results.
The only real weakness that GCC is showing is 64bit integer arithmetic. These are badly implemented in GCC and could be vastly improved.
Like I explained in my initial message, there are 2 competing G95 projects:
http://g95.sourceforge.net/ and http://gcc-g95 .sourceforge.net/
Both compilers are still in development, and IMHO not suitable for production use. The second project is the one that got the blessing from the GCC developers and is targeted to be included in GCC 3.5. This will hoever still take some time as currently GCC 3.4 hast not even been released yet. If you want to play with G95, both projects have snapshots available for you to download. Just follow the appropriate links on the web pages.
Well, I think it's still a bit early for production use. In its current state, it may be fine to play around with and help the developers, but I don't think it is good enough yet for real world programming.
Like others said, I think it is not so much the existance of G77 that hurts Fortran popularity, but rather the lack of free Fortran 90 or 95 compilers. The good news is that this is going to change. The G95 project is well on its way implementing a Fortran 95 frontend for GCC. Alas, this is kind of clouded by sad news. In fact, the G95 development has split up and there are now 2 separate projects: http://gcc-g95.sourceforge.net/ and h ttp://g95.sourceforge.net/
While sometimes competition is good, I think this is not the case here. In fact, there are not so many people with enough knowledge on Fortran 95 and on compiler development, and so this project splitting is just a terrible waste of scarse resources.
I don't know where you get those numbers from, but I'm talking about the numbers at http://www.myownlittleworld.com/computers/gcctable.html
The numbers in the first table on the page show GCC 3.1.1 to take more time than 3.2.3 for all cases except for -O1 where there is only a 0.01s difference. Also, I have not been able to correlate the obsolute numbers of the first table to the percentages of the second table on that page.
At least the percentages of these stats need to be recalculated. In fact, from the absolute numbers, you can see that GCC 3.2.3 is faster at any optimization level compared to 3.1.1. Yet, the author claims it is slower in his percentage table.
Also, to help developers, an effort has been made to speed up GCC 3.3.x at -O0 where it is faster than GCC 3.1.x and 3.2.x.
The major compilation slowdown occured between 2.95 and 3.0. It was mainly due to the new garbage collection based memory management scheme and the new inliner. Since GCC 3.0, the compilation speed didn't change that much except maybe for some programs that happened to be particularly bad for the inliner heuristics.
Just read the TenDRA FAQ. Currently It's too early to even call TenDRA a C++ compiler:
3.1. Compiling simple C++ programs does not work.
At this point, TenDRA only contains the bare minimum language support library, not the full standard C++ library. See the C++ producer documentation for more details.
Re:I don't get it? Updates to an obseleted arch?
on
GCC 3.3.1 Released
·
· Score: 2, Insightful
Check the release notes more clearly. The m68k architecture as a whole is not removed. Only certain OS types for m68k have been obsoleted. Generally, targets are being obsoleted when they have been broken for some time because of lack of maintainer for the platform and no one seems to bother about it.
Quite on the contrary. It's ICANN that is contributing to the mess by keeping the top level doimans scarce so that there is a lot of money to make in the domain business. If ICANN would open up the top level domains, then there would be no need to misuse the country TLDs.
The current SCO is the former Caldera and not the former SCO. In fact, the former SCO was bought up by Caldera, and later, Caldera changed their name to SCO to reflect the fact that they make most of their money with Unix licenses. So the 7 years relect on the existence of Caldera, not the old SCO.
Read the GCC documentation, and you will see that i686 is just an alias for Pentiumpro. If your processor does not support the cmov instruction, then it is not Pentiumpro compatible and i686 is the wrong option for you. The cmov instruction is the single most important additional instruction activated by -march=i686 . If you remove that instruction, you severely cripple GCC for all users of Intel processors of really compatible processors. If you want your code to be scheduled for i686, but not use the additional instructions, you can still do that using -mcpu=i686 and -march=i585 . So GCC already has all the options you need to properly compile your programs for any possibly minimum/optimal processor combination you want. Don't ask developers to cripple GCC just because you are using an incompatible processor.
The main problem is that there is no i586 and i686. After the i486, Intel started calling their processors by names. Overall, there is a high ambiguity of when a processor is an i586 or i686, especially when it comes to non Intel processors and whether they support some specific instructions. The GCC developers realized that and therefore included -mcpu and -march options for a wide variety of cpu types. For compatibility reasons, the i586 and i686 options just alias to pentium and pentiumpro. If your processor is not 100% intruction compatible with an Intel Pentium or Pentiumpro, then you should better use a more approriate processor type when compiling. If you check the available options at http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/i386-and -x86-64-Options.html , you will see that there is even a c3 option available.
AMD is helping the GCC project by funding the development work to include support for 64bit AMD processors and improve support for other AMD processors as well. The work is actually carried out by GCC specialists from Suse, but AFAIK, AMD is at least partly paying for this.
Slashdot Mirror
This is a one way dump for debugging purposes. You cannot dump the tree, do some transformations on it, and then reimport it again into GCC. That would be the kind of thing that the policy wants to forbid.
The GCC web site has a documentation here
You can easily fork GCC, but the problem is maintaining it after the fork, especially if you want to include changes of the mainline GCC after your fork. Beside, it would still be the main GCC that would continue to be used by 99% of the people and so all your efforts are kind of wasted.
A far more productive approach on the long run would be to try to make the FSF realize how much their policy is currently blocking GCC development and relax their rules.
GCC has some improvements and may produce a bit faster code, thought not that significantly better. The new tree-saa framework will only be available in the next version of GCC.
Still, there are a number improvements to libstdc++ in GCC 3.4 and this could actually make a difference in some of the benchmarks.
You should also note that lately, the GCC developers have put more effort in speeding up libstdc++. You might want to check the GCC 3.4 release notes and the Proceedings of the GCC summit in that context.
Unfortunately, the FSF currently has a rather strict policy regarding GCC development which does not permit implementing features like LLVM. I hope this policy will change some time as currently it seems to be a bit blocking for certain interresting features that could be implemented. See the following discussion for this policy:
http://gcc.gnu.org/ml/gcc/2003-11/msg00402.html
This changed quite recently and Microsoft has now made the non crippled version of VC available for free download (command line online, not full IDE).
Since GCC 3, the GCC developers have a very strong tendancy to strictly adhere to standards and even to deprecate or remove non standard GCC extensions, especially those that become problematic because they syntactically interfere with newer C99 features. What makes the kernel non portable accross compilers is more the stuff like inline assembly or directives that control where some pieces of code are located in memory. This kind of stuff is inherently non portable, but there is little one can do about it. Note that given GCC is the standard compiler for the Linux platform, Intel has gone so far as to add those GCC extensions that are necessary to compile the kernel. With just a minimum number of patches, icc thus manages to compile the linux kernel.
The Fortran 95 compiler has not been released yet. It is part of the mainline which will become GCC 3.5 or 4.0 depending on what version number they will finally agree on for the next version.
The new version is tentatively scheduled for the end of the year. If you want to test it right now, you can always try the weekly development snapshots.
The web site may be using a bit of an ambiguous wording but is not fundamentally wrong. Here are my comments to the article and to various comments you made:
- While the article only mentions the Intel processors from the x86 family, I consider it a big omission not to have mentioned the some earlier Intel processors which lead to the x86 family.
There was the 4 bit Intel 4004 processor which is generally considered as the first microprocessor. This was followed by an 8 bit processor, the 8008 which later evolved into the 8080 processor. The 8080 processor was used as a base for CPM, a very popular PC operating system, and the 8080 design was copied by Zilog to create the Z80 processor which was an 8080 clone which could run the same CP/M software. The latest 8 bit processor from the Intel 8080 family was the 8085. After that, they expanded their design to 16 bits and created the 8086.
The reason why IBM chose the Intel 8088 processor for their first IBM PC rather than another processor family was precisely because of the already important collection of CP/M software for the 8080 processor, and given the similarity between the 8080 and the 8088, IBM considered it would be easy for software companies to port their programs to the 8088 processor. They also wanted to use CP/M, bit for some reason, they couldn't make a deal with Digital Research, so that they settled for an OS that implemented an exact copy of the CP/M APIs which was MSDOS.
- The reason why the 80186/80188 processors were not popular, in spite of their richer functionality and better performance was the lack of hardware compatibility. In fact, the 80186 came with a number of on chip IO controllers which were implemented in a way that was incompatible with IBM's PC design. So with the 80186 processor, you could not built a fully IBM compatible PC. NEC learned from Intel's errors. The V20 and V30 were hardware compatible with the 8088/8086 processors, but implemented the richer instruction set and performance improvements of the 80186/80188
- The statement that the 80286 was the first "real" processor is of course a very poor formulation. What was new with the 80286 is that it was the first Intel processor with hardware support for multitasking Operating Systems by implementing task descriptor tables and memory protection. Also, the statement of having to "warm boot" to return to real mode is misleading. The reality is that you have to *reset* the processor to return to real mode. Like others already explained, the PC/AT BIOS used a magic flag in CMOS memory to remember the return to real mode and not perform a complete reboot.
In the beginning, resetting the 80286 was done with the help of an extra feature built into the keyboard controller. However this was slow. Later people discovered a trick to do a faster reset by deliberately causing a triple fault on the processor. When with C&T the area of chipsets started to emerge, chipset manufacturers built a fast reset feature into their chipsets.
Marcel
Well, you are wrong in a number of ways:
1) Like you already noticed yourself, GCC doesn't have the even/odd numbered version logic of Linux. Each version number is a release version. Development versions have the next release version with a date attached to the version. The development process is formalized and is described here
2) GCC 3.4 is a regular new version with a number of new features. It is certainly not a minor version with just some compile speed tuning. I would consider the changes from 3.3 to 3.4 bigger than the previous changes from 3.2 to 3.3.
3) The real oddball in the GCC 3.x series is GCC 3.2.x. This is just a bugfix version of GCC 3.1. However as some of the bugs fixed were a major C++ ABI issue and fixing those bugs lead to incompatibility, the GCC developers decicded to exceptionally increment the version number not following the regular release scheme.
Marcel
I think enough other people have already pointed out that the kind of comparision done in this article is rather useless. Different languages are designed for different uses, and while some languages might favour faster code, other might favour ease of development or portability.
Anyway, even when remaining within a same language or language family, the benchmarks are still quite meaningless. For instance when you want to compare the Performance of MSVC++ and GCC. The benchmark has several flaws:
- the code is too trivial. It doesn't show how good the compilers really are at optimizing
- the code is too library dependent. For instance, in the trig benchmark, only the runtime library is really benchmarked and not the code generated by the compiler itself
- for the floating point benchmarks, the options chosen for both compilers do not match. For MSVC++, the options chosen favour speed over accuracy, while the GCC options favour accuracy over speed.
The last point can very easily be illustrated with the trig benchmark.
On my computer (P4, 2.8GHz), I get the following results:
1) Options from the article: 10.9s
2) additional option -ffast-math : 6.9s
(this option is also a significant win for the double benchmark)
3) options above plus linking with CRT_fp8.o : 2.8s
The last option may need some explanation:
Programs compiled by MSVC++ by default set the math coprocessor to 64bit, while GCC programs set it to 80bit. Linking with CRT_fp8.o on Windows platforms makes GCC programs behave like MSVC++ programs and only use 64bit precision. For arithmetic operations, this makes no difference, but the built in transcedental functions become much faster if you reduce the precision of the coprocessor. So all in all, be were able to reduce the speed of the trig benchmark by a factor 3.9 just by changing the compilation options. This is almost exactly the difference seen in the article between the MSVC++ and the GCC results for the trig benchmark.
All in all, for trivial benchmarks like this, if you chose matching compilation options, different compilers give you almost the same results.
The only real weakness that GCC is showing is 64bit integer arithmetic. These are badly implemented in GCC and could be vastly improved.
Marcel
Like I explained in my initial message, there are 2 competing G95 projects:
5 .sourceforge.net/
http://g95.sourceforge.net/
and
http://gcc-g9
Both compilers are still in development, and IMHO not suitable for production use. The second project is the one that got the blessing from the GCC developers and is targeted to be included in GCC 3.5. This will hoever still take some time as currently GCC 3.4 hast not even been released yet.
If you want to play with G95, both projects have snapshots available for you to download. Just follow the appropriate links on the web pages.
Marcel
Why not use gfortran ?
Well, I think it's still a bit early for production use. In its current state, it may be fine to play around with and help the developers, but I don't think it is good enough yet for real world programming.
Marcel
Like others said, I think it is not so much the existance of G77 that hurts Fortran popularity, but rather the lack of free Fortran 90 or 95 compilers.
h ttp://g95.sourceforge.net/
The good news is that this is going to change. The G95 project is well on its way implementing a Fortran 95 frontend for GCC.
Alas, this is kind of clouded by sad news. In fact, the G95 development has split up and there are now 2 separate projects:
http://gcc-g95.sourceforge.net/
and
While sometimes competition is good, I think this is not the case here. In fact, there are not so many people with enough knowledge on Fortran 95 and on compiler development, and so this project splitting is just a terrible waste of scarse resources.
Marcel
I don't know where you get those numbers from, but I'm talking about the numbers at http://www.myownlittleworld.com/computers/gcctable .html
The numbers in the first table on the page show GCC 3.1.1 to take more time than 3.2.3 for all cases except for -O1 where there is only a 0.01s difference. Also, I have not been able to correlate the obsolute numbers of the first table to the percentages of the second table on that page.
Marcel
At least the percentages of these stats need to be recalculated. In fact, from the absolute numbers, you can see that GCC 3.2.3 is faster at any optimization level compared to 3.1.1. Yet, the author claims it is slower in his percentage table.
Also, to help developers, an effort has been made to speed up GCC 3.3.x at -O0 where it is faster than GCC 3.1.x and 3.2.x.
Marcel
The major compilation slowdown occured between 2.95 and 3.0.
It was mainly due to the new garbage collection based memory management scheme and the new inliner.
Since GCC 3.0, the compilation speed didn't change that much except maybe for some programs that happened to be particularly bad for the inliner heuristics.
Marcel
3.1. Compiling simple C++ programs does not work.
At this point, TenDRA only contains the bare minimum language support library, not the full standard C++ library. See the C++ producer documentation for more details.
Check the release notes more clearly. The m68k architecture as a whole is not removed. Only certain OS types for m68k have been obsoleted. Generally, targets are being obsoleted when they have been broken for some time because of lack of maintainer for the platform and no one seems to bother about it.
Marcel
Quite on the contrary. It's ICANN that is contributing to the mess by keeping the top level doimans scarce so that there is a lot of money to make in the domain business. If ICANN would open up the top level domains, then there would be no need to misuse the country TLDs.
Marcel
The current SCO is the former Caldera and not the former SCO. In fact, the former SCO was bought up by Caldera, and later, Caldera changed their name to SCO to reflect the fact that they make most of their money with Unix licenses. So the 7 years relect on the existence of Caldera, not the old SCO.
Read the GCC documentation, and you will see that i686 is just an alias for Pentiumpro. If your processor does not support the cmov instruction, then it is not Pentiumpro compatible and i686 is the wrong option for you. The cmov instruction is the single most important additional instruction activated by -march=i686 . If you remove that instruction, you severely cripple GCC for all users of Intel processors of really compatible processors. If you want your code to be scheduled for i686, but not use the additional instructions, you can still do that using -mcpu=i686 and -march=i585 . So GCC already has all the options you need to properly compile your programs for any possibly minimum/optimal processor combination you want. Don't ask developers to cripple GCC just because you are using an incompatible processor.
Marcel
The main problem is that there is no i586 and i686. After the i486, Intel started calling their processors by names. Overall, there is a high ambiguity of when a processor is an i586 or i686, especially when it comes to non Intel processors and whether they support some specific instructions. The GCC developers realized that and therefore included -mcpu and -march options for a wide variety of cpu types. For compatibility reasons, the i586 and i686 options just alias to pentium and pentiumpro. If your processor is not 100% intruction compatible with an Intel Pentium or Pentiumpro, then you should better use a more approriate processor type when compiling.d -x86-64-Options.html , you will see that there is even a c3 option available.
If you check the available options at http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/i386-an
Marcel
AMD is helping the GCC project by funding the development work to include support for 64bit AMD processors and improve support for other AMD processors as well. The work is actually carried out by GCC specialists from Suse, but AFAIK, AMD is at least partly paying for this.
Marcel