<bgdev />free

Вход Регистрация

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

0 1 2 3
#8674 (ツ) johnfound
Създадено на 07.09.2020, видяно: 1036 пъти.
code2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0 1 2 3

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

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE