If you want to achive optimal results, use the correct compiler options. There is not really an i686 processor, but as the expression i686 is so commonly used, GCC has it as an alias for Pentiumpro. Now the problem is that the Intel processors based on the Pentiumpro core (this includes the Pentium2 and Pentium3 processors) need a rather strict scheduling for optimal performance whereas the Athlon processors are more relaxed in their scheduling requirements. This means that the i386 option may produce tighter code that while slower on a Pentium Pro/2/3 may actually be faster on an Athlon.
If you really want to see how much the compiler can make of your processor, tell it what processor you are using and don't lie to the compiler. For instance if you take a look at the compiler options for the x86 target http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/i386-a nd-x86_002d64-Options.html#i386-and-x86_002d64-Opt ions you will see that GCC actually knows about the different type of AMD processors. So if you for instance have an AthlonXP and you want to try what the best code is that GCC can produce for your processor, try the option -march=athlon-xp
This is of course no guarantee that your program will run faster. I agree with your overall answer "it depends". Also, I must admit that the Athlon options for 32 bit code may not be so well tuned as the Intel options. This may partly be due to the fact that the Athlon processor is more "flexible" in their code execution and there are less occasions to improve performance by better scheduling.
In conclusion, I think people are too much fixed on the "mythical" i686 option whereas very few people still use processors for which the i686 is the best one. GCC knows a lot of processors and if you want to compile code just for your own machine, tell GCC what processor you *really* have. Also remember that there are 2 options to select the processor: the -mtune and the -march option. -march gives the minimum processor on which the code is to run and influences what kind of instructions can be used at all. -mtune specifies on which processor the code is to be run fastest and incluences instruction scheduling as well as selecting the best instruction in case there would be multiple prossibilities.
I have not done any tests myself nor do I have any numbers to compare. However my guess is that for GCC 4.0, vectorization will still be quite behind the Intel compiler. You should see vectorization support in GCC 4.0 as the first skelleton, but a lot of the vectorization stuff didn't make it for GCC 4.0 and is now scheduled for GCC 4.1. For more details see the following web page: http://gcc.gnu.org/wiki/GCC%204.1%20Projects
As for the speed of GCC, the compilation speed is often a bit disappointing compared to commertial compilers. Dead code elimination is an optimization which GCC already does for a very long time.
The idea that the first CPU runs the main application while the second one does stuff like antivrus, firewall and antispam is naive and doesn't refelect the way these programs really work. Except for complete scans in the case of antivirus or blocking incoming connections for a firewall, most of the checking done by this kind of programs is done in line. E.g. Some application does some action like read a file, open a TCP connection, transfer some stuff from a web site. This action then passes the security program which validates it and only then the underlying OS actually executes the action. All this time, the application sits there waiting for the result. Whether the scanning of the action is done on the same processor as the application, or on a different processor doesn't make a difference here. The time it takes to do the scanning remains the same, and the application has to wait that time. The onl way to gain from multiple processors in this case is if the application is multithreaded. E.g. if the applciation itself has different things it can do while waiting for the scanning to occur. However in this case, the taking advantage of multiple CPUs comes from the application itself. It's the appplciation that takes advantage of the fact that there are multiple CPUs, and this advantage is independent on whether there is security software ot not. So all in all, the idea of the second CPU doing the security scanning in itself is naive. You only gain in speed if you have applications that are able to make use of multiple CPUs themselves, or if you are runnin dufferent (CPU hungry) programs at the same time. In that case, the second CPU does merely compensate for the loss of performance due to the scanning, but there is no real separation of tasks between the main application and the security scanning.
Marcel
Re:g95 to be bundled with duke nukem's next releas
on
GCC 4.0 Preview
·
· Score: 1
I think your are missing one important point:
Neither Gfortran nor G95 are released products. Both projects provide snapshot to give people a preview on what to expect and to help testing for bugs or missing features. However neither Gfortran nor G95 are suited to run important production code, and this was certainly even less the case a couple of months ago, when G95 was still based on an old version of the tree-saa backend.
I think it would have been highly naive for someone to develop fotran programs specifically for those early, unstable and incomplete versions of G95 and Gfortran.
I think both G95 and Gfortran projects are doing exactly what you are asking for. The wait with the official release until they are good enough from the completeness and stability point of view.
Your analogy with MS and Java is completely wrong as MS actually *shipped* their Java version with IE. This is *not* the case with G95 and Gfortran.
What's to stop someone who writes proprietary tools that do nifty things with the IR from releasing their own GPL'd GCC patch that writes out the IR so people can use their proprietary app? Sure, people would have to patch their copy of gcc to use it (or install a pre-patched version), but they could just release RPM's for the latest RHEL and that would be enough for most people (vendors of proprietary software) who would likely use such a tool. It seems like this policy is only making it slightly harder to do that.
Nothing stops people from doing this, and actually it has already be done. For instance, Sun has produced a C backend for GCC so that you can compile any language or dialect support by GCC to a minimum C program which is then fed to Sun's own C compiler and is supposed to produce better code than GCC itself.
However this kind of code takes a lot of work to keep it up to date. For each new version of GCC, a new patch needs to be created. Generally, these projects are therefore "one shot" projects where the code is written once for one version of GCC, and then it remains at that version forever (or at least for a very long time).
With an official internal API or a stable and documented IR, people could write code that would be comptible with multiple versions of GCC without have to make significant changes for each new version of GCC. As such, the overall burden for keeping up non GPL programs that interface with GCC would be much lower.
The alias issue results from casting pointers from one type to another. The background is the following: pointers make it very difficult for a compiler to optimize redundant memory loads or stores. In fact, when a program access data through a pointer, the compiler may not know what other variable gets modified by the pointer access. So all variables for which the compiler cannot prove that they are not accessed through the pointer cannot be kept in registers accross pointer operations. Because this is so penalizing to optimizations, at some point, the C standard has introduced stricter rules as to what variables can be modified by what pointer operations. This essentially boils down to the rule that a pointer access through a certain type (let's say int) is not allowed to access a memory location that is associated with a variable of a different kind (let's say float). So if you take the address of a floating point variable, and store that address in an integer pointer and then access the memory through that integer pointer, the compiler will not notice that in fact the floating point variable gets modified. So the compiler can decide to keep the floating point variable in a register and any access through the integer pointer may not change the floating point variable if you compile with optimization enabled and with strict aliasing. The strict aliasing rules are implemented in all GCC 2.95 and éater versions, but for GCC 2.95, the default options used changed between the different releases based on long and heated discussions whether this kind of optimization should be enabled or disabled by default. So there was no major code change between GCC 2.95.1 and 2.95.3, but rather just the default optimization options changed.
Marcel
Re:g95 to be bundled with duke nukem's next releas
on
GCC 4.0 Preview
·
· Score: 1
Still, the rant is wrong in the sense that it blames an early development version to be not yet complete. The rant would be valid if it said that the *absense* of (a released) G95 was bad for Fortran, but I can't see much truth in a rant which claims that G95 hurt Fortran because it was feature incomplete.
Marcel
Re:confused: gfortran vs. g95
on
GCC 4.0 Preview
·
· Score: 1
I'm sorry, but I have to fundementally disagree with the optimiztations you gave at the end of your message.
Unfortunately, for generations, C programmers have been tought to use pointers to access arrays, and this simply because for a long time, C compilers were not really optimizing compilers and so the programmers where always thinking in the code that the compiler would generate. However nowadays, this is no longer true, and using pointers to access elements in an arry is actually a very bad idea because it prevents the compiler from doing some kind of optimizations as you "hide" the fact from the compiler that you are just accessing a single array and you make it difficult for the compiler to track alias information and do loop unrolling.
I tried your code with GCC 3.4.2 both with integer and floating point data types, and in both cases, the compiler did not generate code to make complicated address calculations, but instead used the indexed addressing modes of the i386 instruction set to directly address the array elements. In this particular case, this results in code more or less equivalent to the pointer code.
However the situation would become different with a loop that would have to access 3 or 4 arrays at the same time. If you used different pointers for each array, a registry starved processor like the i386 would not have enough registers to hold all the pointers and so some pointers would be kept in memory and would have to be reloaded to a registry each time the array would have to be accessed. However using the indexed addressing modes of the i386, a single register would be enough to address the elements in the different arrays, thus leaving enough other registers for the actual calculations that might be done in the loop.
Marcel
That's simply because your first test is wrong and the inner compare is useless because at that pount a is equal to b. In any case, even if your code were correct, it would be a good example of futile source code optimization as the exact order in which the comparisions would be done would depend on the type of compiler and the exact compiler version. However for compound comparisions like that, a lot of compilers (and this includes GCC) have a tool to optimize this and this is profile feedback optimization. You first compile the code with -fprofile-generate (for GCC). Then you run the program a couple of time with more or less typical data, and then you recompile the program with the option -fprofile-use. During this second compilation, the compiler will take advantage of the knowledge of which test result is the most likely for each test, and it will rearange the code to reduce the number of jumps or rearange tests so that the most conclusive tests are done first.
As for the person who claims he finds no useful answers here, he just has to open his eyes. Especially among the first answers there were a number of pretty good suggestions. However let me iterate some of the ideas in my own words:
* whether it is about using !x or x==NULL or what type of loop to use or how to nest tests, that's just a matter of coding style. Changing between coding styles is just a matter of trivial code transformation and any optimizing compiler can do trasnformations like that. As such, such coding style decisions should not have a significant impact on code performance
* based on the previous point, you should always write your code for human readability. If you obfuscate your code just for performance reasons but you neglect readability, you are creating yourself a maintenance nightmare and you will be the big looser in the end
* before even thinking about optimizing your code, first optimize your algorithms. For instance, if your program does some kind of searching in a huge list, instead of using a linear search, use a binary search, or better even a hash table to potentially get much greater speed gains than by just rearanging your code
* investigate the options the compiler gives you to optimize your code withough modifying your source code. There is generally mucgh more than just the -Ox options. For instance, selecting the appropriate target processor is important. For floating point code, if you don't need strict IEEE conformance, optionms like -ffast-math can give you huge performance gain. If your code oonly runs on SSE enabled processors, you can play around with the SSE floating point options...
* if you really need to microoptimize your code, always use a profiler. First try to find your hotspots. There is no need to optimitze code that is rarely executed. Then check if your changes do really make a performance difference. Don't judge the code just on the source code. With modern processors, the shortest code or the most simply looking isn't always the automatically the best.
The idea is actually already used in the ndiswrapper project. This is a project that allows Windows network drivers to operate under Linux. The main purpose of this project is to support writeless adapters for which there are no Linux drivers.
Marcel
I think the "Fractal Art Manifesto" http://www.fractalus.com/info/manifesto.htm is a good reference and could easily be extended to other instances of computer generated art.
I think the G95 author was clever enough to due his source code ahcnegs such that there is no GPL violation. The G95 source code is human readable without problems. What the author has done is changes that make it near impossible to track changes to the source code:
- there is no changelog - whitespace is randomly added to the code - variable names are randomly changed
The last 2 kind of operations make it impossible to do diffs between different versions as the actual changes get burried in the noise created by the whitespace and variable name changes.
Sadly, the historic threads are becoming more and more cluttered with messages posted through the new Google Groups 2 interface. In their infinite wisdom, Google decided to drop the 1 month limit of replying and you can for example see the effect of this in the Linux annoucement thread.
I only read the text you posted in the old article from 2003. The current article shows on page 6 below the picture:
From the picture we see the flow of warm air pulled forward from beyond the VGA card. As it moves towards the front of the case the air flows over the Southbridge and Northbridge passively cooling each chip. We then see from the shades of red the air warms up as it flows through the CPU heatsink then begins to cool as it moves out the front of the case.
Am I the only one who thinks it's a bad idea to blow warm air into the user's face? For a tower model, this would of course not be an issue, but for a desktop model like the one presented in the article. the airflow out of the case might be such that it goes straight into the user's face.
Sorry, but you are completely wrong here. A lot of 32 bit processors already have a 64 bit data bus right now. This is for example the case for the Intel 32 bit processors. So loading an entity bigger than 32 bit is not an issue. The bus width between the processor core and the L1 cache is even wider allowing even bigger chunks to be loaded in one cycle. As for the floating point unit, it is also designed to do the operations in double precision (64bit) or even more. Once again, full 64 bit processors have no advantage here. So for floating point numbers, having a full 64 bit processor compared to current 32 bit processors does not give you any speed advantage. The only advantage that remaines is the bigger address range.
It's only a monopoly because of the excellent value of their product, the ARM design. If they wouldn't provide good value, you could be sure that big chip manufacturers like Intel, Motorolla or TI would invest more R&D money in designing their own competing products rather than licensing the ARM design. So that fact the most potential competitors license the ARM design rather than try to compete shows the quality of ARM. This is not a market like the PC market where Intel compatibility is a requirement. Most people that use embedded ARM processors don't care about code compatibilty. They only thing they want is a controller that does its job.
How typically slashdot. Few people bother to get the details, some people make comments showing their lack of insight in the issue and they get modded as "insightful".
Yes, the ruling of the court is technically stupid. However the depndency on the IP addresses of the plaintif is very clear. The plaintif is a hosting company with thousands of customers who is trying to migrate his infrastructure to a new location and to new addresses. While changing a DNS for a normal company is easy, changing it for thousands of web hosts can be quite disruptive, especially as the ISP was not willing to help in an oderly transfer. That's what all was about.
So someone complaing the plaintif to be stupid because of his depndency on IP addresses does clearly not have any insight in the issue.
Declaring a variable in a for loop is allowed in the 99 standard but not in the 89 standard. By default GCC works in C89 mode. To compile your code, you need to use the option -std=c99
We have here a fine example of a gap between theory and practice. The GCC project has a development plan according to which, a new version would be released about every 6 months. However so far, they project has never managed to follow the schedule and new releases slipped by many months. So while it's true that the new version is scheduled to be released at the end of this year, it is well possible that it doesn't make it.
The egcs project who did just that was very successful.
Yes, but it was the major developers that did the fork, not just someone who came along. Also, the fork was not to bypass political rules, but rather to make major changes to the compiler that people thought were to invasive for the production version of GCC.
Of course, the LLVM project mentioned here is more in the direction you suggest. The initial compiler is GCC based, but the way LLVM works would not be permitted in GCC according to the current policies.
You should try with GCC 3.4. There has been some serious tuning of libstdc++ especially in the iostream and in the string areas and on some cases, GCC 3.4 may be quite a bit faster than GCC 3.0 through 3.3 when using the iostream library.
Slashdot Mirror
If you want to achive optimal results, use the correct compiler options. There is not really an i686 processor, but as the expression i686 is so commonly used, GCC has it as an alias for Pentiumpro. Now the problem is that the Intel processors based on the Pentiumpro core (this includes the Pentium2 and Pentium3 processors) need a rather strict scheduling for optimal performance whereas the Athlon processors are more relaxed in their scheduling requirements. This means that the i386 option may produce tighter code that while slower on a Pentium Pro/2/3 may actually be faster on an Athlon.
a nd-x86_002d64-Options.html#i386-and-x86_002d64-Opt ions you will see that GCC actually knows about the different type of AMD processors. So if you for instance have an AthlonXP and you want to try what the best code is that GCC can produce for your processor, try the option -march=athlon-xp
If you really want to see how much the compiler can make of your processor, tell it what processor you are using and don't lie to the compiler. For instance if you take a look at the compiler options for the x86 target http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/i386-
This is of course no guarantee that your program will run faster. I agree with your overall answer "it depends". Also, I must admit that the Athlon options for 32 bit code may not be so well tuned as the Intel options. This may partly be due to the fact that the Athlon processor is more "flexible" in their code execution and there are less occasions to improve performance by better scheduling.
In conclusion, I think people are too much fixed on the "mythical" i686 option whereas very few people still use processors for which the i686 is the best one. GCC knows a lot of processors and if you want to compile code just for your own machine, tell GCC what processor you *really* have. Also remember that there are 2 options to select the processor: the -mtune and the -march option. -march gives the minimum processor on which the code is to run and influences what kind of instructions can be used at all. -mtune specifies on which processor the code is to be run fastest and incluences instruction scheduling as well as selecting the best instruction in case there would be multiple prossibilities.
Marcel
I have not done any tests myself nor do I have any numbers to compare. However my guess is that for GCC 4.0, vectorization will still be quite behind the Intel compiler. You should see vectorization support in GCC 4.0 as the first skelleton, but a lot of the vectorization stuff didn't make it for GCC 4.0 and is now scheduled for GCC 4.1. For more details see the following web page: http://gcc.gnu.org/wiki/GCC%204.1%20Projects
Marcel
According to the following link http://www.mingw.org/MinGWiki/index.php/TheNextRel ease it might still take some time before there will be an official new MinGW version. However unofficial versions tend to popup quite quickly. For instance the following web page http://www.thisiscool.com/gcc_mingw.htm regularly provides MinGW binaries for GCC snapshots.
As for the speed of GCC, the compilation speed is often a bit disappointing compared to commertial compilers. Dead code elimination is an optimization which GCC already does for a very long time.
Marcel
The idea that the first CPU runs the main application while the second one does stuff like antivrus, firewall and antispam is naive and doesn't refelect the way these programs really work.
Except for complete scans in the case of antivirus or blocking incoming connections for a firewall, most of the checking done by this kind of programs is done in line. E.g. Some application does some action like read a file, open a TCP connection, transfer some stuff from a web site. This action then passes the security program which validates it and only then the underlying OS actually executes the action. All this time, the application sits there waiting for the result. Whether the scanning of the action is done on the same processor as the application, or on a different processor doesn't make a difference here. The time it takes to do the scanning remains the same, and the application has to wait that time.
The onl way to gain from multiple processors in this case is if the application is multithreaded. E.g. if the applciation itself has different things it can do while waiting for the scanning to occur. However in this case, the taking advantage of multiple CPUs comes from the application itself. It's the appplciation that takes advantage of the fact that there are multiple CPUs, and this advantage is independent on whether there is security software ot not.
So all in all, the idea of the second CPU doing the security scanning in itself is naive. You only gain in speed if you have applications that are able to make use of multiple CPUs themselves, or if you are runnin dufferent (CPU hungry) programs at the same time. In that case, the second CPU does merely compensate for the loss of performance due to the scanning, but there is no real separation of tasks between the main application and the security scanning.
Marcel
I think it would have been highly naive for someone to develop fotran programs specifically for those early, unstable and incomplete versions of G95 and Gfortran.
I think both G95 and Gfortran projects are doing exactly what you are asking for. The wait with the official release until they are good enough from the completeness and stability point of view.
Your analogy with MS and Java is completely wrong as MS actually *shipped* their Java version with IE. This is *not* the case with G95 and Gfortran.
Marcel
Nothing stops people from doing this, and actually it has already be done. For instance, Sun has produced a C backend for GCC so that you can compile any language or dialect support by GCC to a minimum C program which is then fed to Sun's own C compiler and is supposed to produce better code than GCC itself.
However this kind of code takes a lot of work to keep it up to date. For each new version of GCC, a new patch needs to be created. Generally, these projects are therefore "one shot" projects where the code is written once for one version of GCC, and then it remains at that version forever (or at least for a very long time).
With an official internal API or a stable and documented IR, people could write code that would be comptible with multiple versions of GCC without have to make significant changes for each new version of GCC. As such, the overall burden for keeping up non GPL programs that interface with GCC would be much lower.
Marcel
The alias issue results from casting pointers from one type to another.
The background is the following:
pointers make it very difficult for a compiler to optimize redundant memory loads or stores. In fact, when a program access data through a pointer, the compiler may not know what other variable gets modified by the pointer access. So all variables for which the compiler cannot prove that they are not accessed through the pointer cannot be kept in registers accross pointer operations.
Because this is so penalizing to optimizations, at some point, the C standard has introduced stricter rules as to what variables can be modified by what pointer operations. This essentially boils down to the rule that a pointer access through a certain type (let's say int) is not allowed to access a memory location that is associated with a variable of a different kind (let's say float). So if you take the address of a floating point variable, and store that address in an integer pointer and then access the memory through that integer pointer, the compiler will not notice that in fact the floating point variable gets modified. So the compiler can decide to keep the floating point variable in a register and any access through the integer pointer may not change the floating point variable if you compile with optimization enabled and with strict aliasing.
The strict aliasing rules are implemented in all GCC 2.95 and éater versions, but for GCC 2.95, the default options used changed between the different releases based on long and heated discussions whether this kind of optimization should be enabled or disabled by default. So there was no major code change between GCC 2.95.1 and 2.95.3, but rather just the default optimization options changed.
Marcel
Still, the rant is wrong in the sense that it blames an early development version to be not yet complete.
The rant would be valid if it said that the *absense* of (a released) G95 was bad for Fortran, but I can't see much truth in a rant which claims that G95 hurt Fortran because it was feature incomplete.
Marcel
This is rather unfortunate as both projects just advance slowly as they suffer a lack of developpers.
Marcel
I'm sorry, but I have to fundementally disagree with the optimiztations you gave at the end of your message. Unfortunately, for generations, C programmers have been tought to use pointers to access arrays, and this simply because for a long time, C compilers were not really optimizing compilers and so the programmers where always thinking in the code that the compiler would generate. However nowadays, this is no longer true, and using pointers to access elements in an arry is actually a very bad idea because it prevents the compiler from doing some kind of optimizations as you "hide" the fact from the compiler that you are just accessing a single array and you make it difficult for the compiler to track alias information and do loop unrolling. I tried your code with GCC 3.4.2 both with integer and floating point data types, and in both cases, the compiler did not generate code to make complicated address calculations, but instead used the indexed addressing modes of the i386 instruction set to directly address the array elements. In this particular case, this results in code more or less equivalent to the pointer code. However the situation would become different with a loop that would have to access 3 or 4 arrays at the same time. If you used different pointers for each array, a registry starved processor like the i386 would not have enough registers to hold all the pointers and so some pointers would be kept in memory and would have to be reloaded to a registry each time the array would have to be accessed. However using the indexed addressing modes of the i386, a single register would be enough to address the elements in the different arrays, thus leaving enough other registers for the actual calculations that might be done in the loop. Marcel
That's simply because your first test is wrong and the inner compare is useless because at that pount a is equal to b.
...
In any case, even if your code were correct, it would be a good example of futile source code optimization as the exact order in which the comparisions would be done would depend on the type of compiler and the exact compiler version. However for compound comparisions like that, a lot of compilers (and this includes GCC) have a tool to optimize this and this is profile feedback optimization. You first compile the code with -fprofile-generate (for GCC). Then you run the program a couple of time with more or less typical data, and then you recompile the program with the option -fprofile-use. During this second compilation, the compiler will take advantage of the knowledge of which test result is the most likely for each test, and it will rearange the code to reduce the number of jumps or rearange tests so that the most conclusive tests are done first.
As for the person who claims he finds no useful answers here, he just has to open his eyes. Especially among the first answers there were a number of pretty good suggestions. However let me iterate some of the ideas in my own words:
* whether it is about using !x or x==NULL or what type of loop to use or how to nest tests, that's just a matter of coding style. Changing between coding styles is just a matter of trivial code transformation and any optimizing compiler can do trasnformations like that. As such, such coding style decisions should not have a significant impact on code performance
* based on the previous point, you should always write your code for human readability. If you obfuscate your code just for performance reasons but you neglect readability, you are creating yourself a maintenance nightmare and you will be the big looser in the end
* before even thinking about optimizing your code, first optimize your algorithms. For instance, if your program does some kind of searching in a huge list, instead of using a linear search, use a binary search, or better even a hash table to potentially get much greater speed gains than by just rearanging your code
* investigate the options the compiler gives you to optimize your code withough modifying your source code. There is generally mucgh more than just the -Ox options. For instance, selecting the appropriate target processor is important. For floating point code, if you don't need strict IEEE conformance, optionms like -ffast-math can give you huge performance gain. If your code oonly runs on SSE enabled processors, you can play around with the SSE floating point options
* if you really need to microoptimize your code, always use a profiler. First try to find your hotspots. There is no need to optimitze code that is rarely executed. Then check if your changes do really make a performance difference. Don't judge the code just on the source code. With modern processors, the shortest code or the most simply looking isn't always the automatically the best.
Marcel
The idea is actually already used in the ndiswrapper project. This is a project that allows Windows network drivers to operate under Linux. The main purpose of this project is to support writeless adapters for which there are no Linux drivers.
Marcel
I think the "Fractal Art Manifesto" http://www.fractalus.com/info/manifesto.htm is a good reference and could easily be extended to other instances of computer generated art.
Marcel
I think the G95 author was clever enough to due his source code ahcnegs such that there is no GPL violation. The G95 source code is human readable without problems.
What the author has done is changes that make it near impossible to track changes to the source code:
- there is no changelog
- whitespace is randomly added to the code
- variable names are randomly changed
The last 2 kind of operations make it impossible to do diffs between different versions as the actual changes get burried in the noise created by the whitespace and variable name changes.
Marcel
Sadly, the historic threads are becoming more and more cluttered with messages posted through the new Google Groups 2 interface. In their infinite wisdom, Google decided to drop the 1 month limit of replying and you can for example see the effect of this in the Linux annoucement thread.
Marcel
That's because Google switched back to the old interface.
From the picture we see the flow of warm air pulled forward from beyond the VGA card. As it moves towards the front of the case the air flows over the Southbridge and Northbridge passively cooling each chip. We then see from the shades of red the air warms up as it flows through the CPU heatsink then begins to cool as it moves out the front of the case.
So there seems to be quite a contradiction here.
Am I the only one who thinks it's a bad idea to blow warm air into the user's face?
For a tower model, this would of course not be an issue, but for a desktop model like the one presented in the article. the airflow out of the case might be such that it goes straight into the user's face.
Sorry, but you are completely wrong here.
A lot of 32 bit processors already have a 64 bit data bus right now. This is for example the case for the Intel 32 bit processors. So loading an entity bigger than 32 bit is not an issue. The bus width between the processor core and the L1 cache is even wider allowing even bigger chunks to be loaded in one cycle.
As for the floating point unit, it is also designed to do the operations in double precision (64bit) or even more. Once again, full 64 bit processors have no advantage here.
So for floating point numbers, having a full 64 bit processor compared to current 32 bit processors does not give you any speed advantage. The only advantage that remaines is the bigger address range.
Marcel
It's only a monopoly because of the excellent value of their product, the ARM design. If they wouldn't provide good value, you could be sure that big chip manufacturers like Intel, Motorolla or TI would invest more R&D money in designing their own competing products rather than licensing the ARM design.
So that fact the most potential competitors license the ARM design rather than try to compete shows the quality of ARM. This is not a market like the PC market where Intel compatibility is a requirement. Most people that use embedded ARM processors don't care about code compatibilty. They only thing they want is a controller that does its job.
Marcel
How typically slashdot. Few people bother to get the details, some people make comments showing their lack of insight in the issue and they get modded as "insightful". Yes, the ruling of the court is technically stupid. However the depndency on the IP addresses of the plaintif is very clear. The plaintif is a hosting company with thousands of customers who is trying to migrate his infrastructure to a new location and to new addresses. While changing a DNS for a normal company is easy, changing it for thousands of web hosts can be quite disruptive, especially as the ISP was not willing to help in an oderly transfer. That's what all was about. So someone complaing the plaintif to be stupid because of his depndency on IP addresses does clearly not have any insight in the issue.
for (int i=0;isomenumber;i++)
was illegal?
Declaring a variable in a for loop is allowed in the 99 standard but not in the 89 standard. By default GCC works in C89 mode. To compile your code, you need to use the option -std=c99
We have here a fine example of a gap between theory and practice. The GCC project has a development plan according to which, a new version would be released about every 6 months. However so far, they project has never managed to follow the schedule and new releases slipped by many months. So while it's true that the new version is scheduled to be released at the end of this year, it is well possible that it doesn't make it.
The egcs project who did just that was very successful.
Yes, but it was the major developers that did the fork, not just someone who came along. Also, the fork was not to bypass political rules, but rather to make major changes to the compiler that people thought were to invasive for the production version of GCC.
Of course, the LLVM project mentioned here is more in the direction you suggest. The initial compiler is GCC based, but the way LLVM works would not be permitted in GCC according to the current policies.
You should try with GCC 3.4. There has been some serious tuning of libstdc++ especially in the iostream and in the string areas and on some cases, GCC 3.4 may be quite a bit faster than GCC 3.0 through 3.3 when using the iostream library.