I thought this stock "optimized" app. was supposed to be fast. I went from 35min. on the .07 opp. app. to 2hrs 35min. on the stock app.! I thought all you were gonna do was put some tags in the .07 opp. app. that worked and re release it as the "new" stock app.

---

A clear conscience is usually the sign of a bad memory

I thought this stock "optimized" app. was supposed to be fast. I went from 35min. on the .07 opp. app. to 2hrs 35min. on the stock app.! I thought all you were gonna do was put some tags in the .07 opp. app. that worked and re release it as the "new" stock app.

I`m not sure what was optimized, but I am sure, that it wasn`t the runtime !
From 6,5 min. I´m up to 58 min. again with stock app. 0.13.


Regards
Kurt

---

anywhere from 40-60 min is about right on the stock .13 app q6600

anywhere from 40-60 min is about right on the stock .13 app q6600

The times I stated was on a intel '03 server with 3.0 xeon's... quad, kinda.

---

A clear conscience is usually the sign of a bad memory

Stock app q6600 slightly underclocked

39 min average. CLICKY STOCK .13


Last stock app was approx 43m on this box.

The stock application (V0.13 for Windos) is running on 2 quads, a dual Xeon and a dual P3 at the same speeds as the stock 0.7 client.

I am looking forwards to the release of approved, accurate, optimised clients which are similar in crunch times as was found with Milksop and the clients just made redundant.

I thought this stock "optimized" app. was supposed to be fast. I went from 35min. on the .07 opp. app. to 2hrs 35min. on the stock app.! I thought all you were gonna do was put some tags in the .07 opp. app. that worked and re release it as the "new" stock app.

I`m not sure what was optimized, but I am sure, that it wasn`t the runtime !
From 6,5 min. I´m up to 58 min. again with stock app. 0.13.


Regards
Kurt

I think Dave just put "optimized" there to distinguish it from the older version of the milkyway app (which was quite slow in comparison) -- astronomy_X. I've changed the name in the database so hopefully this will update for people. It should be just "MilkyWay@Home" now.

---

[/quote]I think Dave just put "optimized" there to distinguish it from the older version of the milkyway app (which was quite slow in comparison) -- astronomy_X. I've changed the name in the database so hopefully this will update for people. It should be just "MilkyWay@Home" now.[/quote]


.......So thats all You're going to do?

---

A clear conscience is usually the sign of a bad memory

I think Dave just put "optimized" there to distinguish it from the older version of the milkyway app (which was quite slow in comparison) -- astronomy_X. I've changed the name in the database so hopefully this will update for people. It should be just "MilkyWay@Home" now.

.......So thats all You're going to do?[/quote]

Not sure what more you want him to do..

The current .13 code has the optimizations built in - it used to run several hours.. -

The current, non-stock optimized app is SSE type flaged, and can not be used as a project stock app.

The current stock app, is still doing work at a much faster speed than the app we had several weeks ago.

This is no different than SETI, or other projects with optimized apps, there is a basic stock app, and optimized apps that you have to install yourself.

---

.

I think Dave just put "optimized" there to distinguish it from the older version of the milkyway app (which was quite slow in comparison) -- astronomy_X. I've changed the name in the database so hopefully this will update for people. It should be just "MilkyWay@Home" now.

.......So thats all You're going to do?

Not sure what more you want him to do..

The current .13 code has the optimizations built in - it used to run several hours.. -

The current, non-stock optimized app is SSE type flaged, and can not be used as a project stock app.

The current stock app, is still doing work at a much faster speed than the app we had several weeks ago.

This is no different than SETI, or other projects with optimized apps, there is a basic stock app, and optimized apps that you have to install yourself.[/quote]

Unfortunately for the stock app all we can do is code optimization, and architecture independent optimizations -- because the stock app has to work "out of the box" so to speak. Many of the other optimized apps use architecture specific optimizations and thats why they get quite a bit of performance improvement.

If they're using code optimizations, they haven't shared them with me, or else they would be added to the application. In fact, the whole reason we open sourced the application was in hopes that code optimizations would be shared so everyone could benefit.

---

I think Dave just put "optimized" there to distinguish it from the older version of the milkyway app (which was quite slow in comparison) -- astronomy_X. I've changed the name in the database so hopefully this will update for people. It should be just "MilkyWay@Home" now.

.......So thats all You're going to do?

Not sure what more you want him to do..

The current .13 code has the optimizations built in - it used to run several hours.. -

The current, non-stock optimized app is SSE type flaged, and can not be used as a project stock app.

The current stock app, is still doing work at a much faster speed than the app we had several weeks ago.

This is no different than SETI, or other projects with optimized apps, there is a basic stock app, and optimized apps that you have to install yourself.[/quote]

Unfortunately for the stock app all we can do is code optimization, and architecture independent optimizations -- because the stock app has to work "out of the box" so to speak. Many of the other optimized apps use architecture specific optimizations and thats why they get quite a bit of performance improvement.

If they're using code optimizations, they haven't shared them with me, or else they would be added to the application. In fact, the whole reason we open sourced the application was in hopes that code optimizations would be shared so everyone could benefit.

---

More 'specific' versions could be offered for the different systems on this site as 'official optimized apps' that the users would need to install if they want, otherwise the 'stock' would be used. And more optimization could be done for more setups to take advantage of more performance. ie: versions for sse2,sse3 etc.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Just keep one version only and do not accept work from other applications that are not official (released by you).

Just keep one version only and do not accept work from other applications that are not official (released by you).

Well thats all well and good, but if I can do 5x the science for the same wattage then I want to do more for the same cost. If I can get an app that works quicker and provides the same output then I want to do more work for the same electric bill.

Just keep one version only and do not accept work from other applications that are not official (released by you).

Well thats all well and good, but if I can do 5x the science for the same wattage then I want to do more for the same cost. If I can get an app that works quicker and provides the same output then I want to do more work for the same electric bill.

And then comes the famous words of the Einstein devs. Our science team will only accept results from the official app. All other results will be rejected and credit denied. I have yet to see the "electric bill" argument work on any project.

---

me@rescam.org

I known a stock version needs to be the one that runs on any architecture supported by the project but...

A suggestion.
Can you provide real Win x64 application, that has SSE2 enabled?
I mean - right now there is not x64 app (it's a 32-bit fake given to 64-bit hosts) but x64 CPUs are also SSE2 capable.
This way, 64-bit hosts can somehow benefit and provide better performance per watt.

I believe it can be even extened.
It is known what CPU features are available to each host (BOINC client reports what is known to OS) and app can be provided accordingly.
This would mean to have Win stock, Win SSE2, Win SSE3, Win x64 SSE2, Win x64 SSE3 etc and send them to hosts.

Or, you can make a single app that would have all version inside (stock...SSE4.2) and app itself will choose what code version to run.

---

BOINC Project specifications and hardware requirements

I thought this stock "optimized" app. was supposed to be fast. I went from 35min. on the .07 opp. app. to 2hrs 35min. on the stock app.! I thought all you were gonna do was put some tags in the .07 opp. app. that worked and re release it as the "new" stock app.

I`m not sure what was optimized, but I am sure, that it wasn`t the runtime !
From 6,5 min. I´m up to 58 min. again with stock app. 0.13.


Regards
Kurt

I think Dave just put "optimized" there to distinguish it from the older version of the milkyway app (which was quite slow in comparison) -- astronomy_X. I've changed the name in the database so hopefully this will update for people. It should be just "MilkyWay@Home" now.

Understood ! The same mechanism as Seti....We´ll just be patient, and wait for
an optimised app for Windows, which will come along eventually !
Thanks for the explanation, Travis !

Regards
Kurt

---

anywhere from 40-60 min is about right on the stock .13 app q6600

OK, so I´m on the " safe side ", so to speak !
( q6600, no OC )

Thanks !

Regards
Kurt

---

I known a stock version needs to be the one that runs on any architecture supported by the project but...

A suggestion.
Can you provide real Win x64 application, that has SSE2 enabled?
I mean - right now there is not x64 app (it's a 32-bit fake given to 64-bit hosts) but x64 CPUs are also SSE2 capable.
This way, 64-bit hosts can somehow benefit and provide better performance per watt.

I believe it can be even extened.
It is known what CPU features are available to each host (BOINC client reports what is known to OS) and app can be provided accordingly.
This would mean to have Win stock, Win SSE2, Win SSE3, Win x64 SSE2, Win x64 SSE3 etc and send them to hosts.

Or, you can make a single app that would have all version inside (stock...SSE4.2) and app itself will choose what code version to run.

Probably too much work to maintain all the versions and bug check them for each update.

Would be nice as I have C2 processors capable of functions up to SSSE3 that could speed up the process.

But then that would just make me a credit whore wouldn't it?

---

Never surrender and never give up. In the darkest hour there is always hope.

Just keep one version only and do not accept work from other applications that are not official (released by you).

Well thats all well and good, but if I can do 5x the science for the same wattage then I want to do more for the same cost. If I can get an app that works quicker and provides the same output then I want to do more work for the same electric bill.

And then comes the famous words of the Einstein devs. Our science team will only accept results from the official app. All other results will be rejected and credit denied. I have yet to see the "electric bill" argument work on any project.

Yes, but they employed Akos and essentially rolled many / most of his improvements into the stock applications over time. I was going to suggest that Travis and Dave contact Bernd to look into the cpu detection switching apps that they are doing now to see if the same concept could be used here...