Прогрес ARM процесорів

[tornadox]

шо, опять? (с)

так Юрій викладач, це його робота повторювати одне і теж поки "невігласи" запамʼятають. 90 сторінок фладу який складається з одних і тих самих текстів.

сильно простіша архітектура команд. Наприклад у х86 команди: купити хліб, купити масло, купити молоко
проц під час виконання мусить їх розбивати на підкоманди - піти в магазин, взяти хліб, повернутись, і оптимізовувати - щоб за один похід взяти все
у той час як у АРМ просто нема команди купити хліб, а є лише прості, і оптимізація не кожен раз під час виконанння, а один раз під час компіляції. У компілятор LLVM вкладають великі гроші - найбільше Епл та Гугл

у х86 - складні команди. Якщо на пальцях - то типу: купити молоко, купити масло, купити хліб
і проц має їх оптимізовувати постійно під час виконання щоб за один похід в магазин - відразу все взяти, щоб не ходити багато раз. Відповідно тому й гріється, і споживає більше
в той час як АРМ - сильно простіші команди - типу піти в магазин, взяти масло, взяти молоко, вернутись
і вся оптимізація під час компіляції
Також команди х86 різної довжини - їх ще й не так просто докодувати в паралель

[dext]

я досі чекаю конкуруючий ноут до MacBook air, навіть не дешевший хоча би за ту саму ціну?

іміджевий, одноразовий, непрактичний продукт, без ринку поза емейзінгом, ще за часів x86

в ньому буде браузер настільки сама швидкий при роботі від батареї?

браузер в роботі чи ви в роботі? це має значення

в ньому буде такий самий якісний корпус екран тачпад клавіатура автономність?

"Staingate" is a common issue where the anti-reflective coating on MacBook screens delaminates, causing permanent stains, often triggered by pressure from the keyboard or improper cleaning. To fix this, you can either have the screen replaced by Apple, or remove the entire coating using alcohol wipes, a mixture of baking soda and water, or screen polish

The Apple butterfly keyboard was used in MacBook Air models from 2018 to 2019 (specifically Retina, 13-inch models), designed to be ultra-thin but plagued by high failure rates due to dust and debris

Я - якість понад усе

[yuriy_dd]

шо, опять? (с)

доводиться повторювати - бо місцеві досить швидко забувають

пристрій, до якого ПЗ прибите гвіздками

самі придумали, самі повірили

хоч на зараз ви вже викинули свої х86 та перейшли на макос?

чому? невже не можна користуватись різними пристроями кожен в своїй категорії? Чи може у вас грошей є лише на один ноут?
може ви викинули смарти на АРМ? і перейшли на х86?

макбук ейр так може?

мені вже надоїло відповідати на одні й ті самі питання - ще й ви самі запитуєте - шо, опять?
ви ж і провокуєте те саме
напевне пора блокувати таких

ви не повірите, щоб флудити на оверах, вистачіть доісторичного пристрою. та і на інших сайтах - швидкість, з якою браузер відмалює текст, в 99% випадків не має ніякого значення фактично. бо біоробот перед екраном не вміє швидко працювати.
показники улюбленого вами speedometer не значуть рівно нічого

просто у вас недостатньо знань - чому так багато компаній та розробників 10 років робили цей тест

Відправлено через 3 хвилини 42 секунди:

так Юрій викладач, це його робота повторювати одне і теж

люди питають знову, ви відповісти не в стані, напевне в силу обмеження знань, заперечити мої аналогії - теж

"Staingate"

вперше почув про таке

The Apple butterfly keyboard

хотіли досягнути малий хід - не вийшло, є багато інших речей на яких Епл обламалась, і що? не помиляється хто нічого не робить

[artko]

самі придумали, самі повірили

та ладно, невже на макбук ейр останній вже можна встановлювати windows чи linux? )

чому? невже не можна користуватись різними пристроями кожен в своїй категорії? Чи може у вас грошей є лише на один ноут?
може ви викинули смарти на АРМ? і перейшли на х86?

невже це я безперервно пропагандую арм у вигляді божествених Мx які бьють х86 застарілий по всіх фронтах та не мають ніяких проблем з ПЗ? навіщо ж ви досі користуєтесь х86? щось математика не сходиться.

мені вже надоїло відповідати на одні й ті самі питання - ще й ви самі запитуєте - шо, опять?

"доводиться повторювати - бо місцеві досить швидко забувають" і знов по колу іде як космічнний корабель арму бороздить простори великого театру.

[AntonyKandaurov]

