Сижу вот изучаю Rust
Как вы, наверное, знаете, в C/C++ есть
И компилятор там всеми силами пытается его соптимайзить, фигачит
В Rust есть по сути тоже самое, но еще и со строками (
Короче - сам поиск примерно никак, используется линейный поиск, но оптимизируется сравнение строк.
Единственное, если размер строк разный, то он сделает jump table по их размеру (по сути, как с обычными числами)
А вот со сравнением строк уже интереснее. Да да, это скорее всего уже не сам раст, сколько llvm, но все равно интересно
1) Если строки <8 байт, то строка запишется как число, и компилятор просто прочитает строку как число и сделает сравнение
2) Если строки <16 байт, то сделает два сравнения (два числа 8 байт)
3) Если строки <32(?) байта, то фиганет SIMD сравнение (строки все еще числа)
4) Иначе, вызовет какую-то функцию сравнения длинных строк, которая, думаю, использует какие-то идеи из 1-3
Обидно конечно, что он не оптимайзит для длинных строк ничего. В моем случае (см картинку) очевидно, что можно понять, какая именно строка нужна по первому символу даже, и дальше сделать всего-лишь 1 проверку.
May be one day я решусь залезть в llvm...
Так что если вдруг кто-то решит переписать ejudge на раст, то придется и для него кодогенерировать бор для команд...
Как вы, наверное, знаете, в C/C++ есть
switch, который работает для чиселИ компилятор там всеми силами пытается его соптимайзить, фигачит
jump table какой-то или около тогоВ Rust есть по сути тоже самое, но еще и со строками (
match str), и возник вопрос, а как оно там, собственно, оптимизируетсяКороче - сам поиск примерно никак, используется линейный поиск, но оптимизируется сравнение строк.
Единственное, если размер строк разный, то он сделает jump table по их размеру (по сути, как с обычными числами)
А вот со сравнением строк уже интереснее. Да да, это скорее всего уже не сам раст, сколько llvm, но все равно интересно
1) Если строки <8 байт, то строка запишется как число, и компилятор просто прочитает строку как число и сделает сравнение
2) Если строки <16 байт, то сделает два сравнения (два числа 8 байт)
3) Если строки <32(?) байта, то фиганет SIMD сравнение (строки все еще числа)
4) Иначе, вызовет какую-то функцию сравнения длинных строк, которая, думаю, использует какие-то идеи из 1-3
Обидно конечно, что он не оптимайзит для длинных строк ничего. В моем случае (см картинку) очевидно, что можно понять, какая именно строка нужна по первому символу даже, и дальше сделать всего-лишь 1 проверку.
May be one day я решусь залезть в llvm...
Так что если вдруг кто-то решит переписать ejudge на раст, то придется и для него кодогенерировать бор для команд...
godbolt.org
Compiler Explorer - Rust (rustc 1.55.0)
// Type your code here, or load an example.
pub fn some(s: &str) -> i32 {
match s {
"asomessmesomdsomesomesomesomessmesomdsomesomesome" => 0,
"bothrothrothrothrothrothrothrothrothrothrothrothr" => 1,
"cstufstufstufstufstufstuf…
pub fn some(s: &str) -> i32 {
match s {
"asomessmesomdsomesomesomesomessmesomdsomesomesome" => 0,
"bothrothrothrothrothrothrothrothrothrothrothrothr" => 1,
"cstufstufstufstufstufstuf…
👍1
В Go можно написать простой rate-limiter, который ограничивает нагрузку, двумя способами: перед запуском горутины, или внутри нее. Я вот не задумывался, что они отличаются довольно сильно в плане порядка обработки запросов
За подробностями прошу сюда: https://leviska.notion.site/3dbe7633fd5449ff99c485d147f2d420
За подробностями прошу сюда: https://leviska.notion.site/3dbe7633fd5449ff99c485d147f2d420
Лев's Notion on Notion
Рейтлимитер: внутри или снаружи | Notion
Начнем с простого: зачем нужен рейтлимитер?
👍1
Написал что-то похожее на kwargs, но статически типизированное и на расте. Не спрашивайте меня зачем. playground
Немного макросов, и я думаю, что можно сделать даже красиво
https://twitter.com/leviska0/status/1536502738237931520
Немного макросов, и я думаю, что можно сделать даже красиво
https://twitter.com/leviska0/status/1536502738237931520
👍3