<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


  johnfound  Създадено на 07.09.2020, видяно: 1168 пъти. #8674
code2

Ако не успее, то трябва ли дизасемблираният код да се счита за негов?

Естествено. Ние не обсъждаме пазарната икономика и интелектуална собственост, а теорема за отношенията на хора и компилатори.



  code2  Създадено на 07.09.2020, видяно: 1163 пъти. #8677

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

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



  johnfound  Последно редактирано на 07.09.2020 от johnfound, видяно: 1162 пъти. #8678
Golden Gega

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

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

Твърдението е разбито.

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

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

Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)



  40oz  Създадено на 07.09.2020, видяно: 1155 пъти. #8679
johnfound
40oz
johnfound

И даже повече, може формално да се докаже, че компилаторът по принцип може да създаде само по-лош или еквивалентен на код, създаден от човек.

Това ми е много интересно как се доказва

Елементарно се доказва.

1. Ако човек и компилатор решават една и съща задача и решението на човека е по-добро, то теоремата е доказана.

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

3. Компилаторът не може да анализира кода на човека от т.1

Теоремата е доказана.

Много пробойни, основно идващи от грешната ти формулировка.

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

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

Що да не може компютъра да си оптимизира решението? Може ли да заменим човека с маймуна в твърдението?

И други крайни случаи, но много трудно се пише от телефон с тая жълтата тема.



  |  Създадено на 07.09.2020, видяно: 1154 пъти. #8680
johnfound

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

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

Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)

Формалната логика определено не е за теб. И ти ли си учил "висша математика"?



  johnfound  Създадено на 07.09.2020, видяно: 1148 пъти. #8681
|
johnfound

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

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

Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)

Формалната логика определено не е за теб. И ти ли си учил "висша математика"?

Може, но доказателството ми е съвършено правилно. :-P



  |  Последно редактирано на 07.09.2020 от |, видяно: 1144 пъти. #8682
johnfound
|
johnfound

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

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

Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)

Формалната логика определено не е за теб. И ти ли си учил "висша математика"?

Може, но доказателството ми е съвършено правилно. :-P

Доказателството ти НЕ Е правилно.

Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)



  johnfound  Създадено на 07.09.2020, видяно: 1132 пъти. #8685
|

Доказателството ти НЕ Е правилно.

Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)

Доказателството ми е правилно.

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

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



  Golden Gega  Създадено на 07.09.2020, видяно: 1127 пъти. #8686
johnfound
Golden Gega

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

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

Твърдението е разбито.

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

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

Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)

Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.

Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.



  |  Създадено на 07.09.2020, видяно: 1123 пъти. #8687
johnfound
|

Доказателството ти НЕ Е правилно.

Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)

Доказателството ми е правилно.

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

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

Изобщо не са несъществени детайли, а неща които ЗНАЧИТЕЛНО подобряват производителността. Я кажи колко често "преценяваш", че трябва да ги използваш. Колко пъти си използвал prefetching, например? :)

Можел да използва всичко, което му било необходимо... :)

С какви реални програми си показвал, че компилатор не може да бие ръчно написан код? Такива с 10 милиона реда на C++, или разни примерчета с по 10-20 реда?

Виж сега, мнооого по-умни хора от теб, знаещи асемблер много по-добре от теб са ги мислили тези неща като са измислили другите езици са програмиране. Кен Томпсън е написал първия Юникс на асемблер. Мислиш ли, че е по-тъп от теб като го е преписал на C? :)



  johnfound  Създадено на 07.09.2020, видяно: 1121 пъти. #8688
Golden Gega

Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.

Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.

Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.



  |  Създадено на 07.09.2020, видяно: 1116 пъти. #8690
johnfound
Golden Gega

Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.

Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.

Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.

Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?



  johnfound  Създадено на 07.09.2020, видяно: 1112 пъти. #8692
|

Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?

Планирано е. Има нужда от нормална релационна база данни, която да е удобна за използване от асемблер. Просто нямам още ясна представа за правилното решение.



  Rabin  Последно редактирано на 07.09.2020 от Rabin, видяно: 1111 пъти. #8693

Жони, няколко пъти ти показах у казармения форум. Ако жунката не го е изтрил де. Трие на поразия, и едни 30 % от постовете ми не достигаха до вас.

