<bgdev />free

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

Задача НЕ за интервю
7

0 1 2 3 4 5 6 7 8 9 ....20 21 22 23 24 ....32 33 34 35 36
#11458 (ツ) |
Създадено на 21.09.2020, видяно: 1465 пъти.
johnfound
|

T.e. смяташ, че допълнителните регистри са безполезни? :)

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

Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)

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

E, хайде сега да не се лъжем. Ти не гледаш собствен код на език от високо ниво, гледаш кода на други. :)

Безразлично ми е какво си въобразяваш за кода ми. (впрочем, от чий точно код гледам, че ми стана интересно?) Правилният код на асемблер много рядко съответства на някакъв добър код на език от високо ниво.

Обратно - знам за няколко проекта, които използват именно този подход, но резултатите рядко са добри - асемблерната програма се получава с 10..20% по-бърза от кода на C.

Докато при писане всичко направо на асемблер, често се получава двойна или тройна скорост на изпълнение.

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

Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)

А ти спря ли да биеш жена си всяка вечер? Да или не!?

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

Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)

А ти спря ли да биеш жена си всяка вечер? Да или не!?

Да, спрях. Та, защо твоят невероятно оптимизиран memory heap е по-бавен от jemalloc или този на libc? :)

Между друтото този малоумен въпрос показва, че си нямаш идея от формална логика. :) И двата отговора са ВЕРНИ, а не грешни.

#11462 (ツ) johnfound
Създадено на 21.09.2020, видяно: 1441 пъти.
|
johnfound
|

Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)

А ти спря ли да биеш жена си всяка вечер? Да или не!?

Да, спрях. Та, защо твоят невероятно оптимизиран memory heap е по-бавен от jemalloc или този на libc? :)

А по-бавен ли е? Силно ме съмнява! Просто защото от съображения за лесна преносимост на кода - Windows версията използва heap функциите на WinAPI, Linux версията използва heap функциите на libc, a KolibriOS версията, да има написан heap, който обаче е много далече от понятието "невероятно оптимизиран", при това е и доста бъгав. rofl

А когато ми трябва наистина висока скорост на изпълнение, не използвам heap въобще.

#11463 (ツ) johnfound
Създадено на 21.09.2020, видяно: 1438 пъти.
|

И двата отговора са ВЕРНИ, а не грешни.

Естествено, че и двата отговора са верни. Аз затова и зададох въпроса. А ти избра този отговор, който те компрометира по-малко. Щото все нещо трябваше да отговориш. rofl rofl rofl

#11464 (ツ) |
Създадено на 21.09.2020, видяно: 1436 пъти.
johnfound
|
johnfound
|

Aaanyway, защо твоят memory heap не е толкова бърз като jemalloc? :)

А ти спря ли да биеш жена си всяка вечер? Да или не!?

Да, спрях. Та, защо твоят невероятно оптимизиран memory heap е по-бавен от jemalloc или този на libc? :)

А по-бавен ли е? Силно ме съмнява! Просто защото от съображения за лесна преносимост на кода - Windows версията използва heap функциите на WinAPI, Linux версията използва heap функциите на libc, a KolibriOS версията, да има написан heap, който обаче е много далече от понятието "невероятно оптимизиран", при това е и доста бъгав. rofl

А когато ми трябва наистина висока скорост на изпълнение, не използвам heap въобще.

Говоря за твоята имплементация, не за факта, че се налага да използваш стандартните (написани на C) защото твоята е бавна. :)

#11465 (ツ) |
Създадено на 21.09.2020, видяно: 1435 пъти.
johnfound

Естествено, че и двата отговора са верни. Аз затова и зададох въпроса. А ти избра този отговор, който те компрометира по-малко. Щото все нещо трябваше да отговориш. rofl rofl rofl

Нито един от двата отговора не ме компрометира ИЗОБЩО. Което щеше да знаеш, ако беше учил формална логика. :)

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

ФМИст отново накара инжинерите от меитата да си преглътнат дипломите и еготата 😁. Дон Реба четеш ли?

#11467 (ツ) Courvoisier
Създадено на 21.09.2020, видяно: 1429 пъти.

Много интересно мерите пишоци 3 страници. Мен ме грабна 32 vs 64 бита и скорост. Понеже ми се налага да ползвам криптография, знаете ли, че SHA512 е около 50% по- бърз от SHA256 на 64 битови машини. Въпреки, че операциите са повече, в същото време се обработват 64-bit word-a.

ПС: Low level-а никога не ми е бил интересен, но неволя...

#11468 (ツ) Унуфри
Създадено на 21.09.2020, видяно: 1426 пъти.
Courvoisier

Много интересно мерите пишоци 3 страници. Мен ме грабна 32 vs 64 бита и скорост. Понеже ми се налага да ползвам криптография, знаете ли, че SHA512 е около 50% по- бърз от SHA256 на 64 битови машини. Въпреки, че операциите са повече, в същото време се обработват 64-bit word-a.

