Интересно ще бъда, ако компилаторът пише и туторияли в които обяснява на човешки език как оптимизира отделните конкретни програми.
На практика компютърните програми днес мачкат шахматистите, но не е изключено последните да са много по-слаби от шахматист въоръжен с подходяща компютъра програма от вид асистент с която шахматистът да е наясно как да използва. Просто защото програмите играят играта по едни съвсем различни правила от човека и симбиозата между двата начина би трябвало да е по-ефективна технология по принцип.
Последно редактирано на 07.09.2020 от johnfound, видяно: 1273 пъти.
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Много пробойни, основно идващи от грешната ти формулировка.
В т. 2 допускаш, че компилатора е написал по-добър код, а пък твърдението ти друго.
Не всеки може да дизасемблира, камо ли да напише по-добър код. Ако приемем, че има такъв мега голям разбирач, то може да не му стигне времето да го намери и напише тоя код, т.е. ще пукне преди да го сътвори.
Що да не може компютъра да си оптимизира решението? Може ли да заменим човека с маймуна в твърдението?
И други крайни случаи, но много трудно се пише от телефон с тая жълтата тема.
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Формалната логика определено не е за теб. И ти ли си учил "висша математика"?
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Формалната логика определено не е за теб. И ти ли си учил "висша математика"?
Последно редактирано на 07.09.2020 от |, видяно: 1255 пъти.
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Формалната логика определено не е за теб. И ти ли си учил "висша математика"?
Може, но доказателството ми е съвършено правилно.
Доказателството ти НЕ Е правилно.
Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)
Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)
Доказателството ми е правилно.
А за тези неща не ти отговарям, защото са несъществени детайли. Но ако толкова държиш – да, използвам ги, когато преценя, че трябва. Когато пишеш на асемблер, можеш да използваш всичко, каквото ти е необходимо.
Впрочем, ти не си бил в старият форум, но там няколко пъти доказвах и на практика, на съвсем реални програми, че никакъв компилатор не може да бие ръчно написан код.
Глупости на търкалета Ако човека е некадърен въобще няма гаранция че ще успее да използва дизасемблирания код, особено в по-дълга задача, да не говорим че има шанс да го смотае още повече. Дори обаче да стигне дотам че да използва кода на компилатора, то тогава е решил задачата за повече време и пак губи.
3 също е невярно по принцип защото компилаторите се пишат от хора и то много добру, и малко или много с течение на времето компилаторите и кодът им стават все по-добри, докато общата маса програмисти не поумнява.
Твърдението е разбито.
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)
Доказателството ми е правилно.
А за тези неща не ти отговарям, защото са несъществени детайли. Но ако толкова държиш – да, използвам ги, когато преценя, че трябва. Когато пишеш на асемблер, можеш да използваш всичко, каквото ти е необходимо.
Впрочем, ти не си бил в старият форум, но там няколко пъти доказвах и на практика, на съвсем реални програми, че никакъв компилатор не може да бие ръчно написан код.
Изобщо не са несъществени детайли, а неща които ЗНАЧИТЕЛНО подобряват производителността.
Я кажи колко често "преценяваш", че трябва да ги използваш. Колко пъти си използвал prefetching, например? :)
Можел да използва всичко, което му било необходимо... :)
С какви реални програми си показвал, че компилатор не може да бие ръчно написан код? Такива с 10 милиона реда на C++, или разни примерчета с по 10-20 реда?
Виж сега, мнооого по-умни хора от теб, знаещи асемблер много по-добре от теб са ги мислили тези неща като са измислили другите езици са програмиране. Кен Томпсън е написал първия Юникс на асемблер. Мислиш ли, че е по-тъп от теб като го е преписал на C? :)
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.
Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?
Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?
Планирано е. Има нужда от нормална релационна база данни, която да е удобна за използване от асемблер. Просто нямам още ясна представа за правилното решение.
Последно редактирано на 07.09.2020 от Rabin, видяно: 1222 пъти.
Жони, няколко пъти ти показах у казармения форум. Ако жунката не го е изтрил де. Трие на поразия, и едни 30 % от постовете ми не достигаха до вас.
Та пуснах ти съпоставки как php форум е значително по-бръз от твоя. А php е най-жалката бавнотия от всичко, което съм докосвал. Много, болезнено бавно спрямо java.
Ся продължаваме, как ще мигрираме тоя форум на друга платформа? ARM са процесори много различни от тия по РС - тата. Кво правим?
Аз нямам проблем с платформената независимост. Ти имаш!
Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?
Планирано е. Има нужда от нормална релационна база данни, която да е удобна за използване от асемблер. Просто нямам още ясна представа за правилното решение.
OK, като го направиш се обади. Да видим колко по-бърз ще е от стандартния. :)
Та, колко пъти досега си използвал prefetching? Loop unrolling?
Сигурен съм, че дори за нормална програма компилатора прави по-добре register allocation от теб. Разбира се, за разни смешки на 20 реда си много добър.
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.
Аз лично не съм съгласен с тая теза, но за целта на спора да приемем че е спорна. Самата дефиниция обаче за добър код НЕ включва само бързодействие и обем. Първо, една система е бавна колкото най-бавния компонент, в случая ти е базата данни. Т.е. колкото и да ти е бърз и перфектен кода една по-добра база ще направи по-добра система. В голяма система факторите за бързодействие пък вече зависят от много неща. После, времето когато отделни хора правеха големи продукти сами отмина, причините са ясни. За да е добър един код, той трябва:
- да може да се пише от голям кръг програмисти, като има взаимозаменяемост - т.е. едни да почнат, да се включат други, да се поддържа от трети, да се скалира от четвърти - например от друга фирма
- да има готови платформи които да улеснят и стандартизират работата в екип
- да има голям брой библиотеки и лесни механизми за интеграция
- да поддържа стандартни интеграции с други системи
- в някои случаи мултиплатформеност
и много други неща които няма смисъл да се изреждат. Та в общия случай, за да е добър един код той трябва да дава достатъчно (не най-добро) качество на най-добра цена.
Отделна тема е че писането на код е само един от етапите на производство и като такъв в голяма степен зависи от други неща.
Аз лично не съм съгласен с тая теза, но за целта на спора да приемем че е спорна. Самата дефиниция обаче за добър код НЕ включва само бързодействие и обем. Първо, една система е бавна колкото най-бавния компонент, в случая ти е базата данни. Т.е. колкото и да ти е бърз и перфектен кода една по-добра база ще направи по-добра система. В голяма система факторите за бързодействие пък вече зависят от много неща. После, времето когато отделни хора правеха големи продукти сами отмина, причините са ясни. За да е добър един код, той трябва:
- да може да се пише от голям кръг програмисти, като има взаимозаменяемост - т.е. едни да почнат, да се включат други, да се поддържа от трети, да се скалира от четвърти - например от друга фирма
- да има готови платформи които да улеснят и стандартизират работата в екип
- да има голям брой библиотеки и лесни механизми за интеграция
- да поддържа стандартни интеграции с други системи
- в някои случаи мултиплатформеност
и много други неща които няма смисъл да се изреждат. Та в общия случай, за да е добър един код той трябва да дава достатъчно (не най-добро) качество на най-добра цена.
Отделна тема е че писането на код е само един от етапите на производство и като такъв в голяма степен зависи от други неща.
Сега, ако говорим конкретно за AsmBB, то нещата не са точно така. Реално времето е приблизително наравно (плюс-минус) разпределено между заявките към базата данни и работата на темплейт рендера. Впрочем, SQLite е реално много силно оптимизиран код на чисто C – тоест, доближава се толкова до асемблер, колкото въобще е възможно за език от високо ниво.
Всички неща надолу в поста ти са реално въпрос на инструменти, организация и мениджмънт и почти не зависят от езика за програмиране. Тоест, когато нещата започнат да се пишат масово на асемблер, със сигурност и всички тези неща ще се появят.
Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.
Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.
И аз така мислим. Кода е от дев за дев. Иначе щехме да пишем на асемблер.
Така и така размихте поредната тема. Един софтуер е с добър перформънс, когато юзърите и тоя дето плаща на програмистите да си хранят голямото его и малките пишки го виждат да зарежда бързо (което е относително човешко понятие) дори и при голяма натовареност. Оттам насетне на какво и как ще го напишеш им е все тая. Та в тоя ред на мисли, не съм забелязъл този форум да е значително по-бърз от някой пхп базиран, а тук пишат една шепа хора. Даже напротив виждал съм как ми цикли с респонс от около 3-4 секунди просто да екстрактне всички теми на хоум страницата. Което го отдавам на базата данни, а не на асемблера.
Тоест, когато нещата започнат да се пишат масово на асемблер, със сигурност и всички тези неща ще се появят.
Нещата НИКОГА няма да се пишат пак на асемблер. Както вече казах някъде, дори в момента има поне 4 различни популярни ISA: x86, arm, ptx, и vega. Хайде да добавя и RISC-V да не са кръгло число.