Трябва да правиш разлика между многоядрен и суперскаларен професор. Идеята на суперскалата не е да дублира всичко, затова и грубо подобрението е 30-40% според зависи.
Значи:
1) не всички модули са двойни и съответно не можеш кои да е две инструкции да дублираш
2) Дори и операции, които на теория могат да се дублират, на практика ако компилатора не ги е подредил добре се изчакват, щото едната инструкция се нуждае от резултата на предишната.
3) Най-големия проблем обаче е тънката шина. При ARM7 имаш 100% уплътнение само от фетчване на инструкции, затова и няма как load/store да се изпълняват на 1 клок. Решението е кеш, или двойно по-широка шина. При АРМ9 вече имаш кеш, който ти позволява ядрото да има трафик по-голям от трафика към истинската памет. Сега на това нещо като му добавиш и суперскаларност, нуждите от трафик нарастват още поне 30%. Демек съотношението на трафика ядро/памет стига една критична точка. И когато удариш кеш мис става грозна картинка - половината професор седи и бездейства, докато кода не зацикли в кеша. Ако случайно си извикал функция без цикъл, т.е. линеен код - резултатите стават плачевни!
Истинското решение е разбира се шина с по-голям бандвид, но това никак не е лесно решение. По-голям клок на шината спрямо ядрото знаеш не става. Отиваш от 32 на 64-бит.. но това те спасява само в обхвата 200-400MHz. От там нагоре нещата стават сериозни. Примерно 1GHz ядро ако иска 2* 32-бит инструкции на клок + 2 * 32 бит данни имаш 128 Gbit/s трафик. Верно това е към кеша, ама от другата страна на кеша дори и с 64-bit DDR си някъде на 1/4, без да броим latency изобщо. Демек на кеш мис просто си мъртъв.


Те заради разни такива проблемчета 2 инструкции на клок изобщо не е два пъти по-бързо

Навсякъде говоря само за поведение на ядрото, бройката ядра ако искам да я вкарам
в контекста го споменавам изрично (в постовете си дотук). Всички power процесори, дето
съм виждал, са суперскаларни (2 и кусур инструкции на цикъл с късмет за кусура); някои
имат и по повече от едно суперскаларно ядро.

> 1) не всички модули са двойни и съответно не можеш кои да е две инструкции да дублираш

При 603e и подобните му реално можеш две инструкции на клок ако едната е integer, другата
floating point; по-големите ядра имат до 4 integer unit-а, не ги знам колко бързи ги броят (очевидно
поне две integer инструкции на клок ще докарат).

> 3) Най-големия проблем обаче е тънката шина. При ARM7 имаш 100% уплътнение само от фетчване
> на инструкции, затова и няма как load/store да се изпълняват на 1 клок. Решението е кеш, или двойно по-широка шина.

При power данните са 64-бита, но кешовете са два по 64 бита - за инструкции и за данни.
Е, четенето или писането на 32 бита регистър си е цял цикъл, 64 бита (FP) регистъра и
той за толкова се пише.

> Верно това е към кеша, ама от другата страна на кеша дори и с 64-bit DDR си някъде на 1/4, без да
> броим latency изобщо. Демек на кеш мис просто си мъртъв.

Е то поначало всичко се мери само при кеш хит, иначе стават много променливите, иди го мери (преди
да е късно, де ). А и кешовете са по 32к всеки, няма много какво да напише човек да не му
стигнат (освен най-честото, копиране на данни, ама то тогава кешовете не помагат, че и
пречат понякога).

Тия процесори, дето не работят а им се облизвах (e600 ядро) имат по два 64-бита DDR интерфейса,
и позволяват човек да ги interleave-чи. А бе много хубави биха били ако работеха.... Но проектираното
решение на проблема със забиването на ядрото от user level е... да не го оправят.

уф... tqi почвам да се чудя доколко наистина познаваш собствената си архитектура, ама то няма как да имаш поглед върху архитектурите ако бачкаш само една

Значи, всички риск машинки правят нещата на стъпки - поне три (fetch, decode, execute) и за всяка стъпка си има едно или повече блокчета. Ако не намесваме суперскалата при стандартните risc-ве през някои блокчета минават всички инструкции, а през други блокчета минават само определени инструкции. Примерно ако има блокче (копроцесор) за плаваща запетая, през него минават само съответните инструкции.
На пръв поглед изглежда логично, но като се замислиш някои блокчета могат доста време да бездействат... Тоя проблем си има различни решения - примерно ако преработиш до суперскаларна архитектура, удвояваш само най-често използваните, а "безделниците" почват да се товарят от самосебе си щото почват да влизат повече инструкции в ядрото...

