|
Създадено на 18.10.2020, видяно: 1663 пъти. #16214
Да, няма идеален език и няма език, който е идеален за всички случаи. Само фанатици като Иванушка могат да твърдят подобно нещо.
|
Създадено на 18.10.2020, видяно: 1660 пъти. #16218
Програмите на асемблер се получават на порядък по-оптимални от програмите на високо ниво. Ако не смяташ това за предимство, толкова по-зле за тебе. Аз смятам това за сериозно предимство.
Между другото, какво ти е обяснението, че вместо да пишеш на асемблер, използваш език от високо ниво за достъп до данните на форума (SQL)? :)
johnfound
Създадено на 18.10.2020, видяно: 1653 пъти. #16223
Сигурен съм, че ако направиш процесор започвайки от резистори, кондензатори и транзистори, можеш да го направиш на порядък по-оптимален от такъв проектиран както ги проектират сега. Знаеш ли защо не го правят?
А сигурен ли си, че не ги? Във всеки случай, сега проектирането се прави на базата на наработки, които са оптимизирани именно на такова ниво.
Пък и напоследък се наблюдава именно такава детайлизация на проработките - нови топологии на елементите (FinFET например) и т.н. Просто защото технологията е толкова на границата, че без дълбоки оптимизации на ниско ниво никакъв прогрес няма как да има по принцип.
А защо Томпсън и Ричи са измислили езика, гений? Нали уж на Асемблер било по-лесно и по-бързо. Очевидно двама от най-великите програмисти не са смятали сега. Вероятно не са знаели асемблер, горките. :)
Вече ти го обясних, ама кой да чете. Елементарно, езиците от високо ниво и за двамата са далеч по-привични и близки.
Така са ги научили в университета. Научили са ги на някакъв там Фортран-4, и са им обяснили, че бъдещето е в езиците от високо ниво. Защото са по-привични за математиците и защото така и така производителността на хардуера се удвоява на всеки 18 месеца, така че загубата на производителност се компенсира още докато пишеш програмата.
Друг е въпросът, че времето, когато производителността се удвояваше всеки 18 месеца приключи. Окончателно и безвъзвратно. Експоненциален прогрес в компютрите повече никога няма да има. Ще има бавен линеен прогрес. И недостатъците на езиците от високо ниво все повече и повече ще пречат на развитието на софтуера.
Вярно, пренаписването на асемблер (което гарантирано ще се случи) не спасява съвсем положението. Но задел за още поне 3 итерации на удвоявания на скоростта на програмите все още има. А може би дори и 5.
gat3way
Създадено на 18.10.2020, видяно: 1650 пъти. #16224
Видяхме че на асемблер може, но не е практично - това сега не можеш да го портнеш на арм. По-интересния въпрос е как да пишем на език от високо ниво, така че да позволим на компилатора сам да векторизира нещата. И доколко надеждна е авто-векторизацията.
Никак. Няма компилатор дето да се оправя като хората с тея неща. Затва и има разни intrinsics за да се оправяш сам, което в крайна сметка не е толкова лоша идея.
|
Последно редактирано на 18.10.2020 от |, видяно: 1647 пъти. #16225
Сигурен съм, че ако направиш процесор започвайки от резистори, кондензатори и транзистори, можеш да го направиш на порядък по-оптимален от такъв проектиран както ги проектират сега. Знаеш ли защо не го правят?
А сигурен ли си, че не ги? Във всеки случай, сега проектирането се прави на базата на наработки, които са оптимизирани именно на такова ниво.
Сигурен съм.
Пък и напоследък се наблюдава именно такава детайлизация на проработките - нови топологии на елементите (FinFET например) и т.н. Просто защото технологията е толкова на границата, че без дълбоки оптимизации на ниско ниво никакъв прогрес няма как да има по принцип.
Това пък какво общо има с това как се проектират процесорите?
А защо Томпсън и Ричи са измислили езика, гений? Нали уж на Асемблер било по-лесно и по-бързо. Очевидно двама от най-великите програмисти не са смятали сега. Вероятно не са знаели асемблер, горките. :)
Вече ти го обясних, ама кой да чете. Елементарно, езиците от високо ниво и за двамата са далеч по-привични и близки.
За ВСИЧКИ хора езиците от високо ниво са по-привични и близки. Затова и съществуват.
Та, защо използваш SQL вместо да пишеш на асемблер? :)
|
Създадено на 18.10.2020, видяно: 1644 пъти. #16227
Видяхме че на асемблер може, но не е практично - това сега не можеш да го портнеш на арм. По-интересния въпрос е как да пишем на език от високо ниво, така че да позволим на компилатора сам да векторизира нещата. И доколко надеждна е авто-векторизацията.
Никак. Няма компилатор дето да се оправя като хората с тея неща. Затва и има разни intrinsics за да се оправяш сам, което в крайна сметка не е толкова лоша идея.
Според мен има надежда това да се оправи. Компютрите може да са тъпи, но са доста по-бързи от хората. :)
johnfound
Създадено на 18.10.2020, видяно: 1638 пъти. #16231
За ВСИЧКИ хора езиците от високо ниво са по-привични и близки. Затова и съществуват.
Та, защо използваш SQL вместо да пишеш на асемблер? :)
Ами не, далеч не за всички хора езиците от високо ниво са по-привични. Например изразите, които се използват в практически всички езици от високо ниво са част от езика на математиката, а ако не греша, математиката и нейният специфичен език се изучават дълго и упорито и в началното училище и в средното и в университета, а след това благополучно се забравят от 90% от хората (и то от образовани хора) и на 30 години почти никой не може да реши квадратно уравнение ей така на прима виста.
Докато асемблера се занимава именно с деконструкция на сложни алгоритми и описанието им стъпка по стъпка - процес близък до всеки човек. Достатъчно е да погледнеш как се кодират например готварските рецепти, или въобще всяка област в която математиката не е навлязла достатъчно дълбоко. Всяка готварска рецепта е записана буквално на асемблер. Само че не за асемблер, а за готвач.
Даже повече, ако помолиш някой да ти обясни някакъв алгоритъм с думи, то той ще използва именно асемблерен тип указания - стъпка по стъпка. Даже и това да е съвършено математически тип алгоритъм, който свободно се изразява с формули.
|
Последно редактирано на 18.10.2020 от |, видяно: 1635 пъти. #16232
За ВСИЧКИ хора езиците от високо ниво са по-привични и близки. Затова и съществуват.
Та, защо използваш SQL вместо да пишеш на асемблер? :)
Ами не, далеч не за всички хора езиците от високо ниво са по-привични. Например изразите, които се използват в практически всички езици от високо ниво са част от езика на математиката, а ако не греша, математиката и нейният специфичен език се изучават дълго и упорито и в началното училище и в средното и в университета, а след това благополучно се забравят от 90% от хората (и то от образовани хора) и на 30 години почти никой не може да реши квадратно уравнение ей така на прима виста.
Докато асемблера се занимава именно с деконструкция на сложни алгоритми и описанието им стъпка по стъпка - процес близък до всеки човек. Достатъчно е да погледнеш как се кодират например готварските рецепти, или въобще всяка област в която математиката не е навлязла достатъчно дълбоко. Всяка готварска рецепта е записана буквално на асемблер. Само че не за асемблер, а за готвач.
Даже повече, ако помолиш някой да ти обясни някакъв алгоритъм с думи, то той ще използва именно асемблерен тип указания - стъпка по стъпка. Даже и това да е съвършено математически тип алгоритъм, който свободно се изразява с формули.
И ВСЕ ПАК, не ми отговаряш на въпроса защо използваш SQL. :)
(Останалото няма да го коментирам не защото е вярно, а за да получа отговор за SQL първо.)
johnfound
Създадено на 18.10.2020, видяно: 1627 пъти. #16236
И ВСЕ ПАК, не ми отговаряш на въпроса защо използваш SQL. :)
А, просто се отвлякох, че гледам една лекция на Дробышевский. Но имам чудесен отговор – просто защото не съществува асемблерен език за извличане на данни от релационни бази данни.
Но определено, такъв език си струва да се създаде и понякога мисля над темата. Живот и здраве, може и да ми хрумне нещо конструктивно.
Във всеки случай, той би трябвало да има определени преимущества пред SQL – например, оптималният код за конкретна заявка би трябвало да бъде далеч по-очевиден от този при SQL. Защото при SQL, всички оптимизации са чисто шаманство и надежда, че господ е създал конкретната RDBMS достатъчно съвършена.
|
Последно редактирано на 18.10.2020 от |, видяно: 1624 пъти. #16239
И ВСЕ ПАК, не ми отговаряш на въпроса защо използваш SQL. :)
А, просто се отвлякох, че гледам една лекция на Дробышевский. Но имам чудесен отговор – просто защото не съществува асемблерен език за извличане на данни от релационни бази данни.
Но определено, такъв език си струва да се създаде и понякога мисля над темата. Живот и здраве, може и да ми хрумне нещо конструктивно.
Във всеки случай, той би трябвало да има определени преимущества пред SQL – например, оптималният код за конкретна заявка би трябвало да бъде далеч по-очевиден от този при SQL. Защото при SQL, всички оптимизации са чисто шаманство и надежда, че господ е създал конкретната RDBMS достатъчно съвършена.
Можеш да извличаш данните с код на асемблер. Все пак, всеки език от високо ниво предоставя нещо, което е по-лесно от писането на асемблер. И това е причината те да съществуват.
Асемблерния език е лесен за процесора, езиците от високо ниво са (по)лесни за хората.
johnfound
Създадено на 18.10.2020, видяно: 1618 пъти. #16241
Асемблерния език е лесен за процесора, езиците от високо ниво са (по)лесни за хората.
Какви са тези лъжливи дихотомии? Ако едното е така, другото трябва да е обратно. Нищо подобно разбира се.
Процесорът изобщо си няма понятие от асемблерен език. Той изпълнява поредица от байтове. А асемблерният език е създаден именно за да е по-лесен за хората. Асемблерният език има нужда от компилация, за да се превърне в код, разбираем за процесора.
|
Създадено на 18.10.2020, видяно: 1616 пъти. #16244
Асемблерния език е лесен за процесора, езиците от високо ниво са (по)лесни за хората.
Какви са тези лъжливи дихотомии? Ако едното е така, другото трябва да е обратно. Нищо подобно разбира се.
Процесорът изобщо си няма понятие от асемблерен език. Той изпълнява поредица от байтове. А асемблерният език е създаден именно за да е по-лесен за хората. Асемблерният език има нужда от компилация, за да се превърне в код, разбираем за процесора.
Асемблерния език е текстово представяне на машинния код, или поне това, което производителите на процесорите искат да представят като машинен код.
А RDBMS и SQL са си чиста математика. Разбира се, ти това никога няма да го признаеш, защото напълно унищожава всичките ти аргументи за предимствата на асемблера.
BIGBUGEX
Създадено на 18.10.2020, видяно: 1615 пъти. #16245
Черта, хващай да учиш асемблера, не се обяснявай. Бил труден и не ставал за хора... Изядохме ви с парцалите както не ставал за хора.
|
Създадено на 18.10.2020, видяно: 1613 пъти. #16246
Черта, хващай да учиш асемблера, не се обяснявай. Бил труден и не ставал за хора... Изядохме ви с парцалите както не ставал за хора.
Знам асемблер, не съм идиот да го използвам. Последно писах на асемблер за една интересна архитектура на Интел, която май умря.
BIGBUGEX
Създадено на 18.10.2020, видяно: 1609 пъти. #16247
Итаниум?
|
Създадено на 18.10.2020, видяно: 1607 пъти. #16248
Итаниум?
Не. Май умря преди да я обявят официално. :)
BIGBUGEX
Създадено на 18.10.2020, видяно: 1604 пъти. #16249
Лараби?
|
Последно редактирано на 18.10.2020 от |, видяно: 1602 пъти. #16250
Лараби?
Не, Лараби евентуално стана KNL. Което ми напомня, че вероятно трябва да започна да чета повече за Xe.
BIGBUGEX
Създадено на 18.10.2020, видяно: 1598 пъти. #16253
i860?
|
Създадено на 18.10.2020, видяно: 1596 пъти. #16254
i860?
Нали ти казах, не е обявена публично, и може би никога няма да бъде.