It DOES seem to be marginally slower than Linux, but time will tell.
I don't think that this is much of a question. gcc is great, but until the MinGW people approve any gcc-4, we'll have to stick with their gcc-3.4, which gives slightly slower code than any gcc we use on Linux. At least we can now make use of the assembly code we wrote for gcc and throw out the MSC-specific stuff...
It DOES seem to be marginally slower than Linux, but time will tell.
I don't think that this is much of a question. gcc is great, but until the MinGW people approve any gcc-4, we'll have to stick with their gcc-3.4, which gives slightly slower code than any gcc we use on Linux. At least we can now make use of the assembly code we wrote for gcc and throw out the MSC-specific stuff...
BM
So this app has both SSE2 and whatever other improvements were already in the Linux app, or are there additional improvements that can now be ported to the Windows app (other than gcc-4)?
So this app has both SSE2 and whatever other improvements were already in the Linux app,
exactly,
Quote:
or are there additional improvements that can now be ported to the Windows app (other than gcc-4)?
No, there are no more things left in the source code I'm aware of that are beneficial for the Intel Linux build but left out of the Windows build.
Even within the gcc-4 family of compilers, there are quite significant performance differences, e.g. gcc 4.3 introduced Core2 as an optimization target and will generate faster code for that platform. However if you want to build a binary that works on all kinds of Linux distributions, even those (like Debian 4 "Etch") that come with really ancient runtime libraries, it's safer to use older gcc versions.
Native 64 bit builds might be something that would benefit all platforms, but so far I wasn't able to do anything really impressive in that direction.
or are there additional improvements that can now be ported to the
Even within the gcc-4 family of compilers, there are quite significant performance differences, e.g. gcc 4.3 introduced Core2 as an optimization target and will generate faster code for that platform. However if you want to build a binary that works on all kinds of Linux distributions, even those (like Debian 4 "Etch") that come with really ancient runtime libraries, it's safer to use older gcc versions.
So, would it be worthwhile to do a power-users app with gcc 4.3 for those of us with Core 2 machines and new-enough runtime libraries?
So, would it be worthwhile to do a power-users app with gcc 4.3 for those of us with Core 2 machines and new-enough runtime libraries?
Obviously not my decision, but in the past, the effort to create and test power user apps was justified as they were release candidates or intended to lead to release candidates.
I personally would not like to see an abundance of special purpose apps optimized for all possible CPU types (think about a three dimensional matrix : (AMD K8, AMD K10, Intel P4, Intel Core2, ...) x (32 bit, 64 bit) x (Win, Linux distro 1, Linux distro 2, ...), just for the sake of (perhaps) a 10% performance increase, because this will create a quality assurance nightmare.
I know that other projects seem to encourage (at least not discourage) this, but my personal experience and preference is that there should be only one, central, maintainer for the source code and release management who will not want to be overwhelmed with building code for excessively many targets. (If you do it for Core2, why not for Phenoms as well (they could use it even more), and what about the Nehalems, .....)
So, would it be worthwhile to do a power-users app with gcc 4.3 for those of us with Core 2 machines and new-enough runtime libraries?
Obviously not my decision, but in the past, the effort to create and test power user apps was justified as they were release candidates or intended to lead to release candidates.
I personally would not like to see an abundance of special purpose apps optimized for all possible CPU types (think about a three dimensional matrix : (AMD K8, AMD K10, Intel P4, Intel Core2, ...) x (32 bit, 64 bit) x (Win, Linux distro 1, Linux distro 2, ...), just for the sake of (perhaps) a 10% performance increase, because this will create a quality assurance nightmare.
Agreed. I wouldn't want that either. The problem is bad enough as it is. What "problem" you say? Yes, back to that good ole chesnut - "Cross-Procject Parity". I cannot get people to understand that there isn't any such thing as "parity" across projects if there are wide disparities within a single project. The project having the disparities will always be paying one group "too much" and the other "too little", even if project-wide they appear to be "just right".
For approximately the past 2 years, the Linux app has held a firm 20-30% advantage. Now, if we're down to 10%, it's considerably better. I'd still prefer to be within 5%, but 10 is better than 20-30...
Anyone know how to run that test unit on Windows so that we can see the new runtime?
Anyone know how to run that test unit on Windows so that we can see the new runtime?
The Windows scripts discussed in this and the following messages did work in S5R3 and should need only minor (if any) changes for S5R4. I guess even the Linux script provided with the "reference Unit" by Bernd in that same thread would work in a cygwin shell under Windows.
RE: It DOES seem to be
)
I don't think that this is much of a question. gcc is great, but until the MinGW people approve any gcc-4, we'll have to stick with their gcc-3.4, which gives slightly slower code than any gcc we use on Linux. At least we can now make use of the assembly code we wrote for gcc and throw out the MSC-specific stuff...
BM
BM
RE: RE: It DOES seem to
)
So this app has both SSE2 and whatever other improvements were already in the Linux app, or are there additional improvements that can now be ported to the Windows app (other than gcc-4)?
RE: So this app has both
)
exactly,
No, there are no more things left in the source code I'm aware of that are beneficial for the Intel Linux build but left out of the Windows build.
Even within the gcc-4 family of compilers, there are quite significant performance differences, e.g. gcc 4.3 introduced Core2 as an optimization target and will generate faster code for that platform. However if you want to build a binary that works on all kinds of Linux distributions, even those (like Debian 4 "Etch") that come with really ancient runtime libraries, it's safer to use older gcc versions.
Native 64 bit builds might be something that would benefit all platforms, but so far I wasn't able to do anything really impressive in that direction.
CU
Bikeman
RE: or are there additional
)
So, would it be worthwhile to do a power-users app with gcc 4.3 for those of us with Core 2 machines and new-enough runtime libraries?
RE: So, would it be
)
Obviously not my decision, but in the past, the effort to create and test power user apps was justified as they were release candidates or intended to lead to release candidates.
I personally would not like to see an abundance of special purpose apps optimized for all possible CPU types (think about a three dimensional matrix : (AMD K8, AMD K10, Intel P4, Intel Core2, ...) x (32 bit, 64 bit) x (Win, Linux distro 1, Linux distro 2, ...), just for the sake of (perhaps) a 10% performance increase, because this will create a quality assurance nightmare.
I know that other projects seem to encourage (at least not discourage) this, but my personal experience and preference is that there should be only one, central, maintainer for the source code and release management who will not want to be overwhelmed with building code for excessively many targets. (If you do it for Core2, why not for Phenoms as well (they could use it even more), and what about the Nehalems, .....)
CU
Bikeman
RE: RE: So, would it be
)
Agreed. I wouldn't want that either. The problem is bad enough as it is. What "problem" you say? Yes, back to that good ole chesnut - "Cross-Procject Parity". I cannot get people to understand that there isn't any such thing as "parity" across projects if there are wide disparities within a single project. The project having the disparities will always be paying one group "too much" and the other "too little", even if project-wide they appear to be "just right".
For approximately the past 2 years, the Linux app has held a firm 20-30% advantage. Now, if we're down to 10%, it's considerably better. I'd still prefer to be within 5%, but 10 is better than 20-30...
Anyone know how to run that test unit on Windows so that we can see the new runtime?
RE: Anyone know how to run
)
The Windows scripts discussed in this and the following messages did work in S5R3 and should need only minor (if any) changes for S5R4. I guess even the Linux script provided with the "reference Unit" by Bernd in that same thread would work in a cygwin shell under Windows.
CU
Bikeman
My box is a Q6600 quad. Are
)
My box is a Q6600 quad. Are all Q6600 boxes ready for this app?
(Click for detailed stats)
RE: My box is a Q6600 quad.
)
Absolutely yes.
Happy crunching
Bikeman
I think everything from
)
I think everything from Pentium IV is able to run this
Though for some reason on my dual core the difference is way more than on my Pentium IV, anyone knows why that is?