такс

кто шарит в плюсах

что долго работает ксоры или побитовый сдвиг?

кто шарит в плюсах

это крестики такие

да

тогда не шарю :)

в смысле без выделенной строки?

если ее удалить, то получаем пару пустых циклов

а, не, один пустой цикл

который компилятор удалит

... или все-таки два. Потому что дальше тоже ничего не относится к первому циклу

https://habrahabr.ru/post/241740/ ????????????

ну а так чо, 900 операций побитового сдвига... хотя конечно не, скорее 480

что долго работает ксоры или побитовый сдвиг?

оба одинаково вроде должны работать

здесь дороже - 450 операций разыменования

я так понимаю, массив гигантского размера и мы дергаем очень разные его части

типа в разных страницах могут лежать разные части массива?

внутренний цикл идет по j, которая больше, чем i, поэтому на каждой итерации внутреннего цикла у нас идет подгрузка соответствующего куска из памяти, потому что у нас cache miss

да не просто в разных страницах - там индексы различаются на 2^31

ну... 2^29

ок

а в одной странице (если страница 4к) всего-то 1024 интов помещается

если это массив интов такого размера, то он порядка гигабайта

и у нас 450 обращений в почти случайные места этого гигабайтного массива

не в ксорах вобщем дело, и не в сдвигах

ща чот меня штырит и мне кажется что там меньше индексы

вот nameko обменивается сообщениями через AMQP, это нормальная практика? мне просто хайлоад надо построить желательно на микросервисах..

ты же феменистка...

i и j пробегают до 29, то есть наибольшее значение это 1 << 29 + 1 << 28

вот nameko обменивается сообщениями через AMQP, это нормальная практика? мне просто хайлоад надо построить желательно на микросервисах..

Нормальная, но не забывайте о мониторинге ampq- он имеет милую тенденцию внезапно умирать под нагрузкой

да, если что, у внешнего цикла можно сделать до < 29 8)

http://www.theverge.com/circuitbreaker/2016/7/27/12294530/xiaomi-mi-notebook-air-macbook-competitor

но я думаю компилятор это сможет понять

i и j пробегают до 29, то есть наибольшее значение это 1 << 29 + 1 << 28

угу, чуть подольше подумал, ты прав

можно там пошаманить на тему переупорядочивания циклов, чтобы сгруппировать близкие индексы

но особо не получится

да там всего 900 обращений

чо из-за этого париться то?

450

ну 1.5с может для кого-то и беда

450

ну ваще тады

вобщем ксоры и побитовый сдвиг это элементарная арифметика, которую процессор выполняет за очень небольшое число тактов

435 ваще

да там всего 900 обращений

Ну, все это в цикле

а подгрузка из оперативки в кэш - за большое

ща, поищу табличку

Там примерно 6 300 000 операций

Непонятно, почему долго так

не в ксорах вобщем дело, и не в сдвигах

В них

пффффффффф

Мэп протестирован - не в нем

https://blog.codinghorror.com/the-infinite-space-between-words/

тебе выше @aragaer всё норм пояснил

обращение к незакешированной памяти это порядка 350 циклов процессора

я так понимаю, массив гигантского размера и мы дергаем очень разные его части

Это мап, не массив

на каждой итерации цикла у тебя максимум два сдвига и два ксора, это ну 10 щиклов

ооо

ну значит это 450 вычислений хэш функции, а это еще медленнее

ну ты же ваще можешь просто проверить, сохранить эти индексы в массив

и сделать одинарный цикл

короче

ради вас

а если добавить ^x - то 1.5c

а у тебя какие флаги оптимизации стоят?

неужели компилятор сам не догадался это сделать?

-O2

ERROR: S client not available

что не догадался?

должен был

x ^ (1 << i) это инвариант в пределах второго цикла

вынесение инвариантов это на о2 должно делаться

а

у тебя же нету c во внутреннем

сделай внутри c ^ (1 << j)

1.6 c

так что точно не в сдвигах дело и не в ксорах. А в кэш миссах

тьфу

лол

в вычислении

ну она достаточно дерьмовая

ну разницы между (1 << i) ^ (1 << j) и c ^ (1 << j) немного

ксоров столько же, сдвигов меньше

а работает медленнее

ну, примерно так же

ты ж сказал 252 мс против 1.6с

а

а, ну, я про x ^ (1 « i) ^ (1 « j)

хз

ну, по крайней мере

стоп

более того, как мы видим, он делает вынесение инварианта - c ^ (1 << j) работает так же, как x ^ (1 << i) ^ (1 << j)

я говорю, пусть попробует брать эти индексы из массива, и увидит, что дело было не в бобине

а в мапе

я попробывал unordered_map заменить на обычный

там хэши не вычисляются, но есть лог из-за к/ч дерева

стало 2с работать

впрочем, это отличие этих структур

пщщщ пщщщ попробуй индексы из массива пщщщ пщщщ дело не в ксоре пщщ пщщ