Quad-Core AMD Opteron(tm) Processor 2347 [AMD64 Family 16 Model 2 Stepping 10]

Not real snappy, eh?

Well, it is still only running at 1895MHz! So it's respectable clock for clock.

Quad-Core AMD Opteron(tm) Processor 2347 [AMD64 Family 16 Model 2 Stepping 10]

Not real snappy, eh?

Well, it is still only running at 1895MHz! So it's respectable clock for clock.

OK....I'll wait to see what happens when they ramp up to the likes of my Q6600 at 3.924ghz. LOL.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Well, we'll see with a barcelona at 2.8Ghz

---

http://www.presence-pc.com/actualite/phenom-28-25496/

---

http://www.presence-pc.com/actualite/phenom-28-25496/

Zut alors... c'est une page pour le François! :-)

http://www.presence-pc.com/actualite/phenom-28-25496/

Zut alors... c'est une page pour le François! :-)

oulalala ... I am scared!
hehehehe!

[EDIT] Since we are in the real information space: http://www.vr-zone.com/articles/Quad-Core_Phenom_Models_%26_Clocks_Revealed/5331.html#Scene_1

who?
oulalala ...

For whatever it's worth/not worth, I've had posts that have been critical of Who?.

Having said that, I'm on board with the new products of both AMD & Intel; we can all spin things but the bottom line, in my humble opinion is that AMD (based ENTIRELY on stock price) is not doing well and Intel is, just check the market.

Nuff said.

Market Rules? Yes or No???

What I meant about the advise: I gave the name of Mats (an enought info to contact him), he can fix the issue on K10, right now, something is not right, the code is doing something under representing K10, probably hiting a Glass Jaw of the architecture.
Mats can find this in 3 minutes.

who?

Finally, somebody toke my advise and is asking AMD for support!
http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=87923&enterthread=y

nice!

who?

Finally, somebody toke my advise and is asking AMD for support!
http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=87923&enterthread=y

nice!

who?

If you don't know who mmciastro is, It's my only previous username. Follow this thread at simons. That is, if he ever gets back with me.

Finally, somebody toke my advise and is asking AMD for support!
http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=87923&enterthread=y

nice!

who?

If you don't know who mmciastro is, It's my only previous username. Follow this thread at simons. That is, if he ever gets back with me.

Awesome, we will finally know if K10 can crunch.



who?

Finally, somebody toke my advise and is asking AMD for support!
http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=87923&enterthread=y

nice!

who?

Guys, no need to send me emails for appologizing for Astro 'posting', he did what he thinks is right. He is not happy because I did make fun of K10, and he has the right of his feeling.
The good part of it, I made it to amd.com :)

let's keep it fun and respect each other.

who?

I'm surprised he feels so strongly about it, unless he mortgaged his house
for AMD shares...
If you're backing the perceived 'losing' side then I wouldn't draw attention
to it and 'convert' more people to the perceived 'winning' side by convincing
them there is a case to answer for.

It's already a big issue for AMD, and they're trying to make the best of it,
without spreading the news further that optimised C2s are more than twice as
quick as Barcelonas for FPU... The international press could easily pick up
on this and make it a worldwide issue!

AMD can still do well in data centres where throughput is much more important.

What is important is that SETI can only benefit from the competition and
optimisation.

...It's already a big issue for AMD, and they're trying to make the best of it,
without spreading the news further that optimised C2s are more than twice as
quick as Barcelonas for FPU... The international press could easily pick up
on this and make it a worldwide issue!

AMD can still do well in data centres where throughput is much more important.

What is important is that SETI can only benefit from the competition and
optimisation.

If you read this

http://www.xbitlabs.com/articles/cpu/display/amd-k10_7.html

"As we see, the FPU of K10 processor became much more flexible. It acquired some unique features that Intel processors don’t have yet, namely, efficient unaligned loading, including Load-Execute instructions, and two 128-bit reads per clock cycle. Unlike Core 2, floating-point and integer schedulers use separate queues. Separate queues eliminate operations conflicts caused by use of the same execution ports. However, K10 still shares the FSTORE unit for SSE save operations with some data transformation instructions, which may sometimes affect their processing speed."

Architecturally there should be no reason why the k10 shouldn't be as fast or faster the C2. I wouldn't expect a "worldwide issue" to result from the comparison of optimized C2 code to unoptimized k10 code.

Also, as a general statement, the k10 seems to be well received in datacenters:

http://www.crn.com/white-box/202402138

For example

"There are no hardware conflicts and the power draw is as promised. They delivered on their technicals. On these high-performance compute and memory-intensive applications, they're kicking Intel's butt," said Brian Corn, VP of marketing and business development at Waltham, Mass.-based Source Code.

The biggest bummer was that they were six months late with the part. But I think the chip itself is performing ok so far.

Well, I'd really like to see what optimised K10 code can do, and how memory
contention scales with the number of cores... However I wouldn't expect
Francois to tackle this one - he's already got enough to do!

Little question, if they have instructions that reduce the discrepency in
execution time between unaligned and aligned code, won't that make programmers
lazier? :-)

I'm all for someone tackling this, and SETI can be a very good high profile
proving-ground between expert programmers from both companies, for FPU and
memory bandwidth. Raw throughput for web/db applications is another metric
entirely.

...It's already a big issue for AMD, and they're trying to make the best of it,
without spreading the news further that optimised C2s are more than twice as
quick as Barcelonas for FPU... The international press could easily pick up
on this and make it a worldwide issue!

AMD can still do well in data centres where throughput is much more important.

What is important is that SETI can only benefit from the competition and
optimisation.

If you read this

http://www.xbitlabs.com/articles/cpu/display/amd-k10_7.html

"As we see, the FPU of K10 processor became much more flexible. It acquired some unique features that Intel processors don’t have yet, namely, efficient unaligned loading, including Load-Execute instructions, and two 128-bit reads per clock cycle. Unlike Core 2, floating-point and integer schedulers use separate queues. Separate queues eliminate operations conflicts caused by use of the same execution ports. However, K10 still shares the FSTORE unit for SSE save operations with some data transformation instructions, which may sometimes affect their processing speed."

Architecturally there should be no reason why the k10 shouldn't be as fast or faster the C2. I wouldn't expect a "worldwide issue" to result from the comparison of optimized C2 code to unoptimized k10 code.

Also, as a general statement, the k10 seems to be well received in datacenters:

http://www.crn.com/white-box/202402138

For example

"There are no hardware conflicts and the power draw is as promised. They delivered on their technicals. On these high-performance compute and memory-intensive applications, they're kicking Intel's butt," said Brian Corn, VP of marketing and business development at Waltham, Mass.-based Source Code.

The biggest bummer was that they were six months late with the part. But I think the chip itself is performing ok so far.

End of lunch for me.
Having a separated queue for Int and float has some pretty serious down side. Let's take the example of Seti, you very often do Int to float and float to int conversion. In the case of K10, you can see a serious slow down when doing this, due the a synch required between the 2 queues. It is funny how it is spinned as a positive.

If you have a K10, try it, you ll be surprise, it is seriously slower. Example, you do a filter in a picture, you use a float color 3 plans, then, when you get to display, you convert the 3 plans to int.


In SETI, well, you can see the performance of SETI by yourself below, this is why I am saying that it needs custom optimization to avoid this weak point.


Back to mechanics.

In Ray tracing, the 3D noise generation does it severely.

---

who?
Skulltrail D5400XS

...Let's take the example of Seti, you very often do Int to float and float to int conversion. In the case of K10, you can see a serious slow down when doing this, due the a synch required between the 2 queues. It is funny how it is spinned as a positive...

Ok I'm not an opcode expert, but I notice this kind of thing:

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf

Page 165:

Floating-point-to-integer conversion in C and C++ requires the use of truncation. Use one of the instructions from CVTTSS2SI, CVTTSD2SI to convert a floating-point number to integer when truncation is required.

and page 166:

On AMD Family 10h processors, some SIMD conversion instructions are VectorPath and/or add a false dependency on previous instructions that change the same destination register. In the cases for which there are alternatives in Tables 9 and 10, these instruction sequences use DirectPath instructions and provide better performance. (All recommendations apply to both 32-bit and 64-bit software, unless stated otherwise.)
Several instructions may be required to perform some conversions from unsigned integer to floating-point, due to the lack of a suitable conversion instruction, therefore signed integers should be favored when converting to floating-point.

Could it be the code you are talking about used less than optimal k10 instructions? I didn't understand that point about synching the int and fp queues, the conversions go to a simd register no? How does that involve a communication between the queues? Honest question, I really don't know about such things.