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