johnfound
Създадено на 07.09.2020, видяно: 1175 пъти. #8674
Естествено. Ние не обсъждаме пазарната икономика и интелектуална собственост, а теорема за отношенията на хора и компилатори.
code2
Създадено на 07.09.2020, видяно: 1170 пъти. #8677
Интересно ще бъда, ако компилаторът пише и туторияли в които обяснява на човешки език как оптимизира отделните конкретни програми.
На практика компютърните програми днес мачкат шахматистите, но не е изключено последните да са много по-слаби от шахматист въоръжен с подходяща компютъра програма от вид асистент с която шахматистът да е наясно как да използва. Просто защото програмите играят играта по едни съвсем различни правила от човека и симбиозата между двата начина би трябвало да е по-ефективна технология по принцип.
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
40oz
Създадено на 07.09.2020, видяно: 1162 пъти. #8679
Много пробойни, основно идващи от грешната ти формулировка.
В т. 2 допускаш, че компилатора е написал по-добър код, а пък твърдението ти друго.
Не всеки може да дизасемблира, камо ли да напише по-добър код. Ако приемем, че има такъв мега голям разбирач, то може да не му стигне времето да го намери и напише тоя код, т.е. ще пукне преди да го сътвори.
Що да не може компютъра да си оптимизира решението? Може ли да заменим човека с маймуна в твърдението?
И други крайни случаи, но много трудно се пише от телефон с тая жълтата тема.
|
Създадено на 07.09.2020, видяно: 1161 пъти. #8680
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Формалната логика определено не е за теб. И ти ли си учил "висша математика"?
johnfound
Създадено на 07.09.2020, видяно: 1155 пъти. #8681
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Формалната логика определено не е за теб. И ти ли си учил "висша математика"?
Може, но доказателството ми е съвършено правилно.
|
Последно редактирано на 07.09.2020 от |, видяно: 1151 пъти. #8682
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Формалната логика определено не е за теб. И ти ли си учил "висша математика"?
Може, но доказателството ми е съвършено правилно.
Доказателството ти НЕ Е правилно.
Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)
johnfound
Създадено на 07.09.2020, видяно: 1139 пъти. #8685
Доказателството ти НЕ Е правилно.
Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)
Доказателството ми е правилно.
А за тези неща не ти отговарям, защото са несъществени детайли. Но ако толкова държиш – да, използвам ги, когато преценя, че трябва. Когато пишеш на асемблер, можеш да използваш всичко, каквото ти е необходимо.
Впрочем, ти не си бил в старият форум, но там няколко пъти доказвах и на практика, на съвсем реални програми, че никакъв компилатор не може да бие ръчно написан код.
Глупости на търкалета Ако човека е некадърен въобще няма гаранция че ще успее да използва дизасемблирания код, особено в по-дълга задача, да не говорим че има шанс да го смотае още повече. Дори обаче да стигне дотам че да използва кода на компилатора, то тогава е решил задачата за повече време и пак губи.
3 също е невярно по принцип защото компилаторите се пишат от хора и то много добру, и малко или много с течение на времето компилаторите и кодът им стават все по-добри, докато общата маса програмисти не поумнява.
Твърдението е разбито.
Сега, аз нямах предвид тебе срещу компилатора. Там резултата е ясен.
Разглеждаме абстрактен компилатор, срещу абстрактен човек.
Тя формалната логика не е за всеки... Но хайде за тебе ще опростя малко: Представи си компилаторът, срещу авторът на същият този компилатор. (Доколкото разбирам, ти поне не смяташ, като другите програмисти, че компилаторите ги спуска Господ от небето)
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
|
Създадено на 07.09.2020, видяно: 1130 пъти. #8687
Доказателството ти НЕ Е правилно.
Между другото, виждам че нещо не отговаряш на въпросите ми за loop unrolling, prefetching и instruction reordering. Защо така? :)
Доказателството ми е правилно.
А за тези неща не ти отговарям, защото са несъществени детайли. Но ако толкова държиш – да, използвам ги, когато преценя, че трябва. Когато пишеш на асемблер, можеш да използваш всичко, каквото ти е необходимо.
Впрочем, ти не си бил в старият форум, но там няколко пъти доказвах и на практика, на съвсем реални програми, че никакъв компилатор не може да бие ръчно написан код.
Изобщо не са несъществени детайли, а неща които ЗНАЧИТЕЛНО подобряват производителността.
Я кажи колко често "преценяваш", че трябва да ги използваш. Колко пъти си използвал prefetching, например? :)
Можел да използва всичко, което му било необходимо... :)
С какви реални програми си показвал, че компилатор не може да бие ръчно написан код? Такива с 10 милиона реда на C++, или разни примерчета с по 10-20 реда?
Виж сега, мнооого по-умни хора от теб, знаещи асемблер много по-добре от теб са ги мислили тези неща като са измислили другите езици са програмиране. Кен Томпсън е написал първия Юникс на асемблер. Мислиш ли, че е по-тъп от теб като го е преписал на C? :)
johnfound
Създадено на 07.09.2020, видяно: 1128 пъти. #8688
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.
|
Създадено на 07.09.2020, видяно: 1123 пъти. #8690
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.
Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?
johnfound
Създадено на 07.09.2020, видяно: 1119 пъти. #8692
Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?
Планирано е. Има нужда от нормална релационна база данни, която да е удобна за използване от асемблер. Просто нямам още ясна представа за правилното решение.
Rabin
Последно редактирано на 07.09.2020 от Rabin, видяно: 1118 пъти. #8693
Жони, няколко пъти ти показах у казармения форум. Ако жунката не го е изтрил де. Трие на поразия, и едни 30 % от постовете ми не достигаха до вас.
Та пуснах ти съпоставки как php форум е значително по-бръз от твоя. А php е най-жалката бавнотия от всичко, което съм докосвал. Много, болезнено бавно спрямо java.
Ся продължаваме, как ще мигрираме тоя форум на друга платформа? ARM са процесори много различни от тия по РС - тата. Кво правим?
Аз нямам проблем с платформената независимост. Ти имаш!
|
Създадено на 07.09.2020, видяно: 1113 пъти. #8694
Кога ще препишеш sqlite на асемблер вместо да го използваш наготово?
Планирано е. Има нужда от нормална релационна база данни, която да е удобна за използване от асемблер. Просто нямам още ясна представа за правилното решение.
OK, като го направиш се обади. Да видим колко по-бърз ще е от стандартния. :)
Та, колко пъти досега си използвал prefetching? Loop unrolling?
Сигурен съм, че дори за нормална програма компилатора прави по-добре register allocation от теб. Разбира се, за разни смешки на 20 реда си много добър.
Гледа се ... средния случай, абстрактния компилатор по дефиниция (а аз съм писал компилатори за 65x02 доста асемблер за 80x86) се прави от много по-добър от средния програмист. Абстрактния програмист си е средно ниво, дори по камбанката на Гаус.
Автора на компилатора срещу самия компилатор е много частен случай, просто защото не всеки пише компилатори. Та формалната логика наистина не е за всеки.
Още отначало заявих, че това е чисто теоретично доказателство. Впрочем, среден програмист, също може да бие всеки компилатор. Стига да научи асемблер разбира се. Пак казвам – на средно ниво. Не е нужно да е гений.
Аз лично не съм съгласен с тая теза, но за целта на спора да приемем че е спорна. Самата дефиниция обаче за добър код НЕ включва само бързодействие и обем. Първо, една система е бавна колкото най-бавния компонент, в случая ти е базата данни. Т.е. колкото и да ти е бърз и перфектен кода една по-добра база ще направи по-добра система. В голяма система факторите за бързодействие пък вече зависят от много неща. После, времето когато отделни хора правеха големи продукти сами отмина, причините са ясни. За да е добър един код, той трябва:
- да може да се пише от голям кръг програмисти, като има взаимозаменяемост - т.е. едни да почнат, да се включат други, да се поддържа от трети, да се скалира от четвърти - например от друга фирма
- да има готови платформи които да улеснят и стандартизират работата в екип
- да има голям брой библиотеки и лесни механизми за интеграция
- да поддържа стандартни интеграции с други системи
- в някои случаи мултиплатформеност
и много други неща които няма смисъл да се изреждат. Та в общия случай, за да е добър един код той трябва да дава достатъчно (не най-добро) качество на най-добра цена.
Отделна тема е че писането на код е само един от етапите на производство и като такъв в голяма степен зависи от други неща.
johnfound
Създадено на 07.09.2020, видяно: 1098 пъти. #8698
Аз лично не съм съгласен с тая теза, но за целта на спора да приемем че е спорна. Самата дефиниция обаче за добър код НЕ включва само бързодействие и обем. Първо, една система е бавна колкото най-бавния компонент, в случая ти е базата данни. Т.е. колкото и да ти е бърз и перфектен кода една по-добра база ще направи по-добра система. В голяма система факторите за бързодействие пък вече зависят от много неща. После, времето когато отделни хора правеха големи продукти сами отмина, причините са ясни. За да е добър един код, той трябва:
- да може да се пише от голям кръг програмисти, като има взаимозаменяемост - т.е. едни да почнат, да се включат други, да се поддържа от трети, да се скалира от четвърти - например от друга фирма
- да има готови платформи които да улеснят и стандартизират работата в екип
- да има голям брой библиотеки и лесни механизми за интеграция
- да поддържа стандартни интеграции с други системи
- в някои случаи мултиплатформеност
и много други неща които няма смисъл да се изреждат. Та в общия случай, за да е добър един код той трябва да дава достатъчно (не най-добро) качество на най-добра цена.
Отделна тема е че писането на код е само един от етапите на производство и като такъв в голяма степен зависи от други неща.
Сега, ако говорим конкретно за AsmBB, то нещата не са точно така. Реално времето е приблизително наравно (плюс-минус) разпределено между заявките към базата данни и работата на темплейт рендера. Впрочем, SQLite е реално много силно оптимизиран код на чисто C – тоест, доближава се толкова до асемблер, колкото въобще е възможно за език от високо ниво.
Всички неща надолу в поста ти са реално въпрос на инструменти, организация и мениджмънт и почти не зависят от езика за програмиране. Тоест, когато нещата започнат да се пишат масово на асемблер, със сигурност и всички тези неща ще се появят.
Обичате ли да четете метод, в който рядко има по някой и нов празен ред за разграничител? Може би широкоекранните монитори доведоха до това хората да сбиват колкото се може повече за да не скролират и да си пазят девелъпърите пръстчетата за да бият чикии.
Кодът е проза и трябва да се спазват същите правила като когато се пише есе. Все пак кода не се пише за компютъра (иначе всички щяхме да пишем на асемблер), а за програмиста.
И аз така мислим. Кода е от дев за дев. Иначе щехме да пишем на асемблер.
Унуфри
Създадено на 07.09.2020, видяно: 1091 пъти. #8700
Така и така размихте поредната тема. Един софтуер е с добър перформънс, когато юзърите и тоя дето плаща на програмистите да си хранят голямото его и малките пишки го виждат да зарежда бързо (което е относително човешко понятие) дори и при голяма натовареност. Оттам насетне на какво и как ще го напишеш им е все тая. Та в тоя ред на мисли, не съм забелязъл този форум да е значително по-бърз от някой пхп базиран, а тук пишат една шепа хора. Даже напротив виждал съм как ми цикли с респонс от около 3-4 секунди просто да екстрактне всички теми на хоум страницата. Което го отдавам на базата данни, а не на асемблера.
|
Създадено на 07.09.2020, видяно: 1091 пъти. #8701
Тоест, когато нещата започнат да се пишат масово на асемблер, със сигурност и всички тези неща ще се появят.
Нещата НИКОГА няма да се пишат пак на асемблер. Както вече казах някъде, дори в момента има поне 4 различни популярни ISA: x86, arm, ptx, и vega. Хайде да добавя и RISC-V да не са кръгло число.