да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-аAlexandr wrote:все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
Угу, константа - это волшебное слово, которое лежит в волшебной памяти, в память за ней ходить не надо.Alexandr wrote: mov eax, const - вообще никакого обращения к памяти, константа лежит как часть инструкции (mov + immidiate)
Сама команда + константа в памяти лежат? Их считать и выполнить загрузку в регистр нужно? Или оно волшебным образом само загрузится без обращения к памяти. И ширина шины к памяти у нас тоже сферическая и бесконечная в идеале.Замечательные prefetcher'ы делают, если они загружают шину трафиком независимо от того, что нужно процессору.Alexandr wrote:это совсем совсем не правда, префетчер вообще никакого отношения не имеет к branch predictionPrefetcher контролируется branch/execution prediction модулем.
Ну счетчик то будет, да? Сравнение с адресом может быть медленнее декримента счетчика конечно. Но большую разницу в производительности мы не должны замечать.Интеррапт wrote: При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.
Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.АццкоМото wrote:да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-аAlexandr wrote:все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
мир привет сошел с ума
И вы прочитав два раза не заметили, что ответ был не вам? А тот ответ, который был вам по существу вопроса - проигнорировали. Ну, ваше правоZorkus wrote: Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.
Честно говоря, не совсем понял, что имеется в виду. Но даже убрав проверку на array range на каждой итерации цикла - уже можно получить неплохой выигрыш по скорости (что hotspot и делает в некоторых случаях). Посмотреть, что собственно генерит hotspot довольно легко. Нужно загрузить hsdis библиотеку для вашей OS и скинуть его куда-нибудь, где Java его увидит. И запустить тестовое приложение с ключами -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssemblydotcom wrote:Ну счетчик то будет, да? Сравнение с адресом может быть медленнее декримента счетчика конечно. Но большую разницу в производительности мы не должны замечать.Интеррапт wrote: При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.
ЗЫ: Хотя стоп... Оно ведь должно сравнивать с обоих концов массива то... Ну тогда действительно можем x2 на маленьких массивах и получить.
При последовательном доступе hotspot может посчитать кол-во итераций до начала цикла. Тогда каждая итерация заканчивается декрементом счетчика. При random доступе, как вы говорили выше, мы проверяем границу. Вопрос, нужно ли проверять нижнюю границу? Наверное, нет, в отрицательный индекс мы все равно не зайдем. Я погорячился. Для верхней границы мы должны сделать одно сравнение индекса доступа с оной.Интеррапт wrote: Честно говоря, не совсем понял, что имеется в виду.
При всем уважении, я не совсем понимаю, откуда взялся цикл. И тем более - почему этот цикл такой, при котором кто-то что-то может посчитать.dotcom wrote: При последовательном доступе hotspot может посчитать кол-во итераций до начала цикла.
Чем мне нравится Интеррапт что он всегда по делуИнтеррапт wrote:Тот тест нужно запустить с "-XX:-UseLoopPredicate" и посмотреть, будет ли разница.
Зоркус просто молодой и категоричныйАццкоМото wrote:да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-аAlexandr wrote:все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
мир привет сошел с ума
. Но он в целом молодец для своих лет опыта, не обламывайте крылья проверится перед циклом,crypto5 wrote:Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.Alexandr wrote:все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++adda_ wrote:Я вообще не понимаю ничего. Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы. Языки высокого уровня особенно те которые крос платформенные (или имеют претензии на это) не предназначены для задач реального времени где счет идет на милисекунды.. Т.е. вопрос вообще не имеет никакого практического смысла.. И говорит о кругозоре вопрошающего... Вспоминается известная басня Крылова.Zorkus wrote: А вы сами не обратили внимание, что в данном тесте бенчмаркер использует массив из 1 000 000 элементов, а вопрос был про 1000? А двумя постами ниже в треде тот же самый автор пишет:
До туда вы уже не дочитали?
во вторых задача на поговорить, а не на реализовать HFT на жабе
в чем смысл того, что вы написали?АццкоМото wrote:да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-аAlexandr wrote:все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
мир привет сошел с ума
я тоже нифига не понял, пояснитеАццкоМото wrote:И вы прочитав два раза не заметили, что ответ был не вам? А тот ответ, который был вам по существу вопроса - проигнорировали. Ну, ваше правоZorkus wrote: Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.
гадание на пальцах говорит о том, что при рандомном доступе будут проверяться обе границы массива,dotcom wrote:При последовательном доступе hotspot может посчитать кол-во итераций до начала цикла. Тогда каждая итерация заканчивается декрементом счетчика. При random доступе, как вы говорили выше, мы проверяем границу. Вопрос, нужно ли проверять нижнюю границу? Наверное, нет, в отрицательный индекс мы все равно не зайдем. Я погорячился. Для верхней границы мы должны сделать одно сравнение индекса доступа с оной.Интеррапт wrote: Честно говоря, не совсем понял, что имеется в виду.
это именно то, что и нужно было сделать, чтобы мы не читали=доступ к памяти\"вычисляли сложным образом=много тактов вычисляли" индекс, а он был прямо в кодеАццкоМото wrote:При всем уважении, я не совсем понимаю, откуда взялся цикл. И тем более - почему этот цикл такой, при котором кто-то что-то может посчитать.dotcom wrote: При последовательном доступе hotspot может посчитать кол-во итераций до начала цикла.
а что если цикл (ок-ок, пусть для простоты будет цикл) будет вида
for (int i=0; i<1000; i++) sum+=array[getIndexFromF__ckingNowhere(i)];
где getIndexFromF__ckingNowhere() - какая-то не поддающаяся хотспотовскому анализу внешняя функция, которая в одном случае возвращает тупо i, а в другом - someTrickyHashFunction(i)%1000
как противоположный вариант, можно без цикла. пусть будет
array[0]=0;
array[1]=0;
...
array[999]=0;
и против этого
array[372]=0;
array[491]=0;
...
array[013]=0;
вот из чего мы можем сделать вывод, что два этих тысячестрочных куска кода не будут проанализированы и сведены к, грубо говоря, к memset() ?
Да, я думаю, что в реальном мире этого не произойдет. Но ведь ничто не мешает, так ведь?