<bgdev />free

Вход

Задача НЕ за интервю
7

0 1 2 3 4 ....15 16 17 18 19 ....32 33 34 35 36
#16161 (ツ) BIGBUGEX
Създадено на 18.10.2020, видяно: 1282 пъти.

Фикснат бъг и подобрено време. Имаше едно половинчато присвояване на xmm вместо ymm регистър. 43мс средно на низ. Общо 4321мс.

Attached files:
FileSizeUploadedDownloadsMD5 hash
bench.7z3214566 bytes18.10.2020103294640931f8756e1b17c99c55f1e84c6
#16167 (ツ) ФейкПрофил
Създадено на 18.10.2020, видяно: 1277 пъти.

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

#16169 (ツ) |
Създадено на 18.10.2020, видяно: 1275 пъти.
ФейкПрофил

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

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

#16188 (ツ) johnfound
Последно редактирано на 18.10.2020 от johnfound, видяно: 1267 пъти.
ФейкПрофил

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

Това е една от големите заблуди в програмирането.

А реално нещата изобщо не стоят толкова сложно. Алгоритъма който обсъждаме, въобще се състои от 12 инструкции във вътрешния цикъл и още примерно 20..30 във външния.

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

При това, превода ще е от асемблер на асемблер – тоест езици със много подобен синтаксис и идеология.

А при писане на езици от високо ниво, подобни оптимизации се превръщат в пълно мъчение. Задачата "как да напишем на C такъв код, че да се генерират машинните инструкции, които ни трябват" в общият случай въобще няма решение. А даже когато се получава за дадена архитектура, то на другата архитектура се получава много далеч от оптималния код.

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

Което пък води до сериозно нежелание да се оптимизира кода, докато ножа не опре до кокала. Някои даже въздигат подобно поведение до правила и закони: "Всичкото зло идва от ранната оптимизация!" и всякакви други безсмислени мантри.

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

Докато ако го пишем на асемблер, даже много дълбоко оптимизиран код, има практически същата четимост като неоптимизиран код. Разбира се, повечето смятат, че тази "четимост" при асемблера винаги е лоша, но това е дълбоко заблуждение. Просто хората, които смятат, че асемблер е нечетим език, банално не го знаят и не пишат на него. За мене например също толкова нечетим е някакъв там Лисп или Ръст.

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

#16190 (ツ) |
Създадено на 18.10.2020, видяно: 1261 пъти.
johnfound
ФейкПрофил

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

Това е една от големите заблуди в програмирането.

А реално нещата изобщо не стоят толкова сложно. Алгоритъма който обсъждаме, въобще се състои от 12 инструкции във вътрешния цикъл и още примерно 20..30 във външния.

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

При това, превода ще е от асемблер на асемблер – тоест езици със много подобен синтаксис и идеология.

А при писане на езици от високо ниво, подобни оптимизации се превръщат в пълно мъчение. Задачата "как да напишем на C такъв код, че да се генерират машинните инструкции, които ни трябват" в общият случай въобще няма решение. А даже когато се получава за дадена архитектура, то на другата архитектура се получава много далеч от оптималния код.

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

Което пък води до сериозно нежелание да се оптимизира кода, докато ножа не опре до кокала. Някои даже въздигат подобно поведение до правила и закони: "Всичкото зло идва от ранната оптимизация!" и всякакви други безсмислени мантри.

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

Докато ако го пишем на асемблер, даже много дълбоко оптимизиран код, има практически същата четимост като неоптимизиран код. Разбира се, повечето смятат, че тази "четимост" при асемблера винаги е лоша, но това е дълбоко заблуждение. Просто хората, които смятат, че асемблер е нечетим език, банално не го знаят и не пишат на него. За мене например също толкова нечетим е някакъв там Лисп или Ръст.

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

И разбира се тези фантазии работят ако имаш няколко хиляди реда код. Ако имаш няколко стотин милиона, и знаеш, че след 5 години трябва да работи на АРМ, сигурен ли си че ще успееш да го пренапишеш?

#16193 (ツ) johnfound
Последно редактирано на 18.10.2020 от johnfound, видяно: 1254 пъти.
|

И разбира се тези фантазии работят ако имаш няколко хиляди реда код. Ако имаш няколко стотин милиона, и знаеш, че след 5 години трябва да работи на АРМ, сигурен ли си че ще успееш да го пренапишеш?

Абсолютно убеден съм, че няма човек, който да знае какво ще е след 5 години. Или ти вярваш в прорицатели?

