<bgdev />free

| |  


All tags 1will 2023 2code 3for 4food 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 fp fresh fun game github google gpl gpt gpt.3.5 gypsies 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


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

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

Attached files:
FileSizeUploadedDownloadsMD5 hash
bench.7z3214566 bytes18.10.2020148294640931f8756e1b17c99c55f1e84c6


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

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



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

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

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



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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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



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

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

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

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

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

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

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

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

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



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

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

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



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

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

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

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



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

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

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



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

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

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

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



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

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

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

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



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

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

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

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

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

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



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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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



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

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

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



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

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

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

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

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

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

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

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

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


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


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

  



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