Jarz4b: www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF
Strona 260. Jeśli znasz budowę dotychczasowych Inteli lub AMD (32bitowych) zauważysz spore zmiany w potoku wykonywania instrukcji. Efektem tego będą przestoje (stalls) w wykonywaniu kodów zoptymalizowanych na 32b architektury (a każdy komercyjny soft jest obecnie optymalizowany automatycznie przez kompilator, szczególnie jeśli ktoś rozsądny wybierze Intel C++ compiler). Poszerzenie rejestrów o którym mówisz (al/ah>ax>eax>rax) nie ma żadnego wpływu na proca, to fakt, ale skoro połowa każdego układu logicznego leży nieużywana, to po co 64bitowy procek? Sumatory, subtraktory, multipleksery,... wszystkie one będą miały połowę szyny wolnej.
Na operacjach SIMD/SSE nie zyskasz żadnego boostu w tych prockach (choć jest szansa, że wrescie SSE1/2 nie jest upośledzone w AMD względem tego z Inteli - przeprowadzałam testy z których kilkuprocentowy spadek mocy przerobowej rozszerzeń SSE w prockach AMD względem tych SIMD; o porównaniu SSE na Intelu do SSE na AMD nie wspomnę).
Twoja ocena Windowsów jest powieleniem utartych zdań i nie będę z nią polemizowała. Dość powiedzieć, że mam styczność z technologiami MS, Suna i kodu otwartego i dostrzegam kolosalną różnicę. :>
Zintegrowany kontroler pamięci - jasne, to wypasiona rzecz. Ale naprawdę wolałabym zainwestować w HT - weź pod uwagę, że benchmarki wszelkiej maści to programy jednowątkowe. Q3 takie nie jest (żaden dobrze napisany program interakcyjny nie jest). Dam Ci przykład: P4 bez HT, otwieranie projektu Web w Visual Studio, gdzie lokalny VS łączy się z lokalnym serwerem IIS. Tragedia - około 15sekund dla dużego portalu. Z HT - poniżej sekundy (!). Kiedy masz aplikację wielowątkową żaden boost komunikacji z pamięcią Ci nic nie da. ;)
Poza tym to AMD się grzeją, nie Intele. :D