Google Recruiter

[Zorkus]

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

Вот, например, хороший, годный вопрос (хотя и легко гуглиться, но если не гуглить - т.е. просить человека ответить на вопрос, имея только ноутбук со средой разработки и доками, но без инета - будет еще интереснее). По крайней мере мне он очень понравился). По глубине и развернутости ответа сразу отделяются те, кто имеет реальное понимание работы среды от тех, кто прочитал книжку типа "Cracking code interview: 100 алгоритмов, которые вы должны научиться писать вслепую на доске, и тогда интервьюверы вас полюбят и возьмут к себе":

http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM. Сорри, что пока в личку.

[adda_]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

[crypto5]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

Ну вот а любители atoi и инвертирования списков еще и проверяют умеете ли вы код писать ))

[Zorkus]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

На уровне железа хорошо, но вопрос еще на уровне Java. Забавный момент, что даже по такой постановке вопроса, многие люди начинают отвечать на него "Конечно быстрее, потому что ...1), 2), 3).".

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

[crypto5]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

[Zorkus]

Я предполагаю, что вы тему на кодеранче до конца прочитали ведь, да?

[Zorkus]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

Сейчас придут железячники и С++-ники и вас заклюют

[crypto5]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

Сейчас придут железячники и С++-ники и вас заклюют

Та я типа не претендую на особые знания в этой области. Так что там еще?

[Zorkus]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

Сейчас придут железячники и С++-ники и вас заклюют

Та я типа не претендую на особые знания в этой области. Так что там еще?

Так это adda сказал, что любой, знающий, как работает процессор, на этот вопрос легко ответит - вот он пусть и рассказывает Я-то подлый джавист.

[swimmer]

Сейчас придут железячники и С++-ники и вас заклюют

А вот мне как железячнику интересно стало. Возьмем к примеру процессор ARM с внешней SRAM (один кусок, никаких страниц) и оключим кэширование для этой памяти. Неужели в JAVA последовательный доступ будет быстрее случайного?

[dotcom]

Сейчас придут железячники и С++-ники и вас заклюют

А вот мне как железячнику интересно стало. Возьмем к примеру процессор ARM с внешней SRAM (один кусок, никаких страниц) и оключим кэширование для этой памяти. Неужели в JAVA последовательный доступ будет быстрее случайного?

Кэшь то как раз не важен. Важнее метод адресации. В random нам адрес надо загружать сам адрес перед чтением или записью. При последовательном доступе используем регистр и оффсет, который грузится один раз. Т.е., грубо говоря, несколько операций ldr r0, addr будут медленнее ldr r0, [r1, #offset] Ну и SIMD тоже можно вспомнить для порядка. На кеш я бы особо не рассчитывал. Не факт, что процессор будет грузить пачку последовательных слов в кешь на всякий пожарный. Зависит от размера участка памяти, блока предсказаний. Загрузка данных в кешь тоже имеет цену.

[adda_]

Сейчас придут железячники и С++-ники и вас заклюют

А вот мне как железячнику интересно стало. Возьмем к примеру процессор ARM с внешней SRAM (один кусок, никаких страниц) и оключим кэширование для этой памяти. Неужели в JAVA последовательный доступ будет быстрее случайного?

Кэшь то как раз не важен. Важнее метод адресации. В random нам адрес надо загружать сам адрес перед чтением или записью. При последовательном доступе используем регистр и оффсет, который грузится один раз. Т.е., грубо говоря, несколько операций ldr r0, addr будут медленнее ldr r0, [r1, #offset] Ну и SIMD тоже можно вспомнить для порядка. На кеш я бы особо не рассчитывал. Не факт, что процессор будет грузить пачку последовательных слов в кешь на всякий пожарный. Зависит от размера участка памяти, блока предсказаний. Загрузка данных в кешь тоже имеет цену.

Причем здесь кэш? В него один хрен надо будет записывать данные из той же памяти.
А так автоинкриментная выборка данных из памяти осуществляется одной командой. По крайней мере в нормальных процессорах..
Но с другой стороны для Жабы или дотнета, имхо где там всякие мемори менеджменты встроены которые запросто в любой момент могут повесить весь перформенс просто потому что им захотелось почистить память, эти рассуждения не имеют никакого смысла. Я не говорю уже о том что операционка занимается свопингом и где на самом деле находятся ваши данные (то ли в кэше, то ли в памяти, то ли в свап области на хардравйве) одному богу извсестно... И никакие тесты нихрена не помогут, потому что тест будет размером с гулькин хрен а реальная программа на порядки больше. И соответсвтенно как там все будет крутиться непонятно.
Эти рассуждения имеют смысл если кто то пишет что то на уровне ассемблера или максимум Си без плюсов для микропроцессоров где никакой операционки или минимум ее. А так - ну типа показать что вы крутой интервьюер..
Реальная оптимизация делается не на уровне адресации, а на уровне алгоритма. Ну скажем если кор функцию считать тупо в лоб или использовать быстрое преобразование Фурье (первое что пришло на ум).. И еще большая - на уровне системного анализа, когда можно ненужные финтифлюшки выкинуть в форточку.
Но крутые пацаны из гугла будут усилетнно требовать написания страндартных функций преобразования данных которые сто лет уже никто не пишет кроме студентов.

[adda_]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

Ну вот а любители atoi и инвертирования списков еще и проверяют умеете ли вы код писать ))