ПС: Low level-а никога не ми е бил интересен, но неволя...

Абе дори и на мене като на прост .нетаджия ми замириса тезата на другаря за надмощието на х32 над х64. Ако на нещо му потрябва повече от 3 гиг рам, ко прайм не знам...

#11469 (ツ) |
Създадено на 21.09.2020, видяно: 1425 пъти.
Courvoisier

Много интересно мерите пишоци 3 страници. Мен ме грабна 32 vs 64 бита и скорост. Понеже ми се налага да ползвам криптография, знаете ли, че SHA512 е около 50% по- бърз от SHA256 на 64 битови машини. Въпреки, че операциите са повече, в същото време се обработват 64-bit word-a.

ПС: Low level-а никога не ми е бил интересен, но неволя...

Това е интересно. Мерил ли си дали ША инструкциите са бързи? Ако не се лъжа почти всички процесори имат някакви варианти.

#11470 (ツ) |
Създадено на 21.09.2020, видяно: 1424 пъти.
Унуфри

Абе дори и на мене като на прост .нетаджия ми замириса тезата на другаря за надмощието на х32 над х64. Ако на нещо му потрябва повече от 3 гиг рам, ко прайм не знам...

Ще използва сегменти. :) Back to the ... past. :)

#11471 (ツ) bvbfan
Създадено на 21.09.2020, видяно: 1422 пъти.
|

Хехехе, смешник, аз определено разбирам от програмиране МНОГО ПОВЕЧЕ от теб. :) Освен многото повече опит, имам и ДИПЛОМА доказваща го. :)

И аз, за разлика от теб имам доказателство, че trie e по-бързо. Защото го тествах вчера. Код с trie на Go e 1.5х по-бърз от НхМ сравнение на C.

Много са ми забавни екземпляри като теб и bvbfan, "ама то така", "ама то иначе". Ама да си признае "ей, верно бе, не се бях сетил за това" е НЕВЪЗМОЖНО. Винаги сте прави, нали? :)

След това мнение, вече ясно, че си пълен хал-хабер :-)

#11472 (ツ) |
Създадено на 21.09.2020, видяно: 1418 пъти.
bvbfan
|

Хехехе, смешник, аз определено разбирам от програмиране МНОГО ПОВЕЧЕ от теб. :) Освен многото повече опит, имам и ДИПЛОМА доказваща го. :)

И аз, за разлика от теб имам доказателство, че trie e по-бързо. Защото го тествах вчера. Код с trie на Go e 1.5х по-бърз от НхМ сравнение на C.

Много са ми забавни екземпляри като теб и bvbfan, "ама то така", "ама то иначе". Ама да си признае "ей, верно бе, не се бях сетил за това" е НЕВЪЗМОЖНО. Винаги сте прави, нали? :)

След това мнение, вече ясно, че си пълен хал-хабер :-)

Виждам, че си много добър на празните приказки, но като се стигне до конкретика минаваш на "да, ама..." :) Жалка история. :)

#11473 (ツ) Courvoisier
Последно редактирано на 21.09.2020 от Courvoisier, видяно: 1416 пъти.

Има доста писано по нета. Най-сбито е написано в 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-мо би трябвало да е по- бърз.

#11474 (ツ) bvbfan
Създадено на 21.09.2020, видяно: 1415 пъти.

Ние нямаме дипломи, не сме писали prefix/redix trie, не знаем защо се прави, компактността, която имаш с база данни е много по-добра, управлението на паметта - много по-добро, бързодействието - добре регулирано. Щом не си наясно с тези неща, няма как да си "велик" програмист, нищо повече от поплювко.

#11475 (ツ) |
Последно редактирано на 21.09.2020 от |, видяно: 1414 пъти.
bvbfan

Ние нямаме дипломи, не сме писали prefix/redix trie, не знаем защо се прави, компактността, която имаш с база данни е много по-добра, управлението на паметта - много по-добро, бързодействието - добре регулирано. Щом не си наясно с тези неща, няма как да си "велик" програмист, нищо повече от поплювко.

И добре регулирано, разбира се, означава винаги бавно? :)

Да напомням ли, че "поплювкото" знае какъв компилатор използва ARM? :)

#11476 (ツ) bvbfan
Създадено на 21.09.2020, видяно: 1411 пъти.

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

#11477 (ツ) |
Създадено на 21.09.2020, видяно: 1410 пъти.
Courvoisier

Има доста писано по нета. Най-сбито е написано в stackexchange.

Е, колко по- бързо ще е зависи от инструкциите на процесора. Толкова low-level не разбирам.

Имах предвид, че някои процесори имат ЕДНА инструкция, която смята ША. Например това:

https://en.wikipedia.org/wiki/Intel_SHA_extensions

0 1 2 3 4 5 6 7 8 9 ....20 21 22 23 24 ....32 33 34 35 36

Задача НЕ за интервю
7

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