Но проблема със асемблера изобщо е никакъв. Всички процесори работят +/- еднакво. Тоест, тривиална е задачата да се направи транспилатор, който да превежда от x86 на ARM и просто да преведе 99% от кода автоматично.

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

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

#16195 (ツ) |
Създадено на 18.10.2020, видяно: 1250 пъти.
johnfound
|

И разбира се тези фантазии работят ако имаш няколко хиляди реда код. Ако имаш няколко стотин милиона, и знаеш, че след 5 години трябва да работи на АРМ, сигурен ли си че ще успееш да го пренапишеш?

Абсолютно убеден съм, че няма човек, който да знае какво ще е след 5 години. Или ти вярваш в прорицатели?

Но проблема със асемблера изобщо е никакъв. Всички процесори работят +/- еднакво. Тоест, тривиална е задачата да се направи транспилатор, който да превежда от x86 на ARM и просто да преведе 99% от кода автоматично.

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

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

What? Абсолютно всички хардуерни фирми знаят какво ще е след 5 години. Голяма част от потребителите им знаят какво ще е след 5 години.

Т.е. викаш, абсолютно тривиално е да транслираш асемблерски код написан за 8086 за новите процесори със Симди? Сигурен ли си?

Когато се минава на нова архитектура, кода написан на език от високо ниво се компилира. Това е.

#16197 (ツ) johnfound
Създадено на 18.10.2020, видяно: 1249 пъти.
|

Когато се минава на нова архитектура, кода написан на език от високо ниво се компилира. Това е.

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

#16198 (ツ) |
Последно редактирано на 18.10.2020 от |, видяно: 1247 пъти.
johnfound
|

Когато се минава на нова архитектура, кода написан на език от високо ниво се компилира. Това е.

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

Добре оптимизиран бакенд може да е няколко десетки до стотина хиляди реда. Обикновено се пише от фирмата, производител на архитектурата.

#16199 (ツ) johnfound
Създадено на 18.10.2020, видяно: 1243 пъти.
|

Добре оптимизиран бакенд може да е няколко десетки до стотина хиляди реда. Обикновено се пише от фирмата, производител на архитектурата.

Същото важи и за всеки транспилатор, само че на порядък по-просто.

#16200 (ツ) |
Създадено на 18.10.2020, видяно: 1239 пъти.
johnfound
|

Добре оптимизиран бакенд може да е няколко десетки до стотина хиляди реда. Обикновено се пише от фирмата, производител на архитектурата.

Същото важи и за всеки транспилатор, само че на порядък по-просто.

Т.е. ти твърдиш, че можеш да напишеш "транспилатор" (каквото и да означава това), който автоматично ще транслира код за 8086 да може да използва AVX?

#16201 (ツ) johnfound
Създадено на 18.10.2020, видяно: 1235 пъти.
|

Т.е. ти твърдиш, че можеш да напишеш "транспилатор" (каквото и да означава това), който автоматично ще транслира код за 8086 да може да използва AVX?

Тази задача и компилаторите за езици от високо ниво не са я решили още за общият случай. А където са я решили за някакви частни случаи, изискват да се пише на езика от високо ниво по специален начин. Тоест не можеш просто така да прекомпилираш кода и да започне да използва AVX.

Тоест, реално точно в това никаква разлика между езиците от високо ниво и асемблер няма.

#16202 (ツ) |
Последно редактирано на 18.10.2020 от |, видяно: 1232 пъти.
johnfound
|

Т.е. ти твърдиш, че можеш да напишеш "транспилатор" (каквото и да означава това), който автоматично ще транслира код за 8086 да може да използва AVX?

Тази задача и компилаторите за езици от високо ниво не са я решили още за общият случай. А където са я решили за някакви частни случаи, изискват да се пише на езика от високо ниво по специален начин. Тоест не можеш просто така да прекомпилираш кода и да започне да използва AVX.

Тоест, реално точно в това никаква разлика между езиците от високо ниво и асемблер няма.

Попитах конкретен въпрос. Можеш ли или не можеш? Много добре знам какво могат компилаторите за езици от високо ниво.

А това което езиците от високо ниво предоставят е абстрактен модел, който в зависимот от изразителността си, може с различна лекота да се преведе до конкретна архитектура.

#16203 (ツ) johnfound
Създадено на 18.10.2020, видяно: 1226 пъти.
|

Попитах конкретен въпрос. Можеш ли или не можеш? Много добре знам какво могат компилаторите за езици от високо ниво.

Конкретен отговор: Мога, за някои частни случаи. За останалите случаи ще се получи субоптимален код, който обаче пак ще работи правилно.

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

