Джонка, вземи помисли за силна интеграция с популярните Chat ботове, представи си да имаш бутон "замести ме" и бота автоматично да ти получава отговоите и да плямпа вместо теб. Ще е нещо авангардно и със сигурност ще покаже асемблера като модерен веб език не като некъв мухъл за драйвери
waldorf
Създадено на 01.03.2023, видяно: 643 пъти. #86372
Че за какво ти е бот - във всеки форум има поне по един форумен идиот който бълва идиотизми на килограм, за какво ти е повече от това?
Джонка, вземи помисли за силна интеграция с популярните Chat ботове, представи си да имаш бутон "замести ме" и бота автоматично да ти получава отговоите и да плямпа вместо теб. Ще е нещо авангардно и със сигурност ще покаже асемблера като модерен веб език не като некъв мухъл за драйвери
За съжаление, искат пари. Да не говорим, че аз съм по принцип против концепцията SaaS. Но може да взема да напиша собствен, на асемблер. Обаче, трябва да завърша текущият часпром, че нещо много се провлачи...
Джонка, вземи помисли за силна интеграция с популярните Chat ботове, представи си да имаш бутон "замести ме" и бота автоматично да ти получава отговоите и да плямпа вместо теб. Ще е нещо авангардно и със сигурност ще покаже асемблера като модерен веб език не като некъв мухъл за драйвери
За съжаление, искат пари. Да не говорим, че аз съм по принцип против концепцията SaaS. Но може да взема да напиша собствен, на асемблер. Обаче, трябва да завърша текущият часпром, че нещо много се провлачи...
Защо само на асемблер, дай да покажем на света че към асемблера може да се закачат и други езици, е например ако направиш порт за .net може да се включа
Защо само на асемблер, дай да покажем на света че към асемблера може да се закачат и други езици, е например ако направиш порт за .net може да се включа
Ами не, на .нет ще трябва да се изпълнява на клъстър от поне 1000 ядра, за да има въобще някаква производителност... А на асемблер, даже старият ми нетбук ще работи горе-долу добре. Все пак ИИ на нетбук е значително по-весело от ИИ на клъстър...
Защо само на асемблер, дай да покажем на света че към асемблера може да се закачат и други езици, е например ако направиш порт за .net може да се включа
Ами не, на .нет ще трябва да се изпълнява на клъстър от поне 1000 ядра, за да има въобще някаква производителност... А на асемблер, даже старият ми нетбук ще работи горе-долу добре. Все пак ИИ на нетбук е значително по-весело от ИИ на клъстър...
Приказваш глупости но да кажем че си слабо ограмотен, е като начало хвърли един поглед тук: https://docs.nanoframework.net/#what-is-net-nanoframework
Реално пречката да пиша на асм или както се случва от време на време на delphi например е че за мен не са полезни в работата а отминаха ония дни в които да кодиш беше защото нямаше по-интересни неща.
Иначе темата за производителност е интересна и за твое голямо разочарование в уеба например не зависи кой знае колко от езика
waldorf
Създадено на 07.03.2023, видяно: 553 пъти. #86631
Ако си му свикнал на компилатора и го знаеш кога какъв код ще генерира разликата с това да пишеш на асемблер е огромна. Естествено, че и на двете можеш да направиш всичко, но на Ц ще е доста по бързо като време за разработка и ще може по лесно да го търкаляш на различни архитектури докато чистия асемблер си е заключен до платформата за която си го правил и дотам.
Другото нещо което винаги е хубаво човек да го има в предвид е, че болшинството компютри чакат задклавиатурното устройство да направи нещо а не обратното т.е. няма кой знае какво значение колко по ефективно ще правиш нищо. Там където има значение нещата да се свършат бързо си струва да се пише за бързина другото е излишно прахосване на скъпото време на програмиста.
Ако си му свикнал на компилатора и го знаеш кога какъв код ще генерира разликата с това да пишеш на асемблер е огромна.
Тоест да обобщя – трябва да напишеш такъв код, че компилаторът да генерира инструкциите, които ти трябват. За това следва да знаеш кои са тия правилни инструкции. А ако ги знаеш, какъв е проблема да си ги напишеш ти???
Аз преминах изцяло на асемблер когато осъзнах, че постоянно гледам какво е нагенерирал компилатора и нагласям сорсовете докато стане така както ми харесва. Просто не ми харесват такива игрички.
Другото нещо което винаги е хубаво човек да го има в предвид е, че болшинството компютри чакат задклавиатурното устройство да направи нещо а не обратното
О! Тоя бисер го пропуснах. Това твърдение е просто лъжливо. В съвременният софтуер, потребителите постоянно чакат компютрите. Просто ти си свикнал да чакаш, приемаш го за нормално и не го забелязваш.
waldorf
Създадено на 07.03.2023, видяно: 533 пъти. #86659
Ако си му свикнал на компилатора и го знаеш кога какъв код ще генерира разликата с това да пишеш на асемблер е огромна.
Тоест да обобщя – трябва да напишеш такъв код, че компилаторът да генерира инструкциите, които ти трябват. За това следва да знаеш кои са тия правилни инструкции. А ако ги знаеш, какъв е проблема да си ги напишеш ти???
Аз преминах изцяло на асемблер когато осъзнах, че постоянно гледам какво е нагенерирал компилатора и нагласям сорсовете докато стане така както ми харесва. Просто не ми харесват такива игрички.
Когато знаеш компилатора какво прави не е задължително да означава да си правиш труда да му нагласял сорсовете. Това, че ти си решил да е така си е твой проблем. При мен такъв проблем няма. Отдавна съм разбрал, че местата които си заслужават да се оптимизират са много малко и на всички останали е губене на време да ги пишеш на асемблер. И като ми се изясни това спрях да пиша предимно на асемблер - вече над 20 години. Преди това съм писал много. Минали сме през едно и също но сме направили различни изводи в което няма нищо лошо или обидно. Ако всички правехме еднакъв избор щеше да е комунизъм - а както добре знаем комунизма е отвратително нечовешко нещо което прави всички еднакво нещастни.
waldorf
Създадено на 07.03.2023, видяно: 531 пъти. #86661
Другото нещо което винаги е хубаво човек да го има в предвид е, че болшинството компютри чакат задклавиатурното устройство да направи нещо а не обратното
О! Тоя бисер го пропуснах. Това твърдение е просто лъжливо. В съвременният софтуер, потребителите постоянно чакат компютрите. Просто ти си свикнал да чакаш, приемаш го за нормално и не го забелязваш.
Тука вадиш нещата от контекста. Прочети целия параграф и го осмисли. Не съм казал, че няма смисъл да се пише на асемблер. Казвам, че трябва да се прави там където трябва. Това къде трябва е прави разликата. За мен чакането да се натисне клавиш няма смисъл да се оптимизира. Обаче след като се натисне този клавиш спор няма, че нещата трябва да се свършват бързо. Обаче там повече зависи от голямото O в сложността на алгоритма отколкото колко ефективно си го разписал. Разбира се има и изключения.
Другото нещо което винаги е хубаво човек да го има в предвид е, че болшинството компютри чакат задклавиатурното устройство да направи нещо а не обратното
О! Тоя бисер го пропуснах. Това твърдение е просто лъжливо. В съвременният софтуер, потребителите постоянно чакат компютрите. Просто ти си свикнал да чакаш, приемаш го за нормално и не го забелязваш.
Тука вадиш нещата от контекста. Прочети целия параграф и го осмисли. Не съм казал, че няма смисъл да се пише на асемблер. Казвам, че трябва да се прави там където трябва. Това къде трябва е прави разликата. За мен чакането да се натисне клавиш няма смисъл да се оптимизира. Обаче след като се натисне този клавиш спор няма, че нещата трябва да се свършват бързо. Обаче там повече зависи от голямото O в сложността на алгоритма отколкото колко ефективно си го разписал. Разбира се има и изключения.
Чакането за натискане на клавиш въобще не трябва да го има. Трябва да се работи по събития.
И ако казваш за нещо, че е изключение, не е лошо да приведеш аргументи. Защото според мене, тия изключения, за които ти говориш се срещат постоянно и на всяка крачка. Така че никакви изключения не са.
waldorf
Създадено на 07.03.2023, видяно: 524 пъти. #86664
Другото нещо което винаги е хубаво човек да го има в предвид е, че болшинството компютри чакат задклавиатурното устройство да направи нещо а не обратното
О! Тоя бисер го пропуснах. Това твърдение е просто лъжливо. В съвременният софтуер, потребителите постоянно чакат компютрите. Просто ти си свикнал да чакаш, приемаш го за нормално и не го забелязваш.
Тука вадиш нещата от контекста. Прочети целия параграф и го осмисли. Не съм казал, че няма смисъл да се пише на асемблер. Казвам, че трябва да се прави там където трябва. Това къде трябва е прави разликата. За мен чакането да се натисне клавиш няма смисъл да се оптимизира. Обаче след като се натисне този клавиш спор няма, че нещата трябва да се свършват бързо. Обаче там повече зависи от голямото O в сложността на алгоритма отколкото колко ефективно си го разписал. Разбира се има и изключения.
Чакането за натискане на клавиш въобще не трябва да го има. Трябва да се работи по събития.
И ако казваш за нещо, че е изключение, не е лошо да приведеш аргументи. Защото според мене, тия изключения, за които ти говориш се срещат постоянно и на всяка крачка. Така че никакви изключения не са.
Заради това, че процесора работи много по бързо отколкото се прочитат данните от паметта (да не говорим за диска) се получава така, че и да си оптимизирал кода си до дупка той ще се изпълни също толкова бавно колкото и по малко оптимизиран от компилатора защото бавното място е другаде. Когато го нямаш този проблем тогава всеки цикъл си има значение и там добре оптимизирания код е за предпочитане. И дори и тогава има мета където не си струва да оптимизираш защото на повечето хора им е все едно дали ще чакат 0.1с или 0.2с т.е. макар да е двойно по бавно е пренебрежимо малко време. Случвало ми се е да оптимизирам нещо което в реални условия е спестявало по малко време отколкото ми е отнело на мен за оптимизация. Затова смятам, че човек трябва да си разходва времето внимателно за нещата които наистина си струват - освен ако не го прави за кеф. Тогава е важно да ти направи по голям кеф. Примерно как да изчислиш hex => ASCII с по малко инструкции и памет. Или как да преброиш алгоритмично колко бита са вдигнати. И двете се правят с нечетлив код който само посветени разбират. Колко човека мислиш ще го оценят? Знаеш ли само какъв душевен оргазъм имах като дебъгнах на времето как работи pkzip ... как възстановява hoffman tree само от броя битове на всеки символ в него, как като търси back reference за LZ алгоритъма не сравнява байт по байт ами е работи с хеш таблици и т.н. И това всичкото разписано на асемблер. Навремето така учехме занаята, днес света е друг. Апотеоз на неефективността. Свиквай.
Заради това, че процесора работи много по бързо отколкото се прочитат данните от паметта (да не говорим за диска) се получава така, че и да си оптимизирал кода си до дупка той ще се изпълни също толкова бавно колкото и по малко оптимизиран от компилатора защото бавното място е другаде.
Това изказване просто не е вярно.
защото на повечето хора им е все едно дали ще чакат 0.1с или 0.2с т.е. макар да е двойно по бавно е пренебрежимо малко време.
200мс се отличават от 100мс напълно отчетливо. 200мс закъснение се възприема като забавяне и дразни. За да оцениш времевите мащаби, на клавиатурата му 250мс е забавянето за авторепида, а скоростта на повторение е 50 символа в секунда или 20мс. И тия 20мс са интервал, който човек обработва спокойно и отчетливо.
Просто си напиши 2..3 прости примера със паузи и сам ще се убедиш.
Примерно как да изчислиш hex => ASCII с по малко инструкции и памет. Или как да преброиш алгоритмично колко бита са вдигнати. И двете се правят с нечетлив код който само посветени разбират. Колко човека мислиш ще го оценят? Знаеш ли само какъв душевен оргазъм имах като дебъгнах на времето как работи pkzip ... как възстановява hoffman tree само от броя битове на всеки символ в него, как като търси back reference за LZ алгоритъма не сравнява байт по байт ами е работи с хеш таблици и т.н. И това всичкото разписано на асемблер. Навремето така учехме занаята, днес света е друг. Апотеоз на неефективността. Свиквай.
Точно пък NumToStr съм писал именно оптимизирано за размер. И се получава много елегантен и четлив алгоритъм. А относно ZIP алгоритъма, той така е замислен и сегашните библиотеки именно така го правят. Аз съм писал разкомпресиране по RFC-то (с малко помощ от Марк Адлер на stackoverflow) и се получи отлично, компактно и четливо.
Rabin
Последно редактирано на 07.03.2023 от Rabin, видяно: 510 пъти. #86668
А сега де, кой админ си спами служебната тема, КОЙ!
Малко ми е трудно да се сетя!
waldorf
Създадено на 07.03.2023, видяно: 505 пъти. #86669
Заради това, че процесора работи много по бързо отколкото се прочитат данните от паметта (да не говорим за диска) се получава така, че и да си оптимизирал кода си до дупка той ще се изпълни също толкова бавно колкото и по малко оптимизиран от компилатора защото бавното място е другаде.
Това изказване просто не е вярно.
И кое не е вярното?
защото на повечето хора им е все едно дали ще чакат 0.1с или 0.2с т.е. макар да е двойно по бавно е пренебрежимо малко време.
200мс се отличават от 100мс напълно отчетливо. 200мс закъснение се възприема като забавяне и дразни. За да оцениш времевите мащаби, на клавиатурата му 250мс е забавянето за авторепида, а скоростта на повторение е 50 символа в секунда или 20мс. И тия 20мс са интервал, който човек обработва спокойно и отчетливо.
Просто си напиши 2..3 прости примера със паузи и сам ще се убедиш.
Имам да гоня бъг в момента, не ми се правят тестове на клавиатури. Пък и не се сещам къде repeat rate е 50cps ... айде до 20 иди доди ама повече от това ми се струва непрактично. Може и аз с годините да съм станал по ленив ама единствената причина да си забързвам клавиатурата беше преди 30 години като мачках наред колегите на дуум2. За програмиране не ми е трябвало да имам бърза клавиатура. А откак ползвам vim пък съвсем - цъкам си мързеливата и хич не ми дреме.
Примерно как да изчислиш hex => ASCII с по малко инструкции и памет. Или как да преброиш алгоритмично колко бита са вдигнати. И двете се правят с нечетлив код който само посветени разбират. Колко човека мислиш ще го оценят? Знаеш ли само какъв душевен оргазъм имах като дебъгнах на времето как работи pkzip ... как възстановява hoffman tree само от броя битове на всеки символ в него, как като търси back reference за LZ алгоритъма не сравнява байт по байт ами е работи с хеш таблици и т.н. И това всичкото разписано на асемблер. Навремето така учехме занаята, днес света е друг. Апотеоз на неефективността. Свиквай.
Точно пък NumToStr съм писал именно оптимизирано за размер. И се получава много елегантен и четлив алгоритъм. А относно ZIP алгоритъма, той така е замислен и сегашните библиотеки именно така го правят. Аз съм писал разкомпресиране по RFC-то (с малко помощ от Марк Адлер на stackoverflow) и се получи отлично, компактно и четливо.
Евала, ти поне можеш да разбереш какъв кеф ми беше преди 30 години като го разбрах това само с дебъгване без някой да ми помага и без rfc да обяснява алгоритъма. Естествено после си писах собствени компресори и декомпресори. Даже си бях направил една защита за .еxe файлове която започваше с iret т.е. бях си подготвил в стега адрес за връщане където трябва и забрана на прекъсвания, постъпково трасиране и т.н. После включвах трасирането и на всяка изпълнена инструкция разменях адреса за връщане в стека с един от регистрите (май BP) т.е. инструкциите не следваха една след друга а бяха като спагети и преходите можеше да се правят и с зареждане на този регистър с каквото ми трябва - иди го дебъгвай ако си нямаш работа. И после ми се скапа диска и всичко отиде по дяволите ...
waldorf
Създадено на 07.03.2023, видяно: 504 пъти. #86670
Процедурите ти за работа със стрингове не са много оптимални. Не, че не работят ама примерно при сравнението на стрингове като им изчислиш първо дължините вече си ги прочел за да намериш къде е им е терминиращия 0x00 т.е. като така и така ги четеш спокойно можеш да правиш и сравнение символ по символ.
Има един образ който много се заиграва с такива неща - Daniel Lemire ако не го знаеш хвърли едно око, има интересни статии за бързи алгоритми и цепене на цикли.
Джонката си цикли едни и същи глупости вече години наред, като основната глупост е че разглежда своя контекст и критерии като единствено правилни и най-важни, тоя проблем е психологичен и е тъпо да се спори на технологично ниво докато не се изчистят гнилите дъски в тавана.
waldorf
Създадено на 07.03.2023, видяно: 522 пъти. #86681
Джонката си цикли едни и същи глупости вече години наред, като основната глупост е че разглежда своя контекст и критерии като единствено правилни и най-важни, тоя проблем е психологичен и е тъпо да се спори на технологично ниво докато не се изчистят гнилите дъски в тавана.
Ако беше някой лаладжия как да е, но той успява да направи всичко каквото иска на асемблер което само по себе си, си е постижение заслужаващо адмирации. Обаче ако си беше останал да пише на Ц щеше да е изписал няколко пъти повече софтуер през това време. Ама едва ли щеше да му е такъв кеф, така че го разбирам добре. Ама това не пречи да го ръчкам от време на време от колегиална злоба 😁
T.e. не е по луд от средностатистическия луд тука.