Но тук твоята любима архитектура има друго решение... В общи линии пак имаш integer, float, load/store и т.н. но работят по малко по-различен начин. Най-видима е разликата при integer-а. Освен че прави аритметиката на аритметични инструкции, той може да прави и адресната аритметика. Очевидно така аритметиката се натоварва добре и при чисти аритметични инструкции и при load/store.

Уникалното в случая не е самата идея, а нейното пълно прилагане. Цялото пауър ядро е направено с тая идея в главата. И резултатът е видим - доста по-разнообразни инструкции, доста по-добре балансирано ядро (с малко безделници) и в същото време по-прост и по-изчистена схема, щото сметките ги правиш само на едно място.

Иначе малко или много тая концепция се ползва от всички. Просто не в такъв мащаб. Примерно при ARM имаш т.н. шифт-операнд, които се ползва и при чиста аритметика и при адресна аритметика. Но това е само за шифтвания, а не всички аритметични операции.

Сега от цялата тая акробатика, при простите пауъри като 603е имаме 2 или повече операции на клок, а не както говориш ти за 2 инструкции. Всъщност тия животни дори не би трябвало да се наричат суперскаларни според мен, защото при всички останали архитектури суперскаларност означава не просто паралелна работа, ами паралелна работа на еднакви по функция блокчета.
Примерно ако прост АРМ може да прави по 1 събиране всеки клок, то суперскаларен АРМ прави по 2 (или повече) на клок.
Докато твоя 603е има само 1 integer модул и ако му пуснеш поредица само от ADD ще ти ги изпълни за 1 по клок всяка, както простия АРМ. Не искам с това да кажа, че са еднакви. Напротив, 603е има по-висока производителност от ARM9 като цяло.
С две думи предимствата на паура се състоят в:
1) По-богат инструкшън сет, демек по-близко е до CISC. Важното в случая, е че сложните инструкции се разбиват на повече от една операция, които се изпълняват паралелно (или почти).
2) Възможност да изпълняваш повече от една, но различни по тип *операции* на клок.

Забележи, че ефекта от горните две точки не се натрупва, т.е. или изпълняваш по-мощни инструкции, ИЛИ повече но разнотипни инструкции.

В крайна сметка твърдението за "2 и кусур" не е вярно, или поне не е коректно да се твърди когато става дума за сравняване на производителснот. Това че понякога може да изпълниш 2 или 5 инструлции за един конкретен клок, не означава че всеки клок може да го постигнеш. Личното ми наблюдение е, че малките паури са с около 20% по-висока производителност спрямо АРМ9. Говоря ти за тестове при които се търкаля лайнукс или друга достатъчно тежка боза, а не за 32К и оптимизирани програмчета...
На практика има много други фактори, като периферията примерно, която може да вдигне +/- 100% производителността.

LOL, Миро,

бе ти понякога като почнеш авторитетно да ръсиш свободни съчинения спиране нямаш.

Само да разсея някои от очевидните ти заблуди от предишния пост:

- супрескаларна се нарича архитектура, която може да завършва (retire) повече от
една инструкция на цикъл (започването и то така, очевидно). Латентността е отделен
параметър, различен от ммм throughput-а, последният се брои в случая.
Сиреч една инструкция може да минава за 5 цикъла през pipeline-а, но
след като всеки цикъл почва по една такава и свършва по една такава
това прави една инструкция на цикъл с 5 цикъла латентност.
Дано е станало по-ясно сега.

- 603е може да *приключва* (retire) по 2 и кусур инструкции на цикъл, оттам
и твърдението им за май 860 MIPS беше за 400 MHz процесор. Една integer,
една FP за 2 и един "fold-нат" branch за кусура.

Всичко това според разбиранията на freescale, ако някой избере да нарича
суперскаларен процесор нещо дето е в осмоъгълен корпус например
друга - но и само негова си - работа.

Не знам само това ли бяха заблудите в поста ти за разсейване, ама сега
нямам време за повече. Може би по-късно ще погледна пак.

[edit]
Айде и това, че е по-лесно да се поства отколкото да се работи, пък после
се захващам.

> ... Говоря ти за тестове при които се търкаля лайнукс или друга достатъчно
> тежка боза, а не за 32К и оптимизирани програмчета...