Тогда надо говорить досвидания. Потому что проверять умение писать код у человека который дцать лет его пишет глупо. За это время не умеющие писать код давно стали менеджерами.

[Интеррапт]

30 лет пишу код, а что такое atoi и уж тем более с поддержкой минусов и пробелов, не знаю..
Блин, как я низко пал!

Не важно, вам на интервью обьяснят, что такое atoi и попросят написать

[avitya]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

Ну вот а любители atoi и инвертирования списков еще и проверяют умеете ли вы код писать ))

Тогда надо говорить досвидания. Потому что проверять умение писать код у человека который дцать лет его пишет глупо. За это время не умеющие писать код давно стали менеджерами.

Вы невероятно неправы в этом.

[dotcom]

Причем здесь кэш? В него один хрен надо будет записывать данные из той же памяти.
А так автоинкриментная выборка данных из памяти осуществляется одной командой. По крайней мере в нормальных процессорах..

Уважаемый, вы бы сначала почитали внимательно, что я писал и по поводу чего. Любовь к процессорному кэшу показывают другие участники форума. Они правы в том, что блок предсказания "видит", откуда и куда будет писать цикл, поэтому погут делать prefetch памяти в кешь или писать напрямую в кешь с lazy writing последовательных блоков данных. Это не rocket science. Во-вторых, автоинкрементная выборка, как это вас не удивит, в "нормальных" процессорах со времен PDP-11 и Motorola 68k отсутсвует. По крайней мере в вышеупоминаемом ARM ее просто нет. Нет его и в классическом x86. SIMD - это другое дело. Однако выборка с оффсетом через регистр все равно быстрее в последовательных обращениях к памяти, чем "random" с загрузкой нового адреса в регистр или буфер исполнителя (при прямой адресации), т.к. сам адрес требуется еще считать откуда-то. Оффсет для регистровых операций уже сидит в кеше исполнителяющего модуля после предыдущего выполнения той же команды, но с другим значением регистра.

[dotcom]

Тогда надо говорить досвидания. Потому что проверять умение писать код у человека который дцать лет его пишет глупо. За это время не умеющие писать код давно стали менеджерами.

В гугле проверяют кодо-писательство независимо от опыта. Об этом тут был длинный топик полгода назад. До свидания сказать можно, но если уж очень хочется там работать и не звезда индустрии, которая может задавить авторитетом интервьюирующего, то шансов пройти без кода никаких.

[Zorkus]

Сейчас придут железячники и С++-ники и вас заклюют

А вот мне как железячнику интересно стало. Возьмем к примеру процессор ARM с внешней SRAM (один кусок, никаких страниц) и оключим кэширование для этой памяти. Неужели в JAVA последовательный доступ будет быстрее случайного?

