Inefficient science app for MacOS X

Martin P.
Martin P.
Joined: 17 Feb 05
Posts: 162
Credit: 40,156,217
RAC: 0
Topic 191069

The science application for E@H is, compared to the SETI@Home Alpha 5.2, extremely inefficient. When you compare the Credits/hour data between those two applications it turns out, that the SETI app produces more then twice as much data then the E@H science app: Pending Credits for BOINC Projects

Any optimization on the horizon?

P.S. Officially the E@H science app is already Altivec-optimized. However, it's still slow.

Winterknight
Winterknight
Joined: 4 Jun 05
Posts: 482
Credit: 195,065,359
RAC: 80,552

Inefficient science app for MacOS X

Now the shoe is on the other foot, you start complaining. ;-)

Andy

Elphidieus
Elphidieus
Joined: 20 Feb 05
Posts: 234
Credit: 15,948,821
RAC: 10,106

We've started complaining

We've started complaining long ago but nobody cares to listen....

And with the advent of the Int(el)-cheapo Macs, I seriously doubt there will ever be another revision of the Altivec-optimised science apps.....

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,031
Credit: 218,438,854
RAC: 45,463

I'm curious how you judge the

I'm curious how you judge the efficiency of an App - the data used and produced on Einstein@Home has nothing to do with that used on SETI, and nor has any of the algorithms used there, or the length of the Workunits. SETI is mainly doing FFT, which is an algorithm that is well understood and for which highly optimized libraries are available for each CPU. Einstein@Home is not like that.

We've been working with experienced programmers from Apple to make the AltiVec version as fast as we can, and of all official Apps it makes the most of every clock cycle of a CPU.

Unlike on the other platforms I couldn't build anything that ran faster than the current AltiVec version on a PPC Mac (G4 or G5) - until less than a week ago. The vector code I wrote and am currently testing in the Linux App has been reported to be around 20% faster, that's all. And requiring a newer compiler I still have problems building an App with that code that still runs on 10.3 (Panther).

No, guys, you have not been forgotten, not from a Macaddict like me. But I'm on the road right now and it will take some time until I get back to my development machines.

BM

BM

Martin P.
Martin P.
Joined: 17 Feb 05
Posts: 162
Credit: 40,156,217
RAC: 0

RE: I'm curious how you

Message 27987 in response to message 27986

Quote:

I'm curious how you judge the efficiency of an App - the data used and produced on Einstein@Home has nothing to do with that used on SETI, and nor has any of the algorithms used there, or the length of the Workunits. SETI is mainly doing FFT, which is an algorithm that is well understood and for which highly optimized libraries are available for each CPU. Einstein@Home is not like that.

We've been working with experienced programmers from Apple to make the AltiVec version as fast as we can, and of all official Apps it makes the most of every clock cycle of a CPU.

Unlike on the other platforms I couldn't build anything that ran faster than the current AltiVec version on a PPC Mac (G4 or G5) - until less than a week ago. The vector code I wrote and am currently testing in the Linux App has been reported to be around 20% faster, that's all. And requiring a newer compiler I still have problems building an App with that code that still runs on 10.3 (Panther).

No, guys, you have not been forgotten, not from a Macaddict like me. But I'm on the road right now and it will take some time until I get back to my development machines.

BM

Bernd,

thanks for the feedback!

Rand
Rand
Joined: 11 Dec 05
Posts: 10
Credit: 601,115
RAC: 0

RE: RE: I'm curious how

Message 27988 in response to message 27987

Quote:
Quote:

I'm curious how you judge the efficiency of an App - the data used and produced on Einstein@Home has nothing to do with that used on SETI, and nor has any of the algorithms used there, or the length of the Workunits. SETI is mainly doing FFT, which is an algorithm that is well understood and for which highly optimized libraries are available for each CPU. Einstein@Home is not like that.

We've been working with experienced programmers from Apple to make the AltiVec version as fast as we can, and of all official Apps it makes the most of every clock cycle of a CPU.

Unlike on the other platforms I couldn't build anything that ran faster than the current AltiVec version on a PPC Mac (G4 or G5) - until less than a week ago. The vector code I wrote and am currently testing in the Linux App has been reported to be around 20% faster, that's all. And requiring a newer compiler I still have problems building an App with that code that still runs on 10.3 (Panther).

No, guys, you have not been forgotten, not from a Macaddict like me. But I'm on the road right now and it will take some time until I get back to my development machines.

BM

Bernd,

thanks for the feedback!

Yes Thanks Bernd,
Looking forward to getting the next version of the G5 app with the new optimizations built in.

Rand

Martin P.
Martin P.
Joined: 17 Feb 05
Posts: 162
Credit: 40,156,217
RAC: 0

RE: No, guys, you have not

Message 27989 in response to message 27986

Quote:


No, guys, you have not been forgotten, not from a Macaddict like me. But I'm on the road right now and it will take some time until I get back to my development machines.

BM

Hi Bernd,

any news on the new app?

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,031
Credit: 218,438,854
RAC: 45,463

My current vector code has

My current vector code has either a minor bug or a numerical instability, that shows up as occasional invalid results of the 4.55 Linux App. I want to have this fixed before I do anything else with that code, like using it for other platforms.

BM

BM

Honza
Honza
Joined: 10 Nov 04
Posts: 136
Credit: 3,332,354
RAC: 0

RE: a numerical

Message 27991 in response to message 27990

Quote:
a numerical instability

Sorry for my bad English - but what's that? :-)

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,358
Credit: 2,360,528,189
RAC: 3,116,276

RE: RE: a numerical

Message 27992 in response to message 27991

Quote:
Quote:
a numerical instability
Sorry for my bad English - but what's that? :-)

A fancy phrase for a calculation that can loose enough precision to screw up the result.

For example, using 4 decimal digits of precision, and granting that this is a contrived example to make my point
((4.000/(2.000-.00015))-2.000)*2000 =3.022.... according to the windows calculator.
doing it with only 4 digits of precision though you get:
((4.000/(2.000-.0001500))-2.000)*2000 =
((4.000/(1.999))-2.000)*2000 =
(2.001-2.000)*2000 =
(.001)*2000 = = 2.000

This is an error of 33%!

In the real science app the error's probably much smaller but compounds over 1000's of iterations into something eventually becomes large enough to break something.

Elphidieus
Elphidieus
Joined: 20 Feb 05
Posts: 234
Credit: 15,948,821
RAC: 10,106

RE: P.S. Officially the

Quote:

P.S. Officially the E@H science app is already Altivec-optimized. However, it's still slow.

I've tested my G5 1.9 against a P4 2.4A (on Akosf's optimised S41.06 client) on the same WU, my G5 was smoked; my P4 completed the WU in less than half the time it took on the G5.

Comment viewing options

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