Та пуснах ти съпоставки как php форум е значително по-бръз от твоя. А php е най-жалката бавнотия от всичко, което съм докосвал. Много, болезнено бавно спрямо java.

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

Аз нямам проблем с платформената независимост. Ти имаш!



  |  Създадено на 07.09.2020, видяно: 1106 пъти. #8694
johnfound
|

Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?

Планирано е. Има нужда от нормална релационна база данни, която да е удобна за използване от асемблер. Просто нямам още ясна представа за правилното решение.

OK, като го направиш се обади. Да видим колко по-бърз ще е от стандартния. :)

Та, колко пъти досега си използвал prefetching? Loop unrolling?

Сигурен съм, че дори за нормална програма компилатора прави по-добре register allocation от теб. Разбира се, за разни смешки на 20 реда си много добър.



  Golden Gega  Създадено на 07.09.2020, видяно: 1101 пъти. #8696
johnfound
Golden Gega

Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.

Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.

Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.

Аз лично не съм съгласен с тая теза, но за целта на спора да приемем че е спорна. Самата дефиниция обаче за добър код НЕ включва само бързодействие и обем. Първо, една система е бавна колкото най-бавния компонент, в случая ти е базата данни. Т.е. колкото и да ти е бърз и перфектен кода една по-добра база ще направи по-добра система. В голяма система факторите за бързодействие пък вече зависят от много неща. После, времето когато отделни хора правеха големи продукти сами отмина, причините са ясни. За да е добър един код, той трябва:

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

- да има готови платформи които да улеснят и стандартизират работата в екип

- да има голям брой библиотеки и лесни механизми за интеграция

- да поддържа стандартни интеграции с други системи

- в някои случаи мултиплатформеност

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

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



  johnfound  Създадено на 07.09.2020, видяно: 1091 пъти. #8698
Golden Gega

Аз лично не съм съгласен с тая теза, но за целта на спора да приемем че е спорна. Самата дефиниция обаче за добър код НЕ включва само бързодействие и обем. Първо, една система е бавна колкото най-бавния компонент, в случая ти е базата данни. Т.е. колкото и да ти е бърз и перфектен кода една по-добра база ще направи по-добра система. В голяма система факторите за бързодействие пък вече зависят от много неща. После, времето когато отделни хора правеха големи продукти сами отмина, причините са ясни. За да е добър един код, той трябва:

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

- да има готови платформи които да улеснят и стандартизират работата в екип

- да има голям брой библиотеки и лесни механизми за интеграция

- да поддържа стандартни интеграции с други системи

- в някои случаи мултиплатформеност

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

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

Сега, ако говорим конкретно за AsmBB, то нещата не са точно така. Реално времето е приблизително наравно (плюс-минус) разпределено между заявките към базата данни и работата на темплейт рендера. Впрочем, SQLite е реално много силно оптимизиран код на чисто C – тоест, доближава се толкова до асемблер, колкото въобще е възможно за език от високо ниво.

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



  Courvoisier  Създадено на 07.09.2020, видяно: 1089 пъти. #8699
|
Унуфри

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

Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.

И аз така мислим. Кода е от дев за дев. Иначе щехме да пишем на асемблер.



  Унуфри  Създадено на 07.09.2020, видяно: 1084 пъти. #8700

Така и така размихте поредната тема. Един софтуер е с добър перформънс, когато юзърите и тоя дето плаща на програмистите да си хранят голямото его и малките пишки го виждат да зарежда бързо (което е относително човешко понятие) дори и при голяма натовареност. Оттам насетне на какво и как ще го напишеш им е все тая. Та в тоя ред на мисли, не съм забелязъл този форум да е значително по-бърз от някой пхп базиран, а тук пишат една шепа хора. Даже напротив виждал съм как ми цикли с респонс от около 3-4 секунди просто да екстрактне всички теми на хоум страницата. Което го отдавам на базата данни, а не на асемблера.



  |  Създадено на 07.09.2020, видяно: 1084 пъти. #8701
johnfound

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

Нещата НИКОГА няма да се пишат пак на асемблер. Както вече казах някъде, дори в момента има поне 4 различни популярни ISA: x86, arm, ptx, и vega. Хайде да добавя и RISC-V да не са кръгло число.


0 1 2 3


Празни редове като разграничители

  



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