johnfound | T.e. смяташ, че допълнителните регистри са безполезни? :)
Всъщност прекалено многото регистри е също толкова зле, колкото прекалено малкото регистри. Във всеки случай, да се пише на 64 битов асемблер заради повечето регистри е безсмислено. Вредите са повече от ползите.
Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)
| E, хайде сега да не се лъжем. Ти не гледаш собствен код на език от високо ниво, гледаш кода на други. :)
Безразлично ми е какво си въобразяваш за кода ми. (впрочем, от чий точно код гледам, че ми стана интересно?) Правилният код на асемблер много рядко съответства на някакъв добър код на език от високо ниво.
Обратно - знам за няколко проекта, които използват именно този подход, но резултатите рядко са добри - асемблерната програма се получава с 10..20% по-бърза от кода на C.
Докато при писане всичко направо на асемблер, често се получава двойна или тройна скорост на изпълнение.
| Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)
А ти спря ли да биеш жена си всяка вечер? Да или не!?
johnfound | Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)
А ти спря ли да биеш жена си всяка вечер? Да или не!?
Да, спрях. Та, защо твоят невероятно оптимизиран memory heap е по-бавен от jemalloc или този на libc? :)
Между друтото този малоумен въпрос показва, че си нямаш идея от формална логика. :) И двата отговора са ВЕРНИ, а не грешни.
| johnfound | Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)
А ти спря ли да биеш жена си всяка вечер? Да или не!?
Да, спрях. Та, защо твоят невероятно оптимизиран memory heap е по-бавен от jemalloc или този на libc? :)
А по-бавен ли е? Силно ме съмнява! Просто защото от съображения за лесна преносимост на кода - Windows версията използва heap функциите на WinAPI, Linux версията използва heap функциите на libc, a KolibriOS версията, да има написан heap, който обаче е много далече от понятието "невероятно оптимизиран", при това е и доста бъгав. 
А когато ми трябва наистина висока скорост на изпълнение, не използвам heap въобще.
| И двата отговора са ВЕРНИ, а не грешни.
Естествено, че и двата отговора са верни. Аз затова и зададох въпроса. А ти избра този отговор, който те компрометира по-малко. Щото все нещо трябваше да отговориш.
johnfound | johnfound | Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)
А ти спря ли да биеш жена си всяка вечер? Да или не!?
Да, спрях. Та, защо твоят невероятно оптимизиран memory heap е по-бавен от jemalloc или този на libc? :)
А по-бавен ли е? Силно ме съмнява! Просто защото от съображения за лесна преносимост на кода - Windows версията използва heap функциите на WinAPI, Linux версията използва heap функциите на libc, a KolibriOS версията, да има написан heap, който обаче е много далече от понятието "невероятно оптимизиран", при това е и доста бъгав.
А когато ми трябва наистина висока скорост на изпълнение, не използвам heap въобще.
Говоря за твоята имплементация, не за факта, че се налага да използваш стандартните (написани на C) защото твоята е бавна. :)
johnfound Естествено, че и двата отговора са верни. Аз затова и зададох въпроса. А ти избра този отговор, който те компрометира по-малко. Щото все нещо трябваше да отговориш.
Нито един от двата отговора не ме компрометира ИЗОБЩО. Което щеше да знаеш, ако беше учил формална логика. :)
ФМИст отново накара инжинерите от меитата да си преглътнат дипломите и еготата 😁. Дон Реба четеш ли?
Много интересно мерите пишоци 3 страници. Мен ме грабна 32 vs 64 бита и скорост. Понеже ми се налага да ползвам криптография, знаете ли, че SHA512 е около 50% по- бърз от SHA256 на 64 битови машини. Въпреки, че операциите са повече, в същото време се обработват 64-bit word-a.
ПС: Low level-а никога не ми е бил интересен, но неволя...
Courvoisier Много интересно мерите пишоци 3 страници. Мен ме грабна 32 vs 64 бита и скорост. Понеже ми се налага да ползвам криптография, знаете ли, че SHA512 е около 50% по- бърз от SHA256 на 64 битови машини. Въпреки, че операциите са повече, в същото време се обработват 64-bit word-a.
ПС: Low level-а никога не ми е бил интересен, но неволя...
Абе дори и на мене като на прост .нетаджия ми замириса тезата на другаря за надмощието на х32 над х64. Ако на нещо му потрябва повече от 3 гиг рам, ко прайм не знам...
Courvoisier Много интересно мерите пишоци 3 страници. Мен ме грабна 32 vs 64 бита и скорост. Понеже ми се налага да ползвам криптография, знаете ли, че SHA512 е около 50% по- бърз от SHA256 на 64 битови машини. Въпреки, че операциите са повече, в същото време се обработват 64-bit word-a.
ПС: Low level-а никога не ми е бил интересен, но неволя...
Това е интересно. Мерил ли си дали ША инструкциите са бързи? Ако не се лъжа почти всички процесори имат някакви варианти.
Унуфри Абе дори и на мене като на прост .нетаджия ми замириса тезата на другаря за надмощието на х32 над х64. Ако на нещо му потрябва повече от 3 гиг рам, ко прайм не знам...
Ще използва сегменти. :) Back to the ... past. :)
| Хехехе, смешник, аз определено разбирам от програмиране МНОГО ПОВЕЧЕ от теб. :) Освен многото повече опит, имам и ДИПЛОМА доказваща го. :)
И аз, за разлика от теб имам доказателство, че trie e по-бързо. Защото го тествах вчера. Код с trie на Go e 1.5х по-бърз от НхМ сравнение на C.
Много са ми забавни екземпляри като теб и bvbfan, "ама то така", "ама то иначе". Ама да си признае "ей, верно бе, не се бях сетил за това" е НЕВЪЗМОЖНО. Винаги сте прави, нали? :)
След това мнение, вече ясно, че си пълен хал-хабер 
bvbfan | Хехехе, смешник, аз определено разбирам от програмиране МНОГО ПОВЕЧЕ от теб. :) Освен многото повече опит, имам и ДИПЛОМА доказваща го. :)
И аз, за разлика от теб имам доказателство, че trie e по-бързо. Защото го тествах вчера. Код с trie на Go e 1.5х по-бърз от НхМ сравнение на C.
Много са ми забавни екземпляри като теб и bvbfan, "ама то така", "ама то иначе". Ама да си признае "ей, верно бе, не се бях сетил за това" е НЕВЪЗМОЖНО. Винаги сте прави, нали? :)
След това мнение, вече ясно, че си пълен хал-хабер
Виждам, че си много добър на празните приказки, но като се стигне до конкретика минаваш на "да, ама..." :) Жалка история. :)
Има доста писано по нета. Най-сбито е написано в stackexchange.
Е, колко по- бързо ще е зависи от инструкциите на процесора. Толкова low-level не разбирам.
На някои процесори може и 256 да е по- бърз. Intel SHA extensions
В частност, blake2 е по- бърз, но ми е nuget, докато sha-тата ги имам в cryptographic api-то.
Е сега ще пусна на Zen architecture
Ми, специално на моята AMD машина Windows Subsystem for Linux:
Обаче на сървърите сме с малко-годишни xeon, там е по- бърз...
nekav-negar@nekav-laptop:~$ openssl speed sha256 sha512
Doing sha256 for 3s on 16 size blocks: 33960717 sha256's in 2.98s
Doing sha256 for 3s on 64 size blocks: 24800970 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 12545519 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 4421464 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 621186 sha256's in 3.00s
Doing sha256 for 3s on 16384 size blocks: 314039 sha256's in 3.02s
Doing sha512 for 3s on 16 size blocks: 8987077 sha512's in 3.00s
Doing sha512 for 3s on 64 size blocks: 9149068 sha512's in 3.00s
Doing sha512 for 3s on 256 size blocks: 4079757 sha512's in 3.00s
Doing sha512 for 3s on 1024 size blocks: 1521684 sha512's in 3.00s
Doing sha512 for 3s on 8192 size blocks: 222925 sha512's in 3.00s
Doing sha512 for 3s on 16384 size blocks: 113457 sha512's in 3.00s
OpenSSL 1.1.1d 10 Sep 2019
built on: Mon Apr 20 20:23:01 2020 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-8Ocme2/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
sha256 182339.42k 529087.36k 1070550.95k 1509193.05k 1696251.90k 1703713.57k
sha512 47931.08k 195180.12k 348139.26k 519401.47k 608733.87k 619626.50k
На Intel 7-мо би трябвало да е по- бърз.
Ние нямаме дипломи, не сме писали prefix/redix trie, не знаем защо се прави, компактността, която имаш с база данни е много по-добра, управлението на паметта - много по-добро, бързодействието - добре регулирано. Щом не си наясно с тези неща, няма как да си "велик" програмист, нищо повече от поплювко.
bvbfan Ние нямаме дипломи, не сме писали prefix/redix trie, не знаем защо се прави, компактността, която имаш с база данни е много по-добра, управлението на паметта - много по-добро, бързодействието - добре регулирано. Щом не си наясно с тези неща, няма как да си "велик" програмист, нищо повече от поплювко.
И добре регулирано, разбира се, означава винаги бавно? :)
Да напомням ли, че "поплювкото" знае какъв компилатор използва ARM? :)
Не не си наясно, че може да бъде също толкова бързо, колкото и другото. Регулира се с кеша, който може да се бъде достатъчно голям, т.е. резултатите са в паметта. Но това ти не го знаеш и бълваш плява, която е напълно некомпетентна.
Courvoisier Има доста писано по нета. Най-сбито е написано в stackexchange.
Е, колко по- бързо ще е зависи от инструкциите на процесора. Толкова low-level не разбирам.
Имах предвид, че някои процесори имат ЕДНА инструкция, която смята ША. Например това:
https://en.wikipedia.org/wiki/Intel_SHA_extensions