Вы пожалуйста не путайте 2 вещи: язык и реализацию. В языке (спецификации) четко и ясно :) сказано «нечто реализуещее требуемый интерфейс». ;) То, что первая реализация от Оракла создает некоторые классы на лету еще ничего не значит. И кстати, это нифига не анонимные классы, ибо термин анонимный класс имеет конкретный смысл прописанный в спеке и не нужно мешать понятия. Кстати, как раз анонимные классы — это синтаксический сахар. ;)
При этом у нас на подходе есть несколько «более других» реализаций. МетодХэндлы, там рожь всякая…
Вот допилим и поменяем. ;)
От Интела и взялось. ;)
Кажется где-то до кловертаунов (могу немного ошибаться с микроархитектурой) не было спец обработки NOP и таки он пересылал из eax в eax. Точнее не пересылал, а делал ренайминг, а так как внешний регистр тот же — то ничего не делал. Но в RS попадал и power кушал (перформанс не кушал). Сейчас исчезает уже после декодера.
«Разве что в машинную инструкцию nop, на которую, в свою очередь, даже процессор не тратит ни такта.»
Ну это если у нас бедный одинокий NOP. :)
А вот если забить NOP-ами весь fetch line (16 bytes), то придется потратится. Немного если fetch line в iCache, и много в противном случае. ;)
Все проблемы в следующей фразе:
«По этому обращаем его внимание на тот факт, что значения расположены симметрично и просим сэкономить на итерациях циклов. Конечно, зачем пробегать все значения индексов, когда можно пройти только нижний треугольник?»
А дело в том, что экономить нужно не на итерациях, а на операциях. Всё же просто:
— В оригинальном коде у нас N^2 записей в память — и как ты тут не оптимизируй, именно столько и останется. тут не соптимизировать.
— Далее, а стоит ли что нибудь нам i+j? Да ничего оно не стоит. Эта сумма на самом деле индуктивная и заменять такие выражения на инкремент умели еще в 70-х. :) Да к тому же это и пофиг, как i+j так и v+1 вычислаются с латенси в 1 такт, причем на исполнение программы этот 1 такт вообще никак не влияет, пойдет в параллель.
— адресная арифметика? Так же индуктивность + целочисленная арифметика. Intel CPU уже давно содержат по 3 целочисленных сложителя, у AMD тоже не один.
— Обслуживание циклов? Цикл короткий, с вероятностью 99% попадает под LSD (Loop Stream Detector). Profit.
Итого, имеем, что у нас есть N квадрат записей в память. Остальные операции можно не считать. Так что тут оптимизировать? Тут любое прикосновение к коду будет не оптимизацией, а пессимизацией, что автор нам успешно и продемонстрировал.
Вот если бы вместо (i+j) мы считали (int)(sin((double)(i+j))) тогда можно было о чем-нибудь говорить.
Если у вас будет частично concurrent gc — то скорее всего вы только mark фазу будете делать конкаррентно с мутаторами, а собственно чистку в стоп-фазу. Тогда опять же мемори барьеры не нужны. ;) Зато полностью и с размаху наступите на false sharing. :) А вот когда вы начнете делать полностью concurrent gc — я уже вам никаких советов давать не смогу за ненадобностью ;)
Тут есть один нюанс, которые люди часто путают. А именно memory barriers & gc barriers. Еще больше путаницы добавляется когда gc-шные барьеры начинают называть по их специализации, т.е. read-barrier & write-barrier. :)
Так вот — это совершенно разные вещи. Совпадение слова барьер там и там совершенно случайно.
Если у вас не concurrent gc — gc-шные барьеры вам совсем не нужны.
Тут возникают детали, которых я просто уже не знаю. На самом деле, если Invalidation Queue заполнена — мы очевидно не будем посылать acknowledgement и ожидающее ядро будет стоять и ждать.
Как часто это встречается? Думаю очень редко, ибо я нигде не видел упоминания такой проблемы.
http://jeeconf.com/archive/jeeconf-2013/materials/jdk8-lambda/
Вы пожалуйста не путайте 2 вещи: язык и реализацию. В языке (спецификации) четко и ясно :) сказано «нечто реализуещее требуемый интерфейс». ;) То, что первая реализация от Оракла создает некоторые классы на лету еще ничего не значит. И кстати, это нифига не анонимные классы, ибо термин анонимный класс имеет конкретный смысл прописанный в спеке и не нужно мешать понятия. Кстати, как раз анонимные классы — это синтаксический сахар. ;)
При этом у нас на подходе есть несколько «более других» реализаций. МетодХэндлы, там рожь всякая…
Вот допилим и поменяем. ;)
Это я Вам как разработчик лямбд говорю.
Кажется где-то до кловертаунов (могу немного ошибаться с микроархитектурой) не было спец обработки NOP и таки он пересылал из eax в eax. Точнее не пересылал, а делал ренайминг, а так как внешний регистр тот же — то ничего не делал. Но в RS попадал и power кушал (перформанс не кушал). Сейчас исчезает уже после декодера.
Ну это если у нас бедный одинокий NOP. :)
А вот если забить NOP-ами весь fetch line (16 bytes), то придется потратится. Немного если fetch line в iCache, и много в противном случае. ;)
PS Да, речь про Intel.
«По этому обращаем его внимание на тот факт, что значения расположены симметрично и просим сэкономить на итерациях циклов. Конечно, зачем пробегать все значения индексов, когда можно пройти только нижний треугольник?»
А дело в том, что экономить нужно не на итерациях, а на операциях. Всё же просто:
— В оригинальном коде у нас N^2 записей в память — и как ты тут не оптимизируй, именно столько и останется. тут не соптимизировать.
— Далее, а стоит ли что нибудь нам i+j? Да ничего оно не стоит. Эта сумма на самом деле индуктивная и заменять такие выражения на инкремент умели еще в 70-х. :) Да к тому же это и пофиг, как i+j так и v+1 вычислаются с латенси в 1 такт, причем на исполнение программы этот 1 такт вообще никак не влияет, пойдет в параллель.
— адресная арифметика? Так же индуктивность + целочисленная арифметика. Intel CPU уже давно содержат по 3 целочисленных сложителя, у AMD тоже не один.
— Обслуживание циклов? Цикл короткий, с вероятностью 99% попадает под LSD (Loop Stream Detector). Profit.
Итого, имеем, что у нас есть N квадрат записей в память. Остальные операции можно не считать. Так что тут оптимизировать? Тут любое прикосновение к коду будет не оптимизацией, а пессимизацией, что автор нам успешно и продемонстрировал.
Вот если бы вместо (i+j) мы считали (int)(sin((double)(i+j))) тогда можно было о чем-нибудь говорить.
совершенно неверно.
т.е. бывает, но не всегда, или не так как хотелось или вообще не то ;)
О! Клева, хочу послушать доклад об этом. ;))))
Так что всё как у больших. ;)
Так вот — это совершенно разные вещи. Совпадение слова барьер там и там совершенно случайно.
Если у вас не concurrent gc — gc-шные барьеры вам совсем не нужны.
Как часто это встречается? Думаю очень редко, ибо я нигде не видел упоминания такой проблемы.