Чи архітектури процесора налаштовані на процедурний час?

Чи можуть бути внесені зміни в процесори, щоб зробити їх ефективнішими для одночасних циклів виконання, таких як Rust? Наприклад, чи є зміни у впровадженні передбачення гілок чи розмірах кешу, які допоможуть одночасно виконуватись?

У мене складається враження, що поточні конструкції процесора можуть бути оптимізовані більше для процедурних процесів, таких як C. Якби ми замість цього збиралися оптимізувати для одночасного виконання, як би виглядали процесори по-різному?

Для прогнозування, галузеве прогнозування було здійснено на основі узагальнень, проведених у наукових роботах, що аналізують процедурні кодекси. Мені цікаво, чи абстракція одночасності додасть значного робочого періоду часу виконання, що негативно вплине на існуючі алгоритми прогнозування галузей. Наприклад, передбачення в циклі for for - це одне, але коли ціль гілки - це завжди якась нова частина пам'яті (графіка, текст тощо), вона завжди буде пропускати кеш, і ніколи не буде гілки історія для цього - тому що жоден її ще не торкнувся.

Це, мабуть, дурне питання, оскільки вміст, хоча він завжди може бути в оперативній пам'яті, буде розгалужений на порядок менший, ніж він буде використаний (як тільки він буде завантажений у кеш) ... але все ж, там має бути спостережуваною часовою межею для контекстів, що зберігаються в кеші та передбачувачах гілок в процедурний час виконання, що буде виявлятися як межа абстракції в більш паралелізованому середовищі. Тож мені цікаво ... Чи дотримувалися ці межі? Чи аналізували це якісь дослідницькі роботи?

Чи архітектури процесора упереджені до процесуального коду над паралельним кодом; чи сучасні процесори достатньо загального призначення, щоб не страждала високомовна мова?

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

Дуже тривалий час цільовою мовою для більшості архітектур була мова "С". Це відображає скромні вимоги до цієї апаратури та те, що вона стала майже універсальною мовою програмування систем (Вибачте, Руст і Го, вам належить довгий шлях, щоб перемогти С).

Наслідком цього, здається, є те, що нові мови часто визначаються з точки зору їх еквівалентної семантики С тільки для того, щоб уникнути необхідності процесорних засобів, які, можливо, відсутні на сучасних комп'ютерах.

Окупність процесора, який добре відповідає сучасним компіляторам, полягає в тому, що код із цих компіляторів працює добре, і процесор має принаймні шанс бути конкурентоспроможним. Вартість відмови тут прирікає процесор, перш ніж він може почати роботу. Лише два приклади негативу включають iAPX-432 та Itanium, обидва від Intel. У обох були дуже погані стосунки зі своїми компіляторами (Ada та C відповідно), коли збій продуктів перетворювався на гру винних між кремнієм та програмним забезпеченням.

Без сумніву, так.

Зокрема, модель зв'язку, що має на увазі C99, є спільною пам'яттю. Більш досконалі паралельні мови мають більш багаті моделі зв'язку, такі як канали передачі повідомлень (як у Rust).

Сучасні архітектури процесора мають чітку апаратну підтримку спільної пам'яті. Зокрема, протоколи когерентності кеш-пам'яті, такі як MESI, реалізовані у фактичних воротах і провідниках. Немає реальної підтримки для передачі повідомлень між процесами, навіть якщо ідея передачі повідомлень не чужа процесорам. Сучасні шини PCI-e навіть емулюють спільну пам'ять за допомогою передачі повідомлень, тоді як процесори процесора повинні емулювати передачу повідомлень за допомогою спільної пам'яті!