Google Recruiter

[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[], как бы изменилось поведение?" и прочие. Но это уже вариации.

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

[Zorkus]

Кстати, может кто-нибудь еще приведет интересные (на его взгляд) вопросы для интервью

[fruit6]

интересные для кого? для Вас, для кандидата?

кандидат смотрит на Вас, на Ваш проект и делает свои далеко идущие выводы, оставляя Вас в бесконечном поиске "нормальных" людей.

[АццкоМото]

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

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

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

хмм. я вот не могу что-то проверять параллельно с телефонным разговором. если только интервьюер дает время и замолкает нафиг на 10 минут. даже элементарные вещи не могу

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

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

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

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

[dotcom]

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

Да вот уже давно руки чешутся разобраться с JVM. Кстати, забавно ведь получается. Забавная вещь ведь получается с проверкой на нижнюю границу. Был бы unsigned в Java - все было бы проще. Ведь даже signed к unsigned не сконвертируешь, чтобы одной проверкой обойтись.

[АццкоМото]

Да вот уже давно руки чешутся разобраться с JVM. Кстати, забавно ведь получается. Забавная вещь ведь получается с проверкой на нижнюю границу. Был бы unsigned в Java - все было бы проще. Ведь даже signed к unsigned не сконвертируешь, чтобы одной проверкой обойтись.

char - двухбайтное беззнаковое целое

[Alexandr]

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

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

мой ответ был на вот это сообщение

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

смысл моего сообщения был в том, что безотносительно языка этот вопрос имеет смысл, потому что вопрос о понимании среды в которой происходит разработка и эксплуатация систем
что касается жабы, то проход по массиву снегерит примерно такой же код, какой сгенерировал бы С\С++, т.е. буду проявляться абсолютно те же паттерны, поэтому выражение adda_ "Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы" бесмысленно, а соответственно с кругозором Зоркуса все в норме и я согласен с ним, что такие вопросы на жаба интервью задавать можно

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

так такие вопросы и задаются как затравка к беседе, никто от кандидата и не ожидает сухого ответа, и даже если он (ответ) правильный, то логично спрашивать "а если вот так", "а если вот это подкрутим" и так далее

[Alexandr]

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

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

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

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

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

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

вы упускаете из вида то, что константа лежит вместе с командой (в сегменте кода), уже зачитана префетчером (так как тут нет бранчей и соответственно нет никакой проблемы для префетчера читать на пару кеш-лайнов вперед) в L1C (l1 для кода), когда вы читаете переменную из памяти (из сегмента данных), то вы читаете память, которой может и не быть в кеше (на сей раз L1D), а следовательно в худшем случае доступ к переменной может отложиться эдак циклов на 100
т.е. совершенно разные вещи

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

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

[Alexandr]

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

да ладно вам, нормальные же вопросы, не?

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

[АццкоМото]

поэтому выражение adda_ "Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы" бесмысленно

Ну да, ну да. И наэкономив целых 7 микросекунд на массиве из 1000 штуков мы будем потом прерваны на миллисекунды сборщиком мусора
Мысль adda_ как раз очень верна: в джаве нужно экономить на эффективных алгоритмах и структурах данных, а не заморачиваться скоростью доступа к массиву

[Alexandr]

поэтому выражение adda_ "Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы" бесмысленно

Ну да, ну да. И наэкономив целых 7 микросекунд на массиве из 1000 штуков мы будем потом прерваны на миллисекунды сборщиком мусора
Мысль adda_ как раз очень верна: в джаве нужно экономить на эффективных алгоритмах и структурах данных, а не заморачиваться скоростью доступа к массиву

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

Мысль adda_ как раз очень верна: в джаве нужно экономить на эффективных алгоритмах и структурах данных, а не заморачиваться скоростью доступа к массиву

именно! и эта задача по сути задача о структурах данных