Настрана от факта, че сравнявайки "бози" сравняваш в най-добрия случай
работата на компилаторите за платформите, заблудата за разсейване тук
е представата ти за "оптимизирани 32к програмчета".
Кешът не работи така. Ако ще и 32 гигабайта да ти е кодът, огромната част
от времето кодът цикли така, че не пипа и част от 32к пръснати из 32-та гига.
Така че на практика винаги - 99+% от времето - има кеш хитове, когато
става дума за ефикасност на ядрото (примерно филтър или компресор
и т.н.). Както споменах преди, кешът не помага само при копиране на
данни (може дори да пречи в някои случаи).
[/edit]

Те всички суперскалари могат да правят по 2 инструкции за клок, но никой не може да го прави всеки клок.
Дадох ти прост пример - сложи един ADD в цикъл и ми кажи по колко събирания ще получиш за клок.


Освен ти обясних, че пауърската "суперскаларност" в известен смисъл е уникална и за разлика от другите суперскаларни риск машинки постига паралелна обработка *без* дублиране на еднотипни модули. Не го казах в лош смисъл... това си е предимство, а защо IBM са избрали да го опишат това предимство с тоя термин аз нямам представа. Да, също постигат повече от една инструкция като другите, но НЕ по същия начин.

Колкото до това, че от 400MHz постигат 860 MIPS също е леко заблуждаващо. Не казвам, че лъжат... щото всички го правят. Примерно за АРМ9 на 180 MHz Атмел твърдят че дава 210 MIPS. Да ти казвам ли, че това е ядро БЕЗ НИКАКВА суперскаларност? Донякъде е търговски трик, но си има и техническо обяснение - хората са свикнали че RISC означава 1 инструкция за клок, което не е съвсем вярно, но така са свикнали. И за ARM7 официално се води 1 MIPS/MHz (което също не е коректно), но традиция... И как да отличиш ARM9, който наистина дава 1 инструкция за клок? Търговците са решили просто, да умножат по бързодействието и така АРМ9 е уж 1.3 MIPS/MHz. Всъщност Атмел претендират за 1.2 ама щото отчитат и проблемите с памети и т.н.
По същия начин и твоето 603e. Предполагам средно изпълнява по 1.2 - 1.3 паурски инструкции за клок, като сложиш че една паурска инструкция средно върши работа колкото 1.2-1.3 риск инструкции тип АРМ9 и накрая като умножиш още по 1.2-1.3 подобно на атмел за да изравниш с класическия риск получаваш 2 и нещо MIPS/MHz.

Малко ми е странно да споря с теб на тем паур архитектура... ти пишеш на асемблер, грехота е да не знаеш как ти се изпълняват инструкциите. Освен ако не си успял така да ги нареждаш floating - integer-floating, че да се изпълнят по 2 наведнъж... Все едно роднина - милиционер - роднина - милиционер

Миро, стига бе. Както казват англичаните: като си в дупка, спри да копаеш.

Странно ти било да ми обясняваш, пак авторитетно казани глупости и т.н.

Никой не могъл да прави по 2 инструкции всеки цикъл, пак глупости.
Може и още как - не всякакви, но повечето може. Дори малкото 603е
може всеки цикъл да приключва по една integer + 1 FP инструкция, както май
за трети път ти обяснявам. В конкретния ти пример няма никаква пречка
всеки цикъл да приключва по едно integer ADD и едно FP add; в по-големите
ядра, с по повече от един integer unit, може и двете да са integer. Или
пък MUL и т.н. Не може деление, очевидно - то е 15-20 цикъла.

Аз с тия двамата на една маса няма да седна.

Горе долу е това:
- MD5
- AES
- DES
- CRC
- Linked list
- Matrix multiply
- State machine

Бъркаш! Те са 100% икономия на питие и мезе!

Ама понякога изпивам някоя бира, може дори и две (ако позабравя за гумените
последици в тиквата....).

И аз след третата ракия не посягам към бирата, че става мазало.

що бе? ако има достатъчно бира и наденички, ще е голямо шоу.
накрая единия ще наРИСКне, а другия ще се поСКАЛАРчи. ние ще се само СУПЕР.

освен това ще има и образователен ефект. може най-накрая да схвана каква е разликата между ксеон и кор-дуо.
като стана дума за скалари, вектори и други подобни. алфата какъв процесор беше?
и що замина така ефикасно в небитието? дали само компилаторите й бяха криви?