<bgdev />free

| |  


All tags 2023 9may ai algorithm alpha amd american api argon2 arm asm asmbb assembler attachment awareness balgaria bay888 bcrypt bender beta bgdev-next bgdev-next.👍 big.data bitchnigga bitcoin bmw boi borg brexit bug bulgaria business c cad chat cloud computer-names console crossorigin deprivation desktop dna dotnet email eupl falling feature forum foundation fp fresh fun game github goats google gpl gpt gpt.3.5 gypsies happiness harvard hash improvement include investment it java javascript js kleta kleta.maqka.balg lambi language learning leftovers legend level levenshtein.dist libx license linkedlist linux ma mcafee mele microsoft minimag minimalism negro net nginx nigga not.a.bug oop paradigm parler patterns perception persuasion pipe play.station politics populi pornhub pow pro programming protonmail python reba rust sci-fi scripting seks seo server shell sleep smartbeauty soft-skills sqlite srabska sse starship sugerface syntax tablet tailwindcss telegram theme thug troll80lvl tutanota typescript uacme ui uk unix untermensch upload uptime usa utilities ux vb via viber virtual.reality vox vps vulnerable war wasm weapons-grade web windows word x86 xbox xss youtube zig ziglang Übermensch БОКЕБЪЛГАРИН БЪ БЪлгария Белезниците Били Били.Белезниците БялДонор Веган Виста Възраждане ГЛУПАК Гана Глиста ЕС Казарма Копейкин Мода.и.овча.мисъ НЕКАДЪРНИК НРБ ПО-ЗЛЕ.И.ОТ.РАБИ Подкасти Разни Румен СИК СКУМ СетенЧук Скум ТИР Туче Украйна Урсула Яначков авангард аз айфонджия алгоритми амбиции анархизъм антиваксъри армения аудио аутисти бази.данни бакъп без без.пръчове безпросвета бенчмарк биготи биомаса бира боклук борисов ботев брадва булшит бъг бъгове бял ваксина вандал век венерика викинги вицове вишу война вървежен гана ганорник гей гейщина германия герои гешев глупак говеда групировка гюбек данъкоплатец двойни.стандарти дедотия демокрация дизайн дисциплина добитък докери долар донори држава дришльо дрон ебане еврогейски.съюз езици експеримент електроника електроника.s2 емиграция ендпойнт енум ерген ергономия жалкар задача затоплизъм защита здраве златен злато игри идеали идиократ идиократи идиокрация идиот избори избори.рабин изкуство икономика имбецили имейл инвестиране инокулация инструмента интервю ипад искам.да.си.реда казах камшикодържач капитализъм карабах караница картечница кино клавиатура ковид19 колайдер колям.кур комари комплексар комунизъм консолидация конспирации космонавтика кофа кофит-19 краставица криптовалути курви кучелюбци лайно лаладжия лаптоп либерастия литература лоши.практики луд лъжеучени лъжец любов майни майтапи малоумници мафия мениджмънт месо местене метавселена метафизика механика мистика мисъл мода мода.овча.мисъл модерация морал мутра мутри наука национализъм не.it негър некадърник некадърници неон нидерландия овча овчи олигофрени организация офтопик парички партия педал пенджури пенсия пишока плюскане победа погромист поезия политика порно посредствен почивка празници прасе превод предалщина програмиране проект проста простотии против.правилата проф пръч пръч.дришльо пръчка психика психични.болести психология пустиняк путин путката путьо рабин рабин.е.шибан.пе работа радост разврат разни разработка расизъм резерват рейтинг реклама рекламен религия рест ризи ропче ропчета русия руски.език рутина самоковска сасипаха секира село селяндур сериали сериозно.програм сетен сеянин симулация скопяване скръм слушалки сортиране софия софтуер софтуни социализъм спектрометър спринтове сране стандарти стил стуйо стюи сушилня сцена съвет съм сън сървър сърничка таб ташаци телевизия тема територията терминология термояд технологии титли традиция тролинг тръмп туба туче тъпак тъпанари тъпня уиндоус украйна умнокрасивци фалит фантастика фашизъм фейк.акаунти физика филми форум форумни.проекти футбол хазарт хамали харабия хардуер хахаха хомофобия хостинг храна хумор цайко цайси целофан цензура цензурра циганин чалга чалгар чекии чернокраки честота чипове чнг чужбина чук шпация щайга юан яката яко ям 🔨 😂 🪓


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

  

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


  |  Създадено на 18.10.2020, видяно: 1649 пъти. #16214
BIGBUGEX
ФейкПрофил

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

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

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



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

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

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



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

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

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

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

|

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

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

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

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

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



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

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

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



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

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

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

Сигурен съм.

johnfound

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

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

johnfound
|

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

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

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

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



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

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

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

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



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

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

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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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



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

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

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

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

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

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



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

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



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

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

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



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

Итаниум?



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

Итаниум?

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



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

Лараби?



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

Лараби?

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



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

i860?



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

i860?

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


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


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

  



AsmBB v3.0 (check-in: 7544654b24928b93); SQLite v3.47.0 (check-in: 03a9703e27c44437);
©2016..2024 John Found; Licensed under EUPL; Powered by Assembly language Created with Fresh IDE