• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

SSE4.1 F@H optimizations?

S

Shortass

Senior member
If you can't tell from the title, I'm planning on upgrading my computer shortly and I'm trying to justify spending the additional cash for the 45nm process, largely for the power consumption reduction. However, at this point, if you can even find it in stock, the 9450 is rather overpriced for the marginal performance gains. Since I will be folding 24/7, over time the price difference will become less brutal thanks to saved electricity, but it's still hard to swallow considering the less than earthshattering overclock potential.

Of course, if F@H were to be optimized for SSE4.1 and suddenly reap massive performance gains over the 6600... is there any chance of this happening? A quick search brought up nothing on the topic but if anyone knows something it would be sweet.
 
I read on the F@H forums a while back that there were no plans currently to use SSE4 optimizations. A Q9450 overclocked to ~3.6GHz will give you ~4000ppd if you ran F@H 24/7.
 
The same stuff occurred to me too.

I figured to just wait for a bit more to see how things shake out and/or see if price might come down a little.

F@H has eventually made use of previous SSE so I figure it will eventually be used?
 
The 9450 has 4 extra megs of cache. Now if we could find some sort of F@H performance comparison involving equally clocked chips with varying amounts of cache, even that might be enough to boost the 9450s value a bit higher.
 
foxery has a Q9300 clocked at 454x7.5, and markfw900 has a q9450 or x3350 at 3.576 iirc. maybe you could convince mark to drop down for a week or two for a nearly exact comparison.

Q9450 has 12mb total cache, so 3mb/core. Q9300 has 6mb total cache.
 
I thought F@H used only up to SSE2. I have yet to run into a project that uses SSE3.

Offtopic: I added the -advmethods into the registry for my F@H. I noticed that lately, I've been getting small point WUs and for the last 3 projects, the credit I got was only 178 points. Is this fine or is there something wrong? I know I won't be getting big points since I'm folding for 2 different teams on both cores. I don't care that much about points though since as long as I'm helping to make a change, I'm happy.
 
Originally posted by: geokilla
I thought F@H used only up to SSE2. I have yet to run into a project that uses SSE3.

Offtopic: I added the -advmethods into the registry for my F@H. I noticed that lately, I've been getting small point WUs and for the last 3 projects, the credit I got was only 178 points. Is this fine or is there something wrong? I know I won't be getting big points since I'm folding for 2 different teams on both cores. I don't care that much about points though since as long as I'm helping to make a change, I'm happy.
Click to expand...

I had thought that DGromac cores used SSE3 but it must only use up to SSE2 (they sure give a good bonus though!)

The following posted here.

New rules for advanced methods (-adv flag)
In the near future, we will be releasing some new projects which require a very rapid turn-around time. These are peptide fragment simulations which we are interested in simulating for a time-sensitive collaborative project involving protein structure prediction.

These WUs will go directly to the classic clients running with -advmethods. Non-classic clients (eg SMP, GPU, PS3) will not be affected, as all of these calculations will be run via the AMBER core and only the classic client supports the AMBER core.

To reward users for participating in this exciting project, we will be giving a x1.5 bonus in the points awarded. What's the catch? These projects will be less rigorously beta tested, so there will be an increased risk of Early_Unit_End errors. We believe the risk of this is minor (there will likely be a higher rate of early unit ends, especially very early in the WU, but we do not expect client machines to become significantly less stable). However, if you do not wish to participate in this project, just remove the -advmethods setting from your client.

This will not last forever and will likely go back to normal -advmethods usage in a few months. With that said, we do plan other uses for -adv in the future.
Click to expand...
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top