> Условно, перед проверкой на перекрытие данных, адресам делается & 0xFFF, и потом смотрится, есть ли их перекрытие. Так?
Так.
> Мне, логика подсказывает, что при этом объяснении просадка производительности должна быть когда копируешь между адресами кратными 4к, но судя по таблице — это самый лучший случай по производительности. Странно это.
4k-aliasing, не позволяет делать load пока не завершится store (в случае конфликта). То есть нас интересует load, который идет после store.
Если дельта == 4K. то все хорошо ибо:
1) load *+4K
2) store *+4K
3) load *+4K+32
4) store *+4K+32
…
Тут нет конфликтов по 4K-aliasing
Если дельта == 4K+1(2,15,16). то:
1) load *+4K
2) store *+4K+1
3) load *+4K+32
4) store *+4K+1+32
…
то у операций 2 и 3 адреса (в младших 12 битах) перекрываются. И значит load номер 3 ждет пока значение store номер 2 уедет из store buffer.
Ну еще совсем простой пример. David Dice рассказывал про случай, когда просто доступ к чужой NUMA пямяти на 8-сокетной системе (за 2 хопа) занимал > 1000 тактов.
Во первых double check работает — вы просто не умеете его готовить.
А во вторых, да некий аналог на синхронизацию первого доступа есть. Но после того как класс инициализирован — он нам не нужен и его больше нет. Так что ничего медленного, никаких оверхедов. Java это managed runtime — что хотим, то и делаем (в пределах спеки).
Небольшой коммент: кэш ничего не знает про 4K-aliasing.
Это проблема store buffer'а
Так.
> Мне, логика подсказывает, что при этом объяснении просадка производительности должна быть когда копируешь между адресами кратными 4к, но судя по таблице — это самый лучший случай по производительности. Странно это.
4k-aliasing, не позволяет делать load пока не завершится store (в случае конфликта). То есть нас интересует load, который идет после store.
Если дельта == 4K. то все хорошо ибо:
1) load *+4K
2) store *+4K
3) load *+4K+32
4) store *+4K+32
…
Тут нет конфликтов по 4K-aliasing
Если дельта == 4K+1(2,15,16). то:
1) load *+4K
2) store *+4K+1
3) load *+4K+32
4) store *+4K+1+32
…
то у операций 2 и 3 адреса (в младших 12 битах) перекрываются. И значит load номер 3 ждет пока значение store номер 2 уедет из store buffer.
Скачал. потом
sh ./configure
make images
всё
Сдается мне, что тут ты сгущаешь краски ;)
Ну и да — на памяти можно выиграть гораздо больше.
www.youtube.com/watch?v=RGFJjQKChNQ примерно с 50 по 65 минуты ;)
А во втором — длина таблицы не выводится до степени двойки? Чтобы избавится от '%'.
Но и в C++0x11 все работает (если правильно написать).
А во вторых, да некий аналог на синхронизацию первого доступа есть. Но после того как класс инициализирован — он нам не нужен и его больше нет. Так что ничего медленного, никаких оверхедов. Java это managed runtime — что хотим, то и делаем (в пределах спеки).
Нет.
При первом обращении к классу.
Automagically