Думаю, мало кто из готовящихся к своему первому интервью, при приеме на первую работу в должности (pre)junior программиста, ответит на этот вопрос отрицательно. Или хотя бы усомнится в положительном ответе. Конечно, такая простая структура данных с прямым доступом по индексу — никаких подвохов! Нет, в некоторых языках типа JavaScript или PHP массивы, конечно, реализованы очень интересно и по сути являются много большим чем просто массив. Но речь не об этом, а о «традиционной» реализации массивов в виде «сплошного участка памяти». В этом случае на основании индексов и размера одного элемента просто вычисляется адрес и осуществляется доступ к соответствующему значению. Что тут сложного?
Давайте разберемся. Например, на Java. Просим ничего не подозревающего претендента создать массив целых чисел n x n. Человек уверено пишет что-то в духе:
Отлично. Теперь просим инициализировать элементы массива чем-нибудь. Хоть единицами, хоть суммой индексов. Получаем:
Даже чаще пишут
что тоже повод для беседы, но сейчас речь о другом. Мы ведь пытаемся выяснить, что человек знает и посмотреть, как он думает. По этому обращаем его внимание на тот факт, что значения расположены симметрично и просим сэкономить на итерациях циклов. Конечно, зачем пробегать все значения индексов, когда можно пройти только нижний треугольник? Испытуемый обычно легко соглашается и мудро выделяя главную диагональ старательно пишет что-то в духе:
Вместо
Теперь самое время для главного удара. Запускаем оба варианта кода на каком-нибудь достаточно большом значении n (порядка нескольких тысяч), например, так.
Что же мы видим? Оптимизированный вариант работает в 10-100 раз медленнее! Теперь самое время понаблюдать за реакцией претендента на должность. Какая будет реакция на необычную (точнее обычную в практике разработчика) стрессовую ситуацию. Если на лице подзащитного изобразился азарт и он стал жать на кнопочки временно забыв о Вашем существовании, то это хороший признак. До определенной степени. Вы ведь не хотите взять на работу исследователя, которому плевать на результат проекта? Тогда не задавайте ему вопрос «Почему?». Попросите переделать второй вариант так, чтобы он действительно работал быстрее первого.
Теперь можно смело заниматься некоторое время своими делами. Через пол часа у Вас будет достаточно материала, для того, чтобы оценить основные личностные и профессиональные качества претендента.
Кстати, когда я коротко описал эту задачку на своем рабочем сайте, то наиболее популярный комментарий был «Вот такая эта Ваша Java кривая». Специально для них выкладываю код на Великом и Свободном. А счастливые обладатели Free Pascal под Windows могут заглянуть
В приведенном коде на Паскале я убрал «запутывающие» моменты и оставил только суть проблемы. Если это можно назвать проблемой.
Какие мы в итоге получаем вопросы к подзащитному?
1. Почему стало работать медленнее? И поподробнее…
2. Как сделать инициализацию быстрее?
Если есть необходимость копнуть глубже именно в реализацию Java, то просим соискателя понаблюдать за временем выполнения для небольших значений n. Например, на ideone.com для n=117 «оптимизированный» вариант работает вдвое медленнее. Но для следующего значения n=118 он оказывается уже в 100 (сто) раз быстрее не оптимизированного! Предложите поэкспериментировать на локальной машине. Пусть поиграет с настройками.
Кстати, а всем понятно, что происходит?
Пока лидирует версия, что «виноват» кэш процессора. Т.е. последовательный доступ в первом варианте работает в пределах хэша, который обновляется при переходе за определенную границу. При доступе по столбцам хэш вынужден постоянно обновляться и это занимает много времени. Давайте проверим эту версию в самом чистом виде. Заведем массив и сравним, что быстрее — обработать все элементы подряд или столько же раз обработать элементы массива со случайным номером? Вот эта программа — ideone.com/tMaR2S. Для 100000 элементов массива случайный доступ обычно оказывается заметно быстрее. Что же это означает?
Тут мне совершенно справедливо указали (Big_Lebowski), что перестановка циклов меняет результаты в пользу последовательного варианта. Пришлось для чистоты эксперимента поставить цикл для разогрева. Заодно сделал несколько повторов, чтобы вывести среднее время работы как советовал leventov. Получилось так ideone.com/yN1H4g. Т.е. случайный доступ к элементам большого массива на ~10% медленнее чем последовательный. Возможно и в правду какую-то роль может сыграть кэш. Однако, в исходной ситуации производительность проседала в разы. Значит есть еще что-то.
Постепенно в лидеры выходит версия про дополнительные действия при переходе от одной строки массива к другой. И это правильно. Осталось разобраться, что же именно там происходит.
Давайте разберемся. Например, на Java. Просим ничего не подозревающего претендента создать массив целых чисел n x n. Человек уверено пишет что-то в духе:
int g[][] = new int[n][n];
Отлично. Теперь просим инициализировать элементы массива чем-нибудь. Хоть единицами, хоть суммой индексов. Получаем:
for(int i = 0; i < n; i++) {
for(int j = 0; j < n; j++) {
g[i][j] = i + j;
}
}
Даже чаще пишут
for(int i = 0; i < g.length; i++) {
for(int j = 0; j < g[i].length; j++) {
g[i][j] = i + j;
}
}
что тоже повод для беседы, но сейчас речь о другом. Мы ведь пытаемся выяснить, что человек знает и посмотреть, как он думает. По этому обращаем его внимание на тот факт, что значения расположены симметрично и просим сэкономить на итерациях циклов. Конечно, зачем пробегать все значения индексов, когда можно пройти только нижний треугольник? Испытуемый обычно легко соглашается и мудро выделяя главную диагональ старательно пишет что-то в духе:
for(int i = 0; i < n; i++) {
g[i][i] = 2* i;
for(int j = 0; j < i; j++) {
g[j][i] = g[i][j] = i + j;
}
}
Вместо
g[i][i] = 2* i;
часто пишут g[i][i] = i + i;
или g[i][i] = i << 1;
и это тоже повод поговорить. Но мы идем дальше и задаем ключевой вопрос: На сколько быстрее станет работать программа?. Обычные рассуждения такие: почти в 2 раза меньше вычислений индексов; почти в 2 раза меньше вычислений значений (суммирование); столько же присваиваний. Значит быстрее процентов на 30. Если у человека за плечами хорошая математическая школа, то можно даже увидеть точное количество сэкономленных операций и более аргументированную оценку эффективности оптимизации.Теперь самое время для главного удара. Запускаем оба варианта кода на каком-нибудь достаточно большом значении n (порядка нескольких тысяч), например, так.
Код с контролем времени
class A {
public static void main(String[] args) {
int n = 8000;
int g[][] = new int[n][n];
long st, en;
// one
st = System.nanoTime();
for(int i = 0; i < n; i++) {
for(int j = 0; j < n; j++) {
g[i][j] = i + j;
}
}
en = System.nanoTime();
System.out.println("\nOne time " + (en - st)/1000000.d + " msc");
// two
st = System.nanoTime();
for(int i = 0; i < n; i++) {
g[i][i] = i + i;
for(int j = 0; j < i; j++) {
g[j][i] = g[i][j] = i + j;
}
}
en = System.nanoTime();
System.out.println("\nTwo time " + (en - st)/1000000.d + " msc");
}
}
Что же мы видим? Оптимизированный вариант работает в 10-100 раз медленнее! Теперь самое время понаблюдать за реакцией претендента на должность. Какая будет реакция на необычную (точнее обычную в практике разработчика) стрессовую ситуацию. Если на лице подзащитного изобразился азарт и он стал жать на кнопочки временно забыв о Вашем существовании, то это хороший признак. До определенной степени. Вы ведь не хотите взять на работу исследователя, которому плевать на результат проекта? Тогда не задавайте ему вопрос «Почему?». Попросите переделать второй вариант так, чтобы он действительно работал быстрее первого.
Теперь можно смело заниматься некоторое время своими делами. Через пол часа у Вас будет достаточно материала, для того, чтобы оценить основные личностные и профессиональные качества претендента.
Кстати, когда я коротко описал эту задачку на своем рабочем сайте, то наиболее популярный комментарий был «Вот такая эта Ваша Java кривая». Специально для них выкладываю код на Великом и Свободном. А счастливые обладатели Free Pascal под Windows могут заглянуть
под спойлер
program Time;
uses
Windows;
var
start, finish, res: int64;
n, i, j: Integer;
g: Array of Array of Integer;
begin
n := 10000;
SetLength(g, n, n);
QueryPerformanceFrequency(res);
QueryPerformanceCounter(start);
for i:=1 to n-1 do
for j:=1 to n-1 do
g[i,j] := i + j;
QueryPerformanceCounter(finish);
writeln('Time by rows:', (finish - start) / res, ' sec' );
QueryPerformanceCounter(start);
for i:=1 to n-1 do
for j:=1 to n-1 do
g[j,i] := i + j;
QueryPerformanceCounter(finish);
writeln('Time by cols:', (finish - start) / res, ' sec' );
end.
В приведенном коде на Паскале я убрал «запутывающие» моменты и оставил только суть проблемы. Если это можно назвать проблемой.
Какие мы в итоге получаем вопросы к подзащитному?
1. Почему стало работать медленнее? И поподробнее…
2. Как сделать инициализацию быстрее?
Если есть необходимость копнуть глубже именно в реализацию Java, то просим соискателя понаблюдать за временем выполнения для небольших значений n. Например, на ideone.com для n=117 «оптимизированный» вариант работает вдвое медленнее. Но для следующего значения n=118 он оказывается уже в 100 (сто) раз быстрее не оптимизированного! Предложите поэкспериментировать на локальной машине. Пусть поиграет с настройками.
Кстати, а всем понятно, что происходит?
Несколько слов в оправдание
Хочу сказать несколько слов в оправдание такого способа собеседования при найме. Да, я не проверяю знание синтаксиса языка и владение структурами данных. Возможно, при цивилизованном рынке труда это все работает. Но в наших условиях тотальной нехватки квалифицированных кадров, приходится оценивать скорее перспективную адекватность претендента той работе с которой он столкнется. Т.е. способность научиться, прорваться, разобраться, сделать.
По духу это похоже на «собеседованию» при наборе легионеров в древнем Риме. Будущего вояку сильно пугали и смотрели краснеет он или бледнеет. Если бледнеет, то в стрессовой ситуации у претендента кровь отливает от головы и он склонен к пассивной реакции. Например, упасть в обморок. Если же соискатель краснел, то кровь у него к голове приливает. Т.е. он склонен к активным действиям, бросаться в драку. Такой считался годным.
Ну и последнее. Почему я рассказал об этой задаче всем, а не продолжаю использовать её на собеседованиях? Просто, эту задачу уже «выучили» потенциальные соискатели и приходится использовать другие.
Собственно на этот эффект я обратил внимание именно в связи с реальной задачей обработки изображений. Ситуация была несколько запутанная и я не сразу понял почему у меня так просел fps после рефакторинга. А вообще таких чуднЫх моментов наверное много накопилось у каждого.
По духу это похоже на «собеседованию» при наборе легионеров в древнем Риме. Будущего вояку сильно пугали и смотрели краснеет он или бледнеет. Если бледнеет, то в стрессовой ситуации у претендента кровь отливает от головы и он склонен к пассивной реакции. Например, упасть в обморок. Если же соискатель краснел, то кровь у него к голове приливает. Т.е. он склонен к активным действиям, бросаться в драку. Такой считался годным.
Ну и последнее. Почему я рассказал об этой задаче всем, а не продолжаю использовать её на собеседованиях? Просто, эту задачу уже «выучили» потенциальные соискатели и приходится использовать другие.
Собственно на этот эффект я обратил внимание именно в связи с реальной задачей обработки изображений. Ситуация была несколько запутанная и я не сразу понял почему у меня так просел fps после рефакторинга. А вообще таких чуднЫх моментов наверное много накопилось у каждого.
Пока лидирует версия, что «виноват» кэш процессора. Т.е. последовательный доступ в первом варианте работает в пределах хэша, который обновляется при переходе за определенную границу. При доступе по столбцам хэш вынужден постоянно обновляться и это занимает много времени. Давайте проверим эту версию в самом чистом виде. Заведем массив и сравним, что быстрее — обработать все элементы подряд или столько же раз обработать элементы массива со случайным номером? Вот эта программа — ideone.com/tMaR2S. Для 100000 элементов массива случайный доступ обычно оказывается заметно быстрее. Что же это означает?
Тут мне совершенно справедливо указали (Big_Lebowski), что перестановка циклов меняет результаты в пользу последовательного варианта. Пришлось для чистоты эксперимента поставить цикл для разогрева. Заодно сделал несколько повторов, чтобы вывести среднее время работы как советовал leventov. Получилось так ideone.com/yN1H4g. Т.е. случайный доступ к элементам большого массива на ~10% медленнее чем последовательный. Возможно и в правду какую-то роль может сыграть кэш. Однако, в исходной ситуации производительность проседала в разы. Значит есть еще что-то.
Постепенно в лидеры выходит версия про дополнительные действия при переходе от одной строки массива к другой. И это правильно. Осталось разобраться, что же именно там происходит.