Windows S5R4 SSE2 power App 6.05 available

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4267
Credit: 244932518
RAC: 16325

RE: It DOES seem to be

Message 86600 in response to message 86599

Quote:
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

BM

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: RE: It DOES seem to

Message 86601 in response to message 86600

Quote:
Quote:
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)?

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686139002
RAC: 550619

RE: So this app has both

Message 86602 in response to message 86601

Quote:

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.

CU
Bikeman

Donald A. Tevault
Donald A. Tevault
Joined: 17 Feb 06
Posts: 439
Credit: 73516529
RAC: 0

RE: or are there additional

Message 86603 in response to message 86602

Quote:
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?

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686139002
RAC: 550619

RE: So, would it be

Message 86604 in response to message 86603

Quote:

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, .....)

CU
Bikeman

Brian Silvers
Brian Silvers
Joined: 26 Aug 05
Posts: 772
Credit: 282700
RAC: 0

RE: RE: So, would it be

Message 86605 in response to message 86604

Quote:
Quote:

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?

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686139002
RAC: 550619

RE: Anyone know how to run

Message 86606 in response to message 86605

Quote:

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.

CU
Bikeman

Gerry Rough
Gerry Rough
Joined: 1 Mar 05
Posts: 102
Credit: 1847066
RAC: 0

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)

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686139002
RAC: 550619

RE: My box is a Q6600 quad.

Message 86608 in response to message 86607

Quote:
My box is a Q6600 quad. Are all Q6600 boxes ready for this app?


Absolutely yes.
Happy crunching
Bikeman

Novasen169
Novasen169
Joined: 14 May 06
Posts: 43
Credit: 2767204
RAC: 0

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?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.