What are you taking about? GCC has an estimated release date usually it slips by a week or two like right now 3.3.1 was planed for last friday but it slipped because there are some bugs that need to be fixed before the release (but most of these bugs are not regressions from 3.3 or 3.2.3 but from 2.95.3 or 2.91.66). The problem is that most bugs only are fixed in the last month before the release of the minor version.
Because that is the first front-end for Mathematica® and they also in the current versions (at least 3.0 and 4.2) automatically italicize Mathematica®.
Looks like the event model for Win32 was flawed from the beginning and should have changed long ago. Looking at the Mac event model (Carbon Events and even the WaitNextEvent/GetNextEvent), there is no passing of functions to the event handler at all so why did M$ design it that way back in 1993 I do not know.
On the PPC, it is 16 bytes per 4 instructions. But it is not the bloated binaries which creates a need for a larger cache, but just programmers not looking at memory usage. The need for faster computers are because people do not use performance tools like the CHUD tools.
Re:Money crunches create platform dependencies
on
Analysis: x86 Vs PPC
·
· Score: 1
You are using a gcc extension which is going to be removed because it causes more problems than it solves.
That is not true on Mac OS X, QT still uses its own drawing, that is why themes in QT works for Mac OS X, because there are not themes in Mac OS X. In fact I am using a semi-QT based browser which uses native widgets, Safari. I think they (troll**) should look at Apple's bridge between QT and Cocoa.
It is not native, it uses QT which uses custom widgets so it is slow, a native would use Cocoa (or maybe Carbon) libraries and almost no custom widgets.
But that will not help because you do not get anything like the CHUD tools to optimize your programs, it will only optimize using gcc's scheduling which is weak and needs some help for the G5/970/power4 because there are cases where gcc should place noops so there are no reject the dispatch group by the processor (the most common one is the LSU reject which is caused by a load and a store to the same address in the same dispatch group, very bad).
The problem with the XBench and the Altivec test is that it uses some instructions (dst) that are very bad to use on the G5 look at these technotes about tuning your program for the G5:
The Altivec test uses the dst instruction every iteration through a loop so slows down the G5 (it might also slow down the G4 also).
It only truncates when saving to memory, that is why you can get different results when optimizing than not optimizing with gcc (you can force gcc to truncate all the time by using -ffloat-store). With gcc you can force the floating point calculations in the sse registers by -mfpmath=sse.
Re:One example of 64bit gaming benefits
on
P4 3.2GHz Reviews
·
· Score: 1
Yes and that is why one of the spec tests is a chess games, forgot which one though.
If the had read the til from apple, they would not have said it is burned in because it really is a temparory problem that can be fixed according to the atricle.
Slashdot Mirror
Is this only going to be ia32 GNU/linux only, or also sh4, ppc, ppc64, ia64, arm, s390, s390x, m68k, sparc, alpha, etc. GNU/LINUX?
What are you taking about? GCC has an estimated release date usually it slips by a week or two like right now 3.3.1 was planed for last friday but it slipped because there are some bugs that need to be fixed before the release (but most of these bugs are not regressions from 3.3 or 3.2.3 but from 2.95.3 or 2.91.66). The problem is that most bugs only are fixed in the last month before the release of the minor version.
Caldera does not exist any more, SCO removed it.
I forgot to say that this was the first front-end for Mathematica.
Because that is the first front-end for Mathematica® and they also in the current versions (at least 3.0 and 4.2) automatically italicize Mathematica®.
That means, it is just a new Security Framework see the benefit of shared libraries.
Looks like the event model for Win32 was flawed from the beginning and should have changed long ago. Looking at the Mac event model (Carbon Events and even the WaitNextEvent/GetNextEvent), there is no passing of functions to the event handler at all so why did M$ design it that way back in 1993 I do not know.
On the PPC, it is 16 bytes per 4 instructions.
But it is not the bloated binaries which creates a need for a larger cache, but just programmers not looking at memory usage. The need for faster computers are because people do not use performance tools like the CHUD tools.
You are using a gcc extension which is going to be removed because it causes more problems than it solves.
Here is reference to the register saying that http://www.theregus.com/content/4/25711.html
the 970 can have more than 200 instructions in flight at the same time, it can finish up to 5 instructions each clock (4 if there is no branches).
Since C++ is standardized by the ISO and ANSI, I do not think any one owns them (the same thing with POSIX and the UNIX standard, hehe haha).
I thought this came out yesterday when ABC did a news special on NASA and the failure to listen to a guy?
That is not true on Mac OS X, QT still uses its own drawing, that is why themes in QT works for Mac OS X, because there are not themes in Mac OS X. In fact I am using a semi-QT based browser which uses native widgets, Safari.
I think they (troll**) should look at Apple's bridge between QT and Cocoa.
It is not native, it uses QT which uses custom widgets so it is slow, a native would use Cocoa (or maybe Carbon) libraries and almost no custom widgets.
The "emulators" you can get for PPC linux are not real "emulators" but more like what VMWare is.
But that will not help because you do not get anything like the CHUD tools to optimize your programs, it will only optimize using gcc's scheduling which is weak and needs some help for the G5/970/power4 because there are cases where gcc should place noops so there are no reject the dispatch group by the processor (the most common one is the LSU reject which is caused by a load and a store to the same address in the same dispatch group, very bad).
NAG is FORTRAN to C compiler so yes Apple used a FORTRAN to C compiler.
The last one should be http://developer.apple.com/technotes/tn/tn2086.htm l
stupid HTML based web sites, here are the links: http://developer.apple.com/technotes/tn/tn2087.htm l m l.
http://developer.apple.com/technotes/tn/tn2088.ht
The problem with the XBench and the Altivec test is that it uses some instructions (dst) that are very bad to use on the G5 look at these technotes about tuning your program for the G5:
The Altivec test uses the dst instruction every iteration through a loop so slows down the G5 (it might also slow down the G4 also).
It only truncates when saving to memory, that is why you can get different results when optimizing than not optimizing with gcc (you can force gcc to truncate all the time by using -ffloat-store).
With gcc you can force the floating point calculations in the sse registers by -mfpmath=sse.
Yes and that is why one of the spec tests is a chess games, forgot which one though.
If the had read the til from apple, they would not have said it is burned in because it really is a temparory problem that can be fixed according to the atricle.
I thought perl was under both GPL and its own?