#16204 (ツ) |
Създадено на 18.10.2020, видяно: 1222 пъти.
johnfound
|

Попитах конкретен въпрос. Можеш ли или не можеш? Много добре знам какво могат компилаторите за езици от високо ниво.

Конкретен отговор: Мога, за някои частни случаи. За останалите случаи ще се получи субоптимален код, който обаче пак ще работи правилно.

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

T.e. "тривиалната задача" изобщо не е тривиална. А въпросът ти го зададох не защото не знам отговора, а за да ти демонстрирам, че дрънкаш глупости.

#16205 (ツ) johnfound
Създадено на 18.10.2020, видяно: 1219 пъти.
|

T.e. "тривиалната задача" изобщо не е тривиална. А въпросът ти го зададох не защото не знам отговора, а за да ти демонстрирам, че дрънкаш глупости.

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

Колкото и да спориш, излиза, че в най-лошият случай е със същата сложност.

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

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

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

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

#16206 (ツ) |
Последно редактирано на 18.10.2020 от |, видяно: 1215 пъти.
johnfound
|

T.e. "тривиалната задача" изобщо не е тривиална. А въпросът ти го зададох не защото не знам отговора, а за да ти демонстрирам, че дрънкаш глупости.

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

Колкото и да спориш, излиза, че в най-лошият случай е със същата сложност.

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

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

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

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

Т.е. съгласен си, че асемблера няма никакви предимства? Good! :)

Кен Томпсън и Денис Ричи написват Юникс на Асемблер и по-късно го преписват на измисления от тях език C. Та, накъде е вървяла еволюцията?

На езици от високо ниво се пише по същаат причина, по която процесорите не се проектират с програма за електронни схеми и със резисторчета и транзисторчета.

#16207 (ツ) johnfound
Последно редактирано на 18.10.2020 от johnfound, видяно: 1207 пъти.
|

Т.е. съгласен си, че асемблера няма никакви предимства? Good! :)

Кен Томпсън и Денис Ричи написват Юникс на Асемблер и по-късно го преписват на измисления от тях език C. Та, накъде е вървяла еволюцията?

На езици от високо ниво се пише по същаат причина, по която процесорите не се проектират с програма за електронни схеми и със резисторчета и транзисторчета.

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

Е, това, че Томпсън и Ричи пренаписват Юникс на написания от тях език, няма нищо странно. Ако сам не пишеш на езика, който си измислил, как можеш да очакваш, че другите ще пишат на него???

При това и Ричи и Томсън са математици, така че логично е да бутат системата към състояние, което им е привично. Да не говорим, че и двамата със сигурност са знаели и харесвали други езици от високо ниво (FORTRAN), които просто не са били предназначени за писане на операционни системи.

#16208 (ツ) BIGBUGEX
Създадено на 18.10.2020, видяно: 1202 пъти.
ФейкПрофил

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

За сега такива неща се пишат на С със интринсици или асемблер за съответната архитектура. Иначе става неоптимално. Съответно трябва да знаеш червата на процесора как работи. В зависимост от инструкциите които ти дава съответният процесор, алгоритъма и структурите от данни могат да се променят коренно за да стане оптимално. А езиците от високо ниво не го могат това все още.

#16213 (ツ) |
Създадено на 18.10.2020, видяно: 1193 пъти.
johnfound
|

Т.е. съгласен си, че асемблера няма никакви предимства? Good! :)

Кен Томпсън и Денис Ричи написват Юникс на Асемблер и по-късно го преписват на измисления от тях език C. Та, накъде е вървяла еволюцията?

На езици от високо ниво се пише по същаат причина, по която процесорите не се проектират с програма за електронни схеми и със резисторчета и транзисторчета.

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

Е, това, че Томпсън и Ричи пренаписват Юникс на написания от тях език, няма нищо странно. Ако сам не пишеш на езика, който си измислил, как можеш да очакваш, че другите ще пишат на него???

При това и Ричи и Томсън са математици, така че логично е да бутат системата към състояние, което им е привично. Да не говорим, че и двамата със сигурност са знаели и харесвали други езици от високо ниво (FORTRAN), които просто не са били предназначени за писане на операционни системи.

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

А защо Томпсън и Ричи са измислили езика, гений? Нали уж на Асемблер било по-лесно и по-бързо. Очевидно двама от най-великите програмисти не са смятали сега. Вероятно не са знаели асемблер, горките. :)

0 1 2 3 4 ....15 16 17 18 19 ....32 33 34 35 36

Задача НЕ за интервю
7

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE