<bgdev />free

Вход Регистрация

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

0 1 2 3 4 ....15 16 17 18 19 ....32 33 34 35 36
#16214 (ツ) |
Създадено на 18.10.2020, видяно: 1425 пъти.
BIGBUGEX
ФейкПрофил

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

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

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

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

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

Между другото, какво ти е обяснението, че вместо да пишеш на асемблер, използваш език от високо ниво за достъп до данните на форума (SQL)? :)

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

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

А сигурен ли си, че не ги? Във всеки случай, сега проектирането се прави на базата на наработки, които са оптимизирани именно на такова ниво.

Пък и напоследък се наблюдава именно такава детайлизация на проработките - нови топологии на елементите (FinFET например) и т.н. Просто защото технологията е толкова на границата, че без дълбоки оптимизации на ниско ниво никакъв прогрес няма как да има по принцип.

|

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

Вече ти го обясних, ама кой да чете. Елементарно, езиците от високо ниво и за двамата са далеч по-привични и близки.

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

Друг е въпросът, че времето, когато производителността се удвояваше всеки 18 месеца приключи. Окончателно и безвъзвратно. Експоненциален прогрес в компютрите повече никога няма да има. Ще има бавен линеен прогрес. И недостатъците на езиците от високо ниво все повече и повече ще пречат на развитието на софтуера.

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

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

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

Никак. Няма компилатор дето да се оправя като хората с тея неща. Затва и има разни intrinsics за да се оправяш сам, което в крайна сметка не е толкова лоша идея.

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

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

А сигурен ли си, че не ги? Във всеки случай, сега проектирането се прави на базата на наработки, които са оптимизирани именно на такова ниво.

Сигурен съм.

johnfound

Пък и напоследък се наблюдава именно такава детайлизация на проработките - нови топологии на елементите (FinFET например) и т.н. Просто защото технологията е толкова на границата, че без дълбоки оптимизации на ниско ниво никакъв прогрес няма как да има по принцип.

Това пък какво общо има с това как се проектират процесорите?

johnfound
|

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

Вече ти го обясних, ама кой да чете. Елементарно, езиците от високо ниво и за двамата са далеч по-привични и близки.

За ВСИЧКИ хора езиците от високо ниво са по-привични и близки. Затова и съществуват.

Та, защо използваш SQL вместо да пишеш на асемблер? :)

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

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

Никак. Няма компилатор дето да се оправя като хората с тея неща. Затва и има разни intrinsics за да се оправяш сам, което в крайна сметка не е толкова лоша идея.

Според мен има надежда това да се оправи. Компютрите може да са тъпи, но са доста по-бързи от хората. :)

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

За ВСИЧКИ хора езиците от високо ниво са по-привични и близки. Затова и съществуват.

Та, защо използваш SQL вместо да пишеш на асемблер? :)

Ами не, далеч не за всички хора езиците от високо ниво са по-привични. Например изразите, които се използват в практически всички езици от високо ниво са част от езика на математиката, а ако не греша, математиката и нейният специфичен език се изучават дълго и упорито и в началното училище и в средното и в университета, а след това благополучно се забравят от 90% от хората (и то от образовани хора) и на 30 години почти никой не може да реши квадратно уравнение ей така на прима виста.

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

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

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

За ВСИЧКИ хора езиците от високо ниво са по-привични и близки. Затова и съществуват.

Та, защо използваш SQL вместо да пишеш на асемблер? :)

Ами не, далеч не за всички хора езиците от високо ниво са по-привични. Например изразите, които се използват в практически всички езици от високо ниво са част от езика на математиката, а ако не греша, математиката и нейният специфичен език се изучават дълго и упорито и в началното училище и в средното и в университета, а след това благополучно се забравят от 90% от хората (и то от образовани хора) и на 30 години почти никой не може да реши квадратно уравнение ей така на прима виста.

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

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

И ВСЕ ПАК, не ми отговаряш на въпроса защо използваш SQL. :)

(Останалото няма да го коментирам не защото е вярно, а за да получа отговор за SQL първо.)

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

И ВСЕ ПАК, не ми отговаряш на въпроса защо използваш SQL. :)

А, просто се отвлякох, че гледам една лекция на Дробышевский. Но имам чудесен отговор – просто защото не съществува асемблерен език за извличане на данни от релационни бази данни.

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

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

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

И ВСЕ ПАК, не ми отговаряш на въпроса защо използваш SQL. :)

А, просто се отвлякох, че гледам една лекция на Дробышевский. Но имам чудесен отговор – просто защото не съществува асемблерен език за извличане на данни от релационни бази данни.

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

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

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

Асемблерния език е лесен за процесора, езиците от високо ниво са (по)лесни за хората.

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

Асемблерния език е лесен за процесора, езиците от високо ниво са (по)лесни за хората.

Какви са тези лъжливи дихотомии? Ако едното е така, другото трябва да е обратно. Нищо подобно разбира се.

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

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

Асемблерния език е лесен за процесора, езиците от високо ниво са (по)лесни за хората.

Какви са тези лъжливи дихотомии? Ако едното е така, другото трябва да е обратно. Нищо подобно разбира се.

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

Асемблерния език е текстово представяне на машинния код, или поне това, което производителите на процесорите искат да представят като машинен код.

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

#16245 (ツ) BIGBUGEX
Създадено на 18.10.2020, видяно: 1377 пъти.

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

#16246 (ツ) |
Създадено на 18.10.2020, видяно: 1375 пъти.
BIGBUGEX

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

Знам асемблер, не съм идиот да го използвам. Последно писах на асемблер за една интересна архитектура на Интел, която май умря.

#16247 (ツ) BIGBUGEX
Създадено на 18.10.2020, видяно: 1371 пъти.

Итаниум?

#16248 (ツ) |
Създадено на 18.10.2020, видяно: 1369 пъти.
BIGBUGEX

Итаниум?

Не. Май умря преди да я обявят официално. :)

#16249 (ツ) BIGBUGEX
Създадено на 18.10.2020, видяно: 1366 пъти.

Лараби?

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

Лараби?

Не, Лараби евентуално стана KNL. Което ми напомня, че вероятно трябва да започна да чета повече за Xe.

#16253 (ツ) BIGBUGEX
Създадено на 18.10.2020, видяно: 1360 пъти.

i860?

#16254 (ツ) |
Създадено на 18.10.2020, видяно: 1358 пъти.
BIGBUGEX

i860?

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

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