навіщо ж ви досі користуєтесь х86? щось математика не сходиться.

В цьому вся фішка, 91 сторінку топікстартер воює що " арм топ" але чогось продовжує шкваритись об відсталий х86 бо

чому? невже не можна користуватись різними пристроями кожен в своїй категорії? Чи може у вас грошей є лише на один ноут?

Ось ця біполярка, і тому вся ця тема дивно виглядає

Відправлено через 2 хвилини 20 секунд:
Якщо ми користуємось пристроями "кожен в своїй категорії" то до чого це все? Просто від нічого робити шукаємо who is the boss of the gym? Чи у кого довший? Ось це осягнути мені не вистачає знань і вмінь

Відправлено через 2 хвилини 53 секунди:
P.s. доцентику просто на кафедрі між викладанням сумно, тому від сидить і створює " баталії" в інтернеті від нудьги. Іншого пояснення я не маю

[tornadox]

люди питають знову, ви відповісти не в стані, напевне в силу обмеження знань, заперечити мої аналогії - теж

Юрію, проблема не в тому, що "люди питають знову", а в тому, що ви відповідаєте завжди однією і тією ж заученою аналогією, незалежно від контексту і рівня обговорення.

Ваші приклади з "купити хліб/молоко" це навчальні аналогії, максимум рівня першого курсу, щоб заповнити прогалину у базовому розумінні RISC vs CISC.
Але вони не працюють як аргумент у технічній дискусії про сучасні процесори, де:

• x86 вже десятиліттями не є складними командами напряму

• декодування, µops, out-of-order, µop кеш, macro-fusion - це не постійна оптимізація під час виконання, а давно вирішені інженерні задачі

• ARM так само має складні фронт-енд і бек-енд компроміси, просто в іншому місці пайплайну

• LLVM не робить магію, а лише переносить частину складності з рантайму в компайлтайм, створюючи інші обмеження

За 90+ сторінок тут уже неодноразово розклали ці моменти по поличках, але у вас тунельний зір: усе, що не вписується у вашу лекційну модель, ви просто ігноруєте.

Ви не дискутуєте, ви читаєте лекцію.
Це працює в закритій системі, де:

• є викладач

• є студенти

• є обмежений час

• і немає зворотного тиску практики

Але це не працює у відкритій інженерній дискусії, де практика важливіша за красиву аналогію.

Ваша аргументація повністю теоретична.
У вашій картині світу:

• теоретик завжди правий

• практик - двійочник, бо він не знає всієї теорії

• людина, яка працює з реальним навантаженням на x86, невіглас, бо не захоплюється попугаями M1/2/4/5 в Cinebench

Це класичний підхід радянської та пострадянської університетської системи, де:

• зубріння = успіх

• практика = щось другорядне

• реальні обмеження і трейдофи знецінюються

Але головна мета університету - не в тому, щоб людина могла повторювати правильну теорію, а в тому, щоб вона могла вирішувати складні реальні задачі, маючи мінімальний теоретичний базис і вміння шукати, аналізувати і комбінувати рішення.

Ви ж застрягли саме в теорії.
Тому й повторюєте одне й те саме, бо це єдине поле, де ви почуваєтеся безпечно.

Відправлено через 15 хвилин 12 секунд:

вперше почув про таке

Це якраз і є показник браку практики. Ви намагаєтесь видати бажане за дійсне, але читання лекцій через Zoom або перегляд презентацій не є тотожним роботі в сучасній комерційній IT-компанії.

• Якби ви хоча б інколи дивилися реальні описи вакансій в IT, то знали б, що практично всі компанії або забезпечують спеціалістів лептопами, або дозволяють працювати з власних. І ні, це не випадковість. Я не буду вдесяте пояснювати, чому саме лептоп є стандартом індустрії.

• Жоден спеціаліст у здоровому глузді не купує найдешевший молоток, якщо в нього контракт на кілька років і щоденна робота. Те саме з покупкою найдешевшого MacBook Air. Його обмеження стають відчутними не в бенчмарках, а вже через пів року чи рік реальної роботи.

• Mac mini в реальності беруть максимум в офіс, для бухгалтера або офіс-менеджера, де в контракті чітко прописано роботу виключно з офісу. Це не робочий інструмент мобільного спеціаліста.

Тому "вперше почув" тут звучить не як відкриття, а як чергове підтвердження того, що ваш досвід - переважно теоретичний, доповнений ютубом, а не практичний.

[yuriy_dd]

x86 вже десятиліттями не є складними командами напряму

