0 1 2 3 4 ...15 16 17 18 19 ...32 33 34 35 36
Фикснат бъг и подобрено време. Имаше едно половинчато присвояване на xmm вместо ymm регистър. 43мс средно на низ. Общо 4321мс.
| File | Size | Uploaded | Downloads | MD5 hash |
|---|---|---|---|---|
| bench.7z | 3214566 bytes | 18.10.2020 | 149 | 294640931f8756e1b17c99c55f1e84c6 |
Видяхме че на асемблер може, но не е практично - това сега не можеш да го портнеш на арм. По-интересния въпрос е как да пишем на език от високо ниво, така че да позволим на компилатора сам да векторизира нещата. И доколко надеждна е авто-векторизацията.
Както бях писал в темата за развитието на езиците, това е най-интересния проблем който имат да решават създателите на програмни езици в момента: как да се представи и обедини паралелността предоставена от Симди и многото ядра.
Това е една от големите заблуди в програмирането.
А реално нещата изобщо не стоят толкова сложно. Алгоритъма който обсъждаме, въобще се състои от 12 инструкции във вътрешния цикъл и още примерно 20..30 във външния.
Значително по-лесно е да се пренапишат за друг процесор по смисъл (естествено, ако на другата архитектура има подобни инструкции), отколкото да се излъже компилатора на език от високо ниво да ги генерира автоматично за няколко архитектури.
При това, превода ще е от асемблер на асемблер – тоест езици със много подобен синтаксис и идеология.
А при писане на езици от високо ниво, подобни оптимизации се превръщат в пълно мъчение. Задачата "как да напишем на C такъв код, че да се генерират машинните инструкции, които ни трябват" в общият случай въобще няма решение. А даже когато се получава за дадена архитектура, то на другата архитектура се получава много далеч от оптималния код.
Освен това, като правило подобни упражнения обикновено водят до съвършено нечитаем код на езика от високо ниво – а как иначе, когато се опитваме косвено да напишем машинен код, на език от високо ниво.
Което пък води до сериозно нежелание да се оптимизира кода, докато ножа не опре до кокала. Някои даже въздигат подобно поведение до правила и закони: "Всичкото зло идва от ранната оптимизация!" и всякакви други безсмислени мантри.
(Впрочем, когато ножа опре до кокала, като правило вече е късно за оптимизации и всичко трябва да се започне от нулата.)
Докато ако го пишем на асемблер, даже много дълбоко оптимизиран код, има практически същата четимост като неоптимизиран код. Разбира се, повечето смятат, че тази "четимост" при асемблера винаги е лоша, но това е дълбоко заблуждение. Просто хората, които смятат, че асемблер е нечетим език, банално не го знаят и не пишат на него. За мене например също толкова нечетим е някакъв там Лисп или Ръст.
Така че, аз лично смятам, че играта "Как да напишем кода на език от високо ниво, че да генерира нужният ни машинен код" е реално безсмислена и ненужна. Ако знаем какъв код ни трябва, най-просто е да си го напишем директно. Другото е някакво извращение.
И разбира се тези фантазии работят ако имаш няколко хиляди реда код. Ако имаш няколко стотин милиона, и знаеш, че след 5 години трябва да работи на АРМ, сигурен ли си че ще успееш да го пренапишеш?
Абсолютно убеден съм, че няма човек, който да знае какво ще е след 5 години. Или ти вярваш в прорицатели?
Но проблема със асемблера изобщо е никакъв. Всички процесори работят +/- еднакво. Тоест, тривиална е задачата да се направи транспилатор, който да превежда от x86 на ARM и просто да преведе 99% от кода автоматично.
И тази задача, въобще е значително по-лесна от това да се напише компилатор на език от високо ниво, който да компилира за няколко архитектури.
Да не говорим, че тия няколко стотин милиона реда код въобще са просто измислени, защото няма самостоятелна свързана програма, разработвана от един колектив с такъв обем на кода. Тоест, при преминаване на друга архитектура, реално ще се наложи портиране на далеч по-малки обеми код от една група хора. А цялостният процес ще си тече в паралел.
What? Абсолютно всички хардуерни фирми знаят какво ще е след 5 години. Голяма част от потребителите им знаят какво ще е след 5 години.
Т.е. викаш, абсолютно тривиално е да транслираш асемблерски код написан за 8086 за новите процесори със Симди? Сигурен ли си?
Когато се минава на нова архитектура, кода написан на език от високо ниво се компилира. Това е.
А компилатора за новата архитектура, господ го спуска от небето на неделната църковна служба. А после пастора го размножава на флашки и ги праща на праведните програмисти.
Добре оптимизиран бакенд може да е няколко десетки до стотина хиляди реда. Обикновено се пише от фирмата, производител на архитектурата.
Същото важи и за всеки транспилатор, само че на порядък по-просто.
Т.е. ти твърдиш, че можеш да напишеш "транспилатор" (каквото и да означава това), който автоматично ще транслира код за 8086 да може да използва AVX?
Тази задача и компилаторите за езици от високо ниво не са я решили още за общият случай. А където са я решили за някакви частни случаи, изискват да се пише на езика от високо ниво по специален начин. Тоест не можеш просто така да прекомпилираш кода и да започне да използва AVX.
Тоест, реално точно в това никаква разлика между езиците от високо ниво и асемблер няма.
Попитах конкретен въпрос. Можеш ли или не можеш? Много добре знам какво могат компилаторите за езици от високо ниво.
А това което езиците от високо ниво предоставят е абстрактен модел, който в зависимот от изразителността си, може с различна лекота да се преведе до конкретна архитектура.
Конкретен отговор: Мога, за някои частни случаи. За останалите случаи ще се получи субоптимален код, който обаче пак ще работи правилно.
А ако добре знаеше какво могат компилаторите за езици от високо ниво, нямаше да има нужда да ти давам конкретен отговор, защото щеше да го знаеш. 
Така че, или кръстчето свали, или гащи си обуй.
T.e. "тривиалната задача" изобщо не е тривиална. А въпросът ти го зададох не защото не знам отговора, а за да ти демонстрирам, че дрънкаш глупости.
Е и? Ние, да ти напомня обсъждахме съвършено друга тема. Тоест, твоето възражение нищо особено не променя. Задачата да се прехвърли асемблерна програма на друга архитектура не е по-сложна от това да се прехвърли код на език от високо ниво.
Колкото и да спориш, излиза, че в най-лошият случай е със същата сложност.
В резултат, аргумента, че на езици от високо ниво се пише, заради по-лесната преносимост, си губи силата.
И реално, на езици от високо ниво се пише не заради по-лесната преносимост, а поради елементарна еволюционна традиция. Първите професионални програмисти са произлезли от математиците, а записа в езиците от високо ниво е близък до математическият начин на запис, просто защото произлиза от него.
Съответно, новите програмисти се обучават от програмисти, които са свикнали именно с такъв начин на изразяване и така и си върви.
Даже и когато възникват очевидни трудности с кодирането на оптимални алгоритми, вместо използването на по-подходящи езици, се преминава към по-сложни компилатори, които не стига, че използват алгоритми с експоненциална сложност, ами накрая генерират код доста далеч от оптималния.
Т.е. съгласен си, че асемблера няма никакви предимства? Good! :)
Кен Томпсън и Денис Ричи написват Юникс на Асемблер и по-късно го преписват на измисления от тях език C. Та, накъде е вървяла еволюцията?
На езици от високо ниво се пише по същаат причина, по която процесорите не се проектират с програма за електронни схеми и със резисторчета и транзисторчета.
Програмите на асемблер се получават на порядък по-оптимални от програмите на високо ниво. Ако не смяташ това за предимство, толкова по-зле за тебе. Аз смятам това за сериозно предимство.
Е, това, че Томпсън и Ричи пренаписват Юникс на написания от тях език, няма нищо странно. Ако сам не пишеш на езика, който си измислил, как можеш да очакваш, че другите ще пишат на него???
При това и Ричи и Томсън са математици, така че логично е да бутат системата към състояние, което им е привично. Да не говорим, че и двамата със сигурност са знаели и харесвали други езици от високо ниво (FORTRAN), които просто не са били предназначени за писане на операционни системи.
За сега такива неща се пишат на С със интринсици или асемблер за съответната архитектура. Иначе става неоптимално. Съответно трябва да знаеш червата на процесора как работи. В зависимост от инструкциите които ти дава съответният процесор, алгоритъма и структурите от данни могат да се променят коренно за да стане оптимално. А езиците от високо ниво не го могат това все още.
Сигурен съм, че ако направиш процесор започвайки от резистори, кондензатори и транзистори, можеш да го направиш на порядък по-оптимален от такъв проектиран както ги проектират сега. Знаеш ли защо не го правят?
А защо Томпсън и Ричи са измислили езика, гений? Нали уж на Асемблер било по-лесно и по-бързо. Очевидно двама от най-великите програмисти не са смятали сега. Вероятно не са знаели асемблер, горките. :)
0 1 2 3 4 ...15 16 17 18 19 ...32 33 34 35 36