Е точно това питам де, в линка на Рек пишеше нещо, че от NT насам се възползвали
от цялата машина вътре без някаква спирачка на 16-бита режим някакъв който
влачат кой знае от кога (8008? ).
Тоя по-нов не-16 бита код x86 ли е? (демек с разпънатите нагоре до 32 бита два
регистръра и половина) Ако е все такъв няма отърваване от хардуерния декодер
който няма как да свърши работата без значим зор откъм цъкане/тоци; няма да е двойно
но все ще е над 10%, после самият код за да пасне в x86 модела трябва да е по-обемист
(като брой инструкции ако не като обем памет, но по-скоро и двете) ще даде още
поне едно 30% и ей ти го.

Ами много ясно, че е х86 код. Едно време Win 95 и 98 вървяха както на 486 процесори така и на Пентиум. Което идва да покаже, че извън процесора всичко е същото и разликата е само в микро кода вътре в него. Даже сега ако не се лъжа си спомням, че с някои от първите пентиуми май имаше някакъв гаф с тоя микрокод, та правиха рикол на времето.
Незнам как стои въпроса сега с 64 битовите ОС и програми ама предполагам, че е същото щото на същия процесор можеш да сложиш и 32 битови такива. Та без значение какво правят вътре с карантиите легасито е толкова голямо и важно, че няма как да кажат като навремето Епъл: "Баста - от тук нататък всичко е ново и несъвместимо със старото, Който си е купил стари програми да духа супата." .

Е демек е това, което очаквах де. Ясно, че ако искат да останат живи трябва
старият код да върви а софтуерна емулация не може да се мери с хардуерна
такава от същото поколение и ей го на, x86 си живее и компилаторите мажат
като за него а върху намазаното слагат и още един слой размазано за АРМ.
Светът е прекрасен .

Е те в грамофоните едва ли емулират ARM. По-вероятно (и близко до акъла) е андроида да е портнат за х86. Както и Майкрософт пуснаха версия на Уиндоус 8 за ARM.

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

Можеш ли да сравниш кода за едно и също нещо от MS за ARM и x86? Това би казало много.
Прогнозата ми е, че за АРМ ще е по-дълъг (именно по споменатата причина ). Аз нямам
под ръка идея как да ги сравня де, затова чакам някой друг да го направи вместо мене .

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

Бе то ще се види и от инсталационния размер на нещо с еднакви функции ако имат
ама и аз не знам как да го намеря за минута-две. Интересно е именно какво изкарва
компилаторът, дали кодът за АРМ е по-дълъг от тоя за 86 и колко.

Наблюденията са ми основно върху GCC, че само него съм гледал за ARM - но мога да заявя, че генерирания код е съобразен с архитектурата, и се справя доста добре, особено ако е за истинския ARM където се използват условните изпълнения на всяка инструкция. Не ми е направило впечатление да има разни патърни които са за х86.

Като брой инструкции е по кратък, като байтове е по дълъг. Разликата между х86 и ARM e, че ARM-а са го проектирали програмисти, съответно е изключително добре оптимизиран за писане на сбит код.

Преди малко се опитах да намеря нещо ама за 4-5 минути до нищо смислено
не стигнах.
Все мнения на хора дето знаят по въпроса по-малко и от мене а аз практически нищо не знам.

Най-доброто, на което попаднах беше някакво сравнение как java графични аплети вървяли
гладко на x86 а засичали яко на АРМ, някой споменаваше спомени как в Mozilla писачите
се жалвали от това, че кодът е мислен за x86 и няма как да върви свястно на АРМ (т.е. това,
което аз очаквам да е).
Но и това беше в контекст все на "знаещи" та не е много.

Това е интересно твърдение - интересно как програмистите са успели да проектират хардуер . Имаш ли някакъв линк, където да се твърди такова нещо. Ще ми е интересно да го прочета, защото до сега от моите наблюдения не съм видял програмист, който да разбира добре хардуера. Да не говорим пък на какво ниво трябва да го разбират, за да могат да проектират процесор. Такива хора-пенкилери, дето да разбират от всичко еднакво добре (или от нищо като хората) съм срещал само в БГ-то . По белия свят хората обикновено са тясно специализирани.
Иначе генерално RISC архитектурата е по-добра за писане на сбит код, просто защото С компилаторите са оптимизирани още на времето за големите RISC машини. Такова мнение поне съм срещал много често из литературите. За разлика, че никога не съм срещал как някакъв добър хардуер е проектиран от софтуеристи както и обратното - добър софтуер да е написан от хардуеристи .

това е тема за безсмислена докторска дисертация, спонсорирана но ЕС.
ползата от нея ще е да се дудне по разно конференции кой е по-по-най.

всички джамлъци до 98 вървяха във v86, независимо от процесора. NT e особен клон на М$, който незнайно защо М$ зарязаха, подобно на xenix. явно няма кинти в надеждни системи, шарената чалга се харчи като топъл хляб.

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

бавно и мъчително обаче вървят към разпареляване. в началото беше плахо със SSL инструкциите, и то май главно за да отговорят с нещо на АМД. всичката еволюция от 20 години не им стигна за да си оправят паралелната архитектура. на практика първия процесор, който бачка практически паралелно е xeon.

но в крайна сметка ограничението е във скоростта на обмен с външния свят. паметта е голям камък, разните разновидности на PCI-също. кеша набъбна до незнайни висоти именно поради необходимостта да се разтовари външната шина на паметта. нищо чудно DDR6 вече да е със 32 сердеса...

същата болка подпира и АРМ. само че проблема е по-дебел, заради двата кеша и (ин)валидирането, особено при виртуализация и MMU. кошмар... като се сетя, че съм правил трейс на код за 8088 с брояч и руски осцилоскоп и ако един i7 процесор може да се сравни с любимата ми брадва с две дръжки, многоядрения АРМ е брадва с две остриета, ама от двете страни на дръжката - много яка, но непрактична.
така че - няма база за сравнение. едното е турбо-динозавър, другото е ултра-модерна... печка. който и да е многоядрен АРМ, ако го пуснеш на макс ще се разтопи за няколко минути. управлението на power- и clock-домейните изисква виртуозността на военен пилот берящ домати.

компилаторите би трябвало да се сравняват само по възможността да докарат кода по правилно изпълним. няма никакво значение дали единия прави 50М код, за другия 100М. важното е да успее да компилира сорс със 70К реда глупости.

обаче и двете трябва да работят с някакъв РАМ, а там като че ли приемливите идеи се изчерпаха отдавана. сега ни залъгват с неприемливите.
е, добрата новина е, че паметта е без почти пари. машини с 32гиги памет не са рядкост. до следващия пожар в някоя възлова работилничка.


е, и аз не съм виждал кой знае колко много, които да разбират от софтуера

В момента паметта е +50% отгоре, на това което беше преди няколко месеца.
Нямаш проблем с многото ядра в армовете. Всяка задача на отделно ядро, ако е нещо специфично и натоварващо, това се изнася на библиотека, която е писана за много ядра и многото ядра не си "помагат" взаимно, ами гледат да не си пречат. Т.е. трябва да се обработи някакъв файл на 4 ядра, значи го цепиш на 4 части и на всяко ядро пускаш едната част.

Изнамерих един - виж тук: http://www.ot1.com/arm/armchap1.html по специално:

По спомени от разни други сайтове които съм чел преди години, този който е мислил формата на инструкциите е писал и първия фирмуер (интерпретатор на бейсик и разни други неща) и това е оказало директно влияние върху формата да е удобен за програмиране - на асемблер де, не е мислен с идеята за Ц компилатор. С две думи - архитектурата е замислена от много малък екип - 2-3 човека, без предишен опит в дизайн на процесори, без да ползват развойни инструменти. Няма микрокод, анализа на инструкциите е чиста логика - нещо подобно на 6502. Затова и всичките им инструкции май се изпълняват за 1 такт, процесора е с много малко логически елементи от което пък следва ниската консумация което в комбинация с лицензния им модел ги прави може би най успешната архитектура за момента (като брой продадени чипове от съществуването си).

доста опростенчески...
но да засилим малко черните краски.
файла е моментни стойности на електрическа енергия.
състои се от 4 части, разположени последователно:
моментни стойности на напрежението
моментни стойности на тока
моментни стойности на кос-фи
моментни стойности на хармониците.

как твоите 4 процеса ще направят някаква статистическа обработка (средно-квадратична девияция примерно) на данни, който ги няма още?

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

таска, който смята кос-фи му трябва стойността на напрежението. чете променливата, ОС я сваля от диска.
и изненада... стойността е друга.

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