Google Recruiter

[crypto5]

А вы сами не обратили внимание, что в данном тесте бенчмаркер использует массив из 1 000 000 элементов, а вопрос был про 1000? А двумя постами ниже в треде тот же самый автор пишет:

До туда вы уже не дочитали?

Я вообще не понимаю ничего. Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы. Языки высокого уровня особенно те которые крос платформенные (или имеют претензии на это) не предназначены для задач реального времени где счет идет на милисекунды.. Т.е. вопрос вообще не имеет никакого практического смысла.. И говорит о кругозоре вопрошающего... Вспоминается известная басня Крылова.

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
во вторых задача на поговорить, а не на реализовать HFT на жабе

Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.

[Интеррапт]

Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.

При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.

[crypto5]

Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.

При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.

Ну если так то вполне возможно что это и является ответом на вопрос о разнице производительности рандомного и последовательного доступа.

[Интеррапт]

Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.

При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.

Ну если так то вполне возможно что это и является ответом на вопрос о разнице производительности рандомного и последовательного доступа.

Вполне возможно.

[Интеррапт]

Тот тест нужно запустить с "-XX:-UseLoopPredicate" и посмотреть, будет ли разница.

[АццкоМото]

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++

да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-а
мир привет сошел с ума

[dotcom]

mov eax, const - вообще никакого обращения к памяти, константа лежит как часть инструкции (mov + immidiate)

Угу, константа - это волшебное слово, которое лежит в волшебной памяти, в память за ней ходить не надо. Сама команда + константа в памяти лежат? Их считать и выполнить загрузку в регистр нужно? Или оно волшебным образом само загрузится без обращения к памяти. И ширина шины к памяти у нас тоже сферическая и бесконечная в идеале.

Prefetcher контролируется branch/execution prediction модулем.

это совсем совсем не правда, префетчер вообще никакого отношения не имеет к branch prediction

Замечательные prefetcher'ы делают, если они загружают шину трафиком независимо от того, что нужно процессору.

[dotcom]

При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.

Ну счетчик то будет, да? Сравнение с адресом может быть медленнее декримента счетчика конечно. Но большую разницу в производительности мы не должны замечать.

ЗЫ: Хотя стоп... Оно ведь должно сравнивать с обоих концов массива то... Ну тогда действительно можем x2 на маленьких массивах и получить.

[Zorkus]

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++

да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-а
мир привет сошел с ума

Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.

[АццкоМото]

Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.

И вы прочитав два раза не заметили, что ответ был не вам? А тот ответ, который был вам по существу вопроса - проигнорировали. Ну, ваше право

[Интеррапт]

При sequential доступе, когда идет итерация по массиву - эта проверка будет отброшена. Это еще много лет назад было добавлено в хотспот.

Ну счетчик то будет, да? Сравнение с адресом может быть медленнее декримента счетчика конечно. Но большую разницу в производительности мы не должны замечать.

ЗЫ: Хотя стоп... Оно ведь должно сравнивать с обоих концов массива то... Ну тогда действительно можем x2 на маленьких массивах и получить.

Честно говоря, не совсем понял, что имеется в виду. Но даже убрав проверку на array range на каждой итерации цикла - уже можно получить неплохой выигрыш по скорости (что hotspot и делает в некоторых случаях). Посмотреть, что собственно генерит hotspot довольно легко. Нужно загрузить hsdis библиотеку для вашей OS и скинуть его куда-нибудь, где Java его увидит. И запустить тестовое приложение с ключами -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
На выходе получим assembler код, который hotspot jit нагенерил во время исполнения.

[dotcom]

Честно говоря, не совсем понял, что имеется в виду.

При последовательном доступе hotspot может посчитать кол-во итераций до начала цикла. Тогда каждая итерация заканчивается декрементом счетчика. При random доступе, как вы говорили выше, мы проверяем границу. Вопрос, нужно ли проверять нижнюю границу? Наверное, нет, в отрицательный индекс мы все равно не зайдем. Я погорячился. Для верхней границы мы должны сделать одно сравнение индекса доступа с оной.

[АццкоМото]

При последовательном доступе 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() ?
Да, я думаю, что в реальном мире этого не произойдет. Но ведь ничто не мешает, так ведь?

[Сабина]

Тот тест нужно запустить с "-XX:-UseLoopPredicate" и посмотреть, будет ли разница.

Чем мне нравится Интеррапт что он всегда по делу
Лаконично и в самую точку. Молодец !

[Сабина]

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++

да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-а
мир привет сошел с ума

Зоркус просто молодой и категоричный . Но он в целом молодец для своих лет опыта, не обламывайте крылья

[Alexandr]

А вы сами не обратили внимание, что в данном тесте бенчмаркер использует массив из 1 000 000 элементов, а вопрос был про 1000? А двумя постами ниже в треде тот же самый автор пишет:

До туда вы уже не дочитали?

Я вообще не понимаю ничего. Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы. Языки высокого уровня особенно те которые крос платформенные (или имеют претензии на это) не предназначены для задач реального времени где счет идет на милисекунды.. Т.е. вопрос вообще не имеет никакого практического смысла.. И говорит о кругозоре вопрошающего... Вспоминается известная басня Крылова.

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
во вторых задача на поговорить, а не на реализовать HFT на жабе

Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.

проверится перед циклом,
а в коде for (int i : v) ее скорее всего вообще не будет

[Alexandr]

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++

да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-а
мир привет сошел с ума

в чем смысл того, что вы написали?

[Alexandr]

Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.

И вы прочитав два раза не заметили, что ответ был не вам? А тот ответ, который был вам по существу вопроса - проигнорировали. Ну, ваше право

я тоже нифига не понял, поясните

[Alexandr]

Честно говоря, не совсем понял, что имеется в виду.

При последовательном доступе hotspot может посчитать кол-во итераций до начала цикла. Тогда каждая итерация заканчивается декрементом счетчика. При random доступе, как вы говорили выше, мы проверяем границу. Вопрос, нужно ли проверять нижнюю границу? Наверное, нет, в отрицательный индекс мы все равно не зайдем. Я погорячился. Для верхней границы мы должны сделать одно сравнение индекса доступа с оной.

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

[Alexandr]

При последовательном доступе 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() ?
Да, я думаю, что в реальном мире этого не произойдет. Но ведь ничто не мешает, так ведь?

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

[crypto5]

А вы сами не обратили внимание, что в данном тесте бенчмаркер использует массив из 1 000 000 элементов, а вопрос был про 1000? А двумя постами ниже в треде тот же самый автор пишет:

До туда вы уже не дочитали?

Я вообще не понимаю ничего. Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы. Языки высокого уровня особенно те которые крос платформенные (или имеют претензии на это) не предназначены для задач реального времени где счет идет на милисекунды.. Т.е. вопрос вообще не имеет никакого практического смысла.. И говорит о кругозоре вопрошающего... Вспоминается известная басня Крылова.

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++
во вторых задача на поговорить, а не на реализовать HFT на жабе

Бытует мнение что джавоский код будет еще проверку за область масива делать, что будет намного медленнее.

проверится перед циклом,
а в коде for (int i : v) ее скорее всего вообще не будет

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

[АццкоМото]

все нормально в кругозоре у вопрощающего, минимум потому что для конкретно этой задачи java генерит ничуть не хуже код, чем сгенерил бы C\С++

да, генерация кода джавой (какой?) всецело зависит от кругозора Zorkus-а
мир привет сошел с ума

в чем смысл того, что вы написали?

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

[Alexandr]

в чем смысл того, что вы написали?

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

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

[АццкоМото]

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

вы написали о том, что с кругозором у Zorkus все в порядке, потому что джава генерирует хороший код. ничего не имею против кругозора Zorkus, но такое насилие над логикой трудно было пропустить
почему мне не нравится вопрос, я написал выше. кажется, на предыдущей странице
причем здравое зерно в вопросе есть, но задавать его надо более конкретно, возможно, с вариациями а-ля "а если так? а вот так?". тогда будет все ок

[Zorkus]

Прочитал вашу фразу два раза, так и не понял что вы имели в виду. Тут обсуждали вопросы для интервью, я высказался что кодеписцы на доске меня раздражают, меня спросили какие вопросы я считаю хорошими, я привел такой вопрос. Через три страницы споров вы делаете такое заключение. Ну, ваше право.

И вы прочитав два раза не заметили, что ответ был не вам? А тот ответ, который был вам по существу вопроса - проигнорировали. Ну, ваше право

Хм, верно. Заметил свое имя в посте и среагировал. Извиняюсь

Ответ по существу этот, как я понимаю?

По-вашему, вопрос "почему луна больше солнца?" провоцирует много вопросов, по которым можно оценивать познания в астрономии?
При этом с луной-солнцем все более-менее однозначно, а в вашем вопросе все гораздо хуже. Потому что действительно может быть быстрее, а может и не быть. И вместо нормальных рассуждений что на что и как может влиять, интервьюируемый будет заниматься гаданием, что же от него хотят услышать
Тут же какая фишка. Средний нормальный человек имеет свойство сомневаться. Он сомневается, что правильно понял вопрос, он допускает, что вполне очевидный и правильный ответ, который у него сразу появился в голове - правильный. В конце концов, вполне нормально сомневаться в том, что задающий вопрос действительно знает правильный ответ, а не верит в какой-то миф. И когда психологические вопросы соединяются с вопросом, в который заложено слишком много неоднозначностей, результат получается практически случайный

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

Если такой вопрос задается человеку по телефону или на личном интервью, когда у него есть ноутбук, он может проявить базовые performance engineering skills - написать простенький тест, прогнать его на разных массивах и разных типах данных, получить экспериментальные данные, сделать гипотезу.

Психологический аспект (в том, подвергнет ли человек сомнению слова интервьювера, или будет отвечать на вопрос так, как он поставлен "быстрее, потому что 1) a 2) b 3) c) важен, показывает умение не поддаваться на ложную авторитетность. Но даже если его опустить, и задавать вопрос в виде "как вы думаете, будет ли рандомный доступ быстрее или медленнее, или таким же по скорости, для данного примера" - вопрос все равно будет интересным. Его можно упростить, задав наводящие вопросы вида "а если бы массив был не интов. а String[], как бы изменилось поведение?" и прочие. Но это уже вариации.

Как раз таки, я бы ожидал что нормальный человек начнет рассуждать, что и как может влиять, и когда может быть быстрее, а когда нет, а не начнет давать ответы да / нет сходу, и пытаться угадать. Собственно как раз и проверка - будет человек пытаться угадать, или пытаться измерить.