та ви що? ну розкажіть як не є складно виконати: int *p; (*p)++;
розкажіть по пунктах що робить проц/(ядро)
чи є аналогічно команда у АРМ? а як там це зроблено?

декодування, µops, out-of-order, µop кеш, macro-fusion - це не постійна оптимізація під час виконання, а давно вирішені інженерні задачі

якщо давно вирішені - то коли будуть енерго-ефективні х86 проци для смартів?
пс: я ще забув згадати про команди різної довжини. До речі знаєте як релазіувати декодер в паралель для х86? або як він реалізований?

LLVM не робить магію, а лише переносить частину складності з рантайму в компайлтайм, створюючи інші обмеження

які обмеження?

Але це не працює у відкритій інженерній дискусії, де практика важливіша за красиву аналогію.

Ваша аргументація повністю теоретична.

я багато разів казав - що я практично перевіряю на свому коді, починаючи з М1
ви таке робили особисто?

вперше почув про таке
Це якраз і є показник браку практики

це є показник що висосали проблему

Те саме з покупкою найдешевшого MacBook Air. Його обмеження стають відчутними не в бенчмарках, а вже через пів року чи рік реальної роботи

саме тому є купа відгуків як люди перейшли з макбук про на ейр і в шоці що воно по факту робить не гірше?

Mac mini в реальності беруть максимум в офіс, для бухгалтера або офіс-менеджера, де в контракті чітко прописано роботу виключно з офісу. Це не робочий інструмент мобільного спеціаліста

в чому проблема - що воно робить мені роботу, чекає на запит і готове відповісти миттєво?
тут пропонували використати х86 + wake on lan - за скільки прокинеться і відповість? впишеться в 30мс?
ті люди що таке пропонували - на ваш погляд - маю достатньо знань, чи все таки нулі без практики?

[dext]

та ви що? ну розкажіть як не є складно виконати: int *p; (*p)++;
розкажіть по пунктах що робить проц/(ядро)
чи є аналогічно команда у АРМ? а як там це зроблено?

якої команди, що складно зробити?
у вас немає жодної компетенції в програмуванні...

[yuriy_dd]

якої команди, що складно зробити?
у вас немає жодної компетенції в програмуванні...

я таке можу сказати про вас, додайте "-O3" в Compiler options
проаналізуйте як помінявся код - особливо для х86
зробіть висновки
а тепер скажіть - як таке просте ви могли не знати?
чекаю на відповідь

[dext]

якої команди, що складно зробити?
у вас немає жодної компетенції в програмуванні...

я таке можу сказати про вас, додайте "-O3" в Compiler options
проаналізуйте як помінявся код - особливо для х86
зробіть висновки
а тепер скажіть - як таке просте ви могли не знати?
чекаю на відповідь

повторюю: у вас немає жодної компетенції в програмуванні

[yuriy_dd]

повторюю: у вас немає жодної компетенції в програмуванні

я ж вам дав приклад коду - до чого тут:

Код: Виділити все

int sum_x(int x, int a, int b) { 
    if (x != 0)
        return a + b;
    else
    return a - b;
}

[dext]

я ж вам дав приклад коду - до чого тут:

ви надали приклад складної команди на x86 з аргументацією, що на АРМ аналогічних команд немає, а вони є (бо ви просто не знайомі з ISA), тож декодери на ARM також складні - що доводить відсутність вашої компетенцію також в архітектурах ЦП

[yuriy_dd]

ви надали приклад складної команди на x86 з аргументацією, що на АРМ аналогічних команд немає, а вони є (бо ви просто не знайомі з ISA)

ну то дайте мені цю команду? аналогічну яка присутня у х86 - про яку ви не знали
перший приклад коду - ви не змогли самостійно написати щоб компілятор згенерував цю команду - ви потішились що на х86 подібно як на АРМ
другий приклад коду - взагалі не про те

що доводить відсутність вашої компетенцію також в архітектурах ЦП

будь хто побачить що доводить ваш код і ваші тексти

[dext]

ну то дайте мені цю команду? аналогічну яка присутня у х86 - про яку ви не знали

я чудово знаю про складні команди x86, а от ви про такі в ARM - абсолютно нічого

перший приклад коду - ви не змогли самостійно написати щоб компілятор згенерував цю команду - ви потішились що на х86 подібно як на АРМ

бо мало хто з O3 компілює релізи

другий приклад коду - взагалі не про те

другий приклад коду доводить, що там де в x86 кілька простих - ARM генерує одну сладну, ситуація зворотня вашому прикладу

і я таких прикладів складних команд ARM (про які ви вочевидь не знаєте нічого) можу навести багато

будь хто побачить що доводить ваш код і ваші тексти

звичайно, тому я одразу даю посилання на godbolt

[yuriy_dd]

я чудово знаю про складні команди x86

я навів ніби саме просте, а ви не знали

а от ви про такі в ARM - абсолютно нічого

то кажіть

бо мало хто з O3 компілює релізи

ого. Ви реально так вважаєте? якщо що - я компілюю постійно з оптимізацією, але з -Ofast - про таку чули? і так - компілює відчутно важче і довше

другий приклад коду доводить, що там де в x86 кілька простих - ARM генерує одну сладну

і де та складна команда?

[dext]

я навів ніби саме просте, а ви не знали

не тіште себе вигадками, не допоможе

то кажіть

про що і мова - нуль компетенції в ARM ISA...
підказка: рахуйте кількість та тип інструкцій

ого. Ви реально так вважаєте? якщо що - я компілюю постійно з оптимізацією, але з -Ofast - про таку чули? і так - компілює відчутно важче і довше

з O3 вмикається loop unrolling та агресивний inline - що іноді призводить до падіння продуктивності через роздуття коду бо його гарячі частини перестають влазити в L1 -- з лікбезом для вас на сьогодні поки все

і де та складна команда?

і ще один доказ відсутності компетенції в ARM ISA

Бачите як буває: про складні команди в x86 можна почитати будь-де, а про складні команди ARM - дізнатися хіба що з власного досвіду, чого у вас вочевидь немає, а в мене прикладів - достатньо

[dext]

Починаємо раунд

-Ofast - про таку чули

-Ofast enables all -O3 optimizations.

давно відомий мені, але не вам баг з -O3: https://dev.mysql.com/worklog/task/?id=10343

-ffast-math

активує небезпечні оптимізації без урахування вимог стандарту ieee754 - як от некоректну поведінку при обробці NaN

розказуйте які ще дурниці робите на постійній основі

Відправлено через 4 години 14 хвилин 20 секунд:
Безкоштовне пояснення для пана yuriy_dd щодо шкоди/непердбачуваності O3 загалом: в сучасних x86 ще з часів Core 2 Duo 2006-го року є така річ як LSD (Loop Stream Detector, а не те що пан yuriy_dd подумав) або його аналоги для L0i для Sandy Bridge+, тому якщо робити агресивний loop unrolling код роздувається і починає вилазити за LSD/L0/L1, що негативно впливає на продуктивність в реальних задачах як от MySQL.

Як в сучасних ARM (aarch64) так і в старих (arm32) достатньо складних інструкцій накшталт ldmia/stmia/cbz/cbnz/ldp/stp (записуйте пане yuriy_dd) які декодуються декілька простих операцій з однією метою: зменшити розмір коду в L0i/L1i -- саме те, що робить x86 з початку свого існування

[Шаженла]

Не ради холиваров.

Можете скинуть объективные тесты x86 vs ARM что бы понимать в каких обстоятельствах наиболее оптимально использовать разные машины. Где какие слабости. Интересует от домашних до рабочих нагрузок.

P.S. Мне это надо для личного просвещение, так и просвещения уверовавших в чудо от Apple и начавших лепить эту технику куда угодно ибо "Apple M круче AMD Ryzen".

[dext]

наиболее оптимально использовать разные машины

Виключно ціна питання: якщо не залежите від софту/екосистеми яблука - купуйте x86, де за ті ж самі $$$$ можете купити більше RAM/SSD/SSD/GPU/CPU ну і взагалі мати можливість обирати/оновлювати ці компоненти.
Хочете спробувати ARM - купуйте qualcomm/raspberry pi.
Хочете приєднатись до секти яблука, до абсолютно закритої екосистеми, не неможливо запустити linux/windows - нехай щастить

[Ekz0rcyst]

dext
У вас якесь упереджене ставлення до яблучної продукції. Звичайно я ТС-а в його "тезисах" ніфіга не підтримую, бо явно прослідковується видавання бажаного за дійсне, але і ваші ось це явно упереджене:

Хочете приєднатись до секти яблука, до абсолютно закритої екосистеми, не неможливо запустити linux/windows - нехай щастить

Ви так пишете ніби Mac-и на M чипах не варті уваги взагалі, а це не так, геть не так.
Від себе можу додатии мало що але по власному досвіду Mac-и на M-чипах відрізняються дуже пристойною автономністю, звичайно не у всих кейсах використання, але в більшості типових завдань, ноути на Intel/AMD поруч не стоять, взагалі.