Кэшь то как раз не важен. Важнее метод адресации. В random нам адрес надо загружать сам адрес перед чтением или записью. При последовательном доступе используем регистр и оффсет, который грузится один раз. Т.е., грубо говоря, несколько операций ldr r0, addr будут медленнее ldr r0, [r1, #offset] Ну и SIMD тоже можно вспомнить для порядка. На кеш я бы особо не рассчитывал. Не факт, что процессор будет грузить пачку последовательных слов в кешь на всякий пожарный. Зависит от размера участка памяти, блока предсказаний. Загрузка данных в кешь тоже имеет цену.

Причем здесь кэш? В него один хрен надо будет записывать данные из той же памяти.
А так автоинкриментная выборка данных из памяти осуществляется одной командой. По крайней мере в нормальных процессорах..
Но с другой стороны для Жабы или дотнета, имхо где там всякие мемори менеджменты встроены которые запросто в любой момент могут повесить весь перформенс просто потому что им захотелось почистить память, эти рассуждения не имеют никакого смысла. Я не говорю уже о том что операционка занимается свопингом и где на самом деле находятся ваши данные (то ли в кэше, то ли в памяти, то ли в свап области на хардравйве) одному богу извсестно... И никакие тесты нихрена не помогут, потому что тест будет размером с гулькин хрен а реальная программа на порядки больше. И соответсвтенно как там все будет крутиться непонятно.
Эти рассуждения имеют смысл если кто то пишет что то на уровне ассемблера или максимум Си без плюсов для микропроцессоров где никакой операционки или минимум ее. А так - ну типа показать что вы крутой интервьюер..
Реальная оптимизация делается не на уровне адресации, а на уровне алгоритма. Ну скажем если кор функцию считать тупо в лоб или использовать быстрое преобразование Фурье (первое что пришло на ум).. И еще большая - на уровне системного анализа, когда можно ненужные финтифлюшки выкинуть в форточку.
Но крутые пацаны из гугла будут усилетнно требовать написания страндартных функций преобразования данных которые сто лет уже никто не пишет кроме студентов.

Вот именно. А главное что лекцию по адресации в CPU мы услышали, а ответа на простой (как тут сказали, для любого, знакомого с работой процессора) вопрос, который я предложил - нет Вопрос звучал почему в Java рандомный доступ к массиву интов из 1000 элементов (каждое слово matters) существеннее медленнее, чем последовательный. Боюсь, что некоторые на самом деле стали объяснять, почему он быстрее


"

[dotcom]

Вот именно. А главное что лекцию по адресации в CPU мы услышали, а ответа на простой (как тут сказали, для любого, знакомого с работой процессора) вопрос, который я предложил - нет Вопрос звучал почему в Java рандомный доступ к массиву интов из 1000 элементов (каждое слово matters) существеннее медленнее, чем последовательный. Боюсь, что некоторые на самом деле стали объяснять, почему он быстрее

И где вы нашли в вышесказанном, что random access медленнее? Ась?

[Zorkus]

Вот именно. А главное что лекцию по адресации в CPU мы услышали, а ответа на простой (как тут сказали, для любого, знакомого с работой процессора) вопрос, который я предложил - нет Вопрос звучал почему в Java рандомный доступ к массиву интов из 1000 элементов (каждое слово matters) существеннее медленнее, чем последовательный. Боюсь, что некоторые на самом деле стали объяснять, почему он быстрее

И где вы нашли в вышесказанном, что random access медленнее? Ась?

Так медленнее или не медленнее? Да или нет?

[Интеррапт]

Мой ответ на этот вопрос будет - "зависит от процессора, OS, мэмори пейджинга, реализации конкретной JVM и т.п.". Вполне возможно, что на каком-то другом процессоре или ОС или на другой реализации Джава (например, Далвик для Андроида или конкретно имлементации J2ME для какой-нибудь Нокии) - разницы по скорости не будет. Так что Джава код я никогда не буду оптимизировать по критерию - sequential или random access. Если производительность очень критична, значит спущусь на JNI уровень и буду писать под конкретную платформу/процессор.
Оптимизацию под Джава, как правило, нужно проводить только с точки зрения алгоритмов (тут я с Адда абсолютно согласен), но никак не с точки зрения процессорной оптимизации (т.к. то, что возможно убыстрит для одной платформы, может ухудшить производительность для другой платформы).

[Интеррапт]

Так что все эти бенчмарки, показывающие, что array random access существенно медленней чем sequential могут убедить меня только, если мне выдать performance таблицы для комбинаций процессора, OS, версии OS, JVM, версии JVM (версия Hotspot, версия Dalvik, версия J2ME для конкретного процессора и т.п.). И вот запустив benchmark и опубликовав данные по десяткам таких конфигураций - я тогда поверю, что у Java медленней random access чем sequential access.

[Zorkus]

Ответил в личку.

[dotcom]

Так медленнее или не медленнее? Да или нет?

Что медленнее? Последовательный доступ для процессора быстрее из-за специфики адресации. Я уже третий раз одно и то же повторяю, если вы еще не заметили. Для JVM - ХЗ. Еще раз, ответ был конкретному человеку на конкретный вопрос. Читаем внимательно. Что касательно оптимизации последовательного доступа за счет кеширования, то вопрос надо рассматривать в частном случае.

[Zorkus]

Не кипятитесь, может я не заметил чего просто. Вопрос вообще был как пример с моей стороны, потом в него все вцепились (простой вопрос видно, да),

Изначально вопрос был не про адресацию вообще, если вы отвечаете про адресацию - извините. Вопрос был такой "Почему в Java доступ к массиву int[] размером в тысячу элементов последовательный доступ намного быстрее, чем рандомный".