Is AMD doing well again?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Lenski pravi:
Yeah, on the other hand I don't see how ATI+AMD really *prevents* nVidia
from making chipsets and graphics for AMD processors. Mostly, it just
seems to have raised the bar for the competition... the available
chipsets for AMD processors have improved a lot since the merger.

Agreed, but you know how this works. The consumers don't really have a
word in all of this, we can only buy what they make, and they are afraid
to make stuff that would have too much competition.

Right. My first AMD64 box (http://www1.shopping.com/xPF-Acer-ASE360-MT-
A3500-1GB-200GB-DVDRW-NVIDIA-XP-MCE but with 1gb RAM) had the nForce4
chipset, and it was really impressive. Not expensive, but great I/O
performance and tons of features. GeForce 6100 IGP worked well too. If
nVidia made something equally good and cheap for Socket AM2+, I would've
probably bought that.

My own computer, which is now about 2.5 years old, has a nForce 550 MCP
with an Athlon 64 x2 5200+. Although I brought this hardware to replace
my old LGA775 Celeron D setups which made my room too hot to live in, I
found the fluent responsiveness of such setups very cool and never
brought anything else since.

With the recent switch to AM3 though, nForce based setups are impossible
to find. Maybe they will start making them after some time.

So you're saying Intel cranks up the CPU performance, benefiting poorly-
written CPU-bound code, while AMD cranks up the I/O performance?

That should be pretty obvious from the way Intel's FSB never recieved
much attention, but they have these ridiculous L2 cache sizes. AMD
always had an advantage with the FSB due to their integrated memory
controller design, but they did a lot to improve it too (HyperTransport;
probably to help with their multi-CPU setups). And if you ever noticed,
the AMD memory controller is a great deal better than any Intel memory
controller in any Intel motherboard, resulting in those silly
requirements you sometimes see on Intel boards, which need the memory to
run on 667 MHz and no faster, or it won't boot.

I wouldn't strictly call it "cranking it up", it's just what the two
companies invested most into and that is actually the direction they
picked. Some of this is very obvious from the way the two companies
decided to solve certain problems... for example microcode:
* On Intel, the microcode grew more and more sophisticated and it now
does a great deal of processing (basically runtime optimization as code
is fed into the CPU), which is what gives Intel CPUs the ability to run
some code very quickly in it's characteristic jerky performance (does
some things very quickly, but momentarily slows down unexplainably on
others; you can actually notice this when using the computer under high
load)
* On AMD, they took a more textbook approach to microcode and simplified
it as much as possible, making individual instructions execute quicker,
in less CPU cycles. This raw performance however does not really help if
the code is doing nonsense, which a more sophisticated microcode would
have detected and remedied.

This point is also one of those things that leads to all those arguments
amongst less informed users. The AMD philosophy is architecturally
correct, honest and efficient, but the Intel philosophy performs better
with the software we use today. Regardless of this, I subscribe to the
AMD philosophy and recommend it to anyone who expects to get a good
computer, because it has a better chance of performing better in
uncontrolled circumstances such as daily use (as opposed to say, lab
benchmarking).

So if I understand you correctly... CrossFire transfers most of the inter-
card data over the bridge which is totally separate from the PCIe bus.
While SLI transfers the inter-card data over the PCIe bus itself, thus
requiring some chipset support?

Exactly.

Though I can't honestly say that, given what is known of the PCI-Ex
network, it would be impossible to do inter-card communication over the
PCI-Ex bus without a special chip. Maybe they designed the requirement
in order to be able to sell it later. Or maybe it serves some obscure
purpose such as selecting which graphics card has a screen attached or such.

Interesting! Did you do some hacking yourself, or read about these
CrossFire/SLI distinctions somewhere else?

What I explained earlier I collected from various sources on the Internet.

Having been programming a kernel recently, I have had to
reverse-engineer (not copy the code, but just see how it's made so that
I could implement support; not everybody writes such nice documentation
as IBM) a lot of things (and uncovered some of the most ridiculous
inefficiencies you could think of in the process), so a BIOS wouldn't be
a particularly big step. The only reason I haven't done it yet is simply
that I have no idea what the data at the start of the BIOS binary is
supposed to be -- is it data, 8bit code, 16bit code, 32bit code, etc?
Needless to say, finding documentation on this, if it even exists to
begin with, is tough work.

Well, on second thought, it could be just memory mapped and thus easy, I
just have to get started. I have a friend to bounce ideas off with, need
to see if he has the time -- if you have any BIOS upgrade images you
want to share thus, just email them to me.

LP,
Jure
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKqT1hB6mNZXe93qgRAnnIAJsHc7TWaEDcstqUMShxl4 j6cvB3+QCcC1lc
xr8GztFvdiL24xibWTHz4Ec=
=1GUG
-----END PGP SIGNATURE-----

Jure Sah writes:
* On Intel, the microcode grew more and more sophisticated and it now
does a great deal of processing (basically runtime optimization as code
is fed into the CPU), which is what gives Intel CPUs the ability to run
some code very quickly in it's characteristic jerky performance (does
some things very quickly, but momentarily slows down unexplainably on
others; you can actually notice this when using the computer under high
load)

I've noticed exactly this behavior on my core2duo system: it's quite
fast at pure number-crunching CPU-bound stuff, but oddly jerky in
general usage, and feels vaguely like it's choking on some bottleneck or
another. My phenom I system, by contrast is somewhat slower per cycle
for CPU-bound stuff, but in general usage feels much smoother and more
responsive (less "bottlenecked"), especially when using big bloated apps
and lots of disk I/O.

I attributed this difference to better I/O and memory bandwidth on the
AMD system, though...

[The AMD system using a SB700 for the actual disk I/O, which seems to
generally be considered a bit of a dog, but it doesn't seem to matter in
practice -- it still has far better disk I/O throughput than any other
system I've used.]

-Miles

--
The trouble with most people is that they think with their hopes or
fears or wishes rather than with their minds. -- Will Durant

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Just came across living proof of such alliances and how they are made
without the interests of the end-user in mind.

http://www.phoenix.com/en/OEM-ODM/Pr...re/default.htm

Phoenix makes these BIOSes, which naturally run on AMD motherboards as
well.

The ad starts out as "Phoenix TrustedCore is the first firmware offering
to fully meet the compliance requirements for Intel Onscreen Branding at
pre-OS startup screen." -- Why the f*ck would an end-user care if it was
fully capable of displaying the Intel logo in all colors at boot?!

It's also explicitly designed to work with something from Microsoft
Windows Vista, but that is perhaps less surprising.

There is also a diagnostic program packed inside this bugger (though
that one may be by Dell), which checks if the CPU has the "GenuineIntel"
logo and yes all this is from an AMD motherboard.

Talk about bias.

I wrote:
We have been noticing a situation on the market for some time, where
certain manufacturers and/or software makers tend to "stick together"
and help each-other lock out their respective competition.

LP,
Jure
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKrpAdB6mNZXe93qgRAj3MAJ9JAkT5YSyQ8Ltpnd2CBh UNmyLp5wCfXWMJ
I1BzORVy82xQhWtr5CTUzmw=
=Kndw
-----END PGP SIGNATURE-----