Здравствуйте, lgb, Вы писали:
lgb>3. Мощный интервьюер не рассказал чем они там таким архиважным занимаются, что стоят перед проблемой выбора структур массивов и массивов структур, но зато после собеседования при мне кинул мое резюме в шредер привычным жестом.
Он при этом не сказал "Потом ты скажешь мне спасибо !" ?
Здравствуйте, antropolog, Вы писали:
A>я думаю вопрос был про AoS vs SoA ( just google it ), и человеку, который далёк от, скажем, GPGPU или активного использования SIMD, это может ни о чём не говорить, так что вопрос имхо бессмысленный в плане оценки профессиональных качеств разработчика, сойдёт просто для оценки эрудиции/кругозора.
а по моему прекрасный вышел вопрос — если для тебя это расширение кругозора, то к оптимизации тебя подпускать нельзя. 5 минут и всё с человеком ясно
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а по моему прекрасный вышел вопрос — если для тебя это расширение кругозора, то к оптимизации тебя подпускать нельзя. 5 минут и всё с человеком ясно
И тебе желаю по жизни таких же скорых на суждения товарищей. Чтоб дольше 5 минут нигде не задерживался
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а по моему прекрасный вышел вопрос — если для тебя это расширение кругозора, то к оптимизации тебя подпускать нельзя. 5 минут и всё с человеком ясно
Ну это у тебя от недостатка опыта оптимизации, видимо. Т.к. есть множество как аппаратных платформ так и алгоритмов, где SoA не роляет в качестве оптимизации от слова совсем.
Здравствуйте, antropolog, Вы писали:
BZ>>а по моему прекрасный вышел вопрос — если для тебя это расширение кругозора, то к оптимизации тебя подпускать нельзя. 5 минут и всё с человеком ясно
A>Ну это у тебя от недостатка опыта оптимизации, видимо. Т.к. есть множество как аппаратных платформ так и алгоритмов, где SoA не роляет в качестве оптимизации от слова совсем.
так и отлично. идеальный кандидат не ограничится простым перечислением своего опыта, а сможет сформулировать общий критерий когда aos или soa может принести пользу. сможешь?
BZ>так и отлично. идеальный кандидат не ограничится простым перечислением своего опыта, а сможет сформулировать общий критерий когда aos или soa может принести пользу. сможешь?
смогу, если не дай бог попаду к тебе на собеседование. Я одного не пойму, неужели не понятно, что наличие этих знаний ( как и вообще любых узкоспециализированных знаний ) никак не коррелируют с навыками инженера?
Здравствуйте, antropolog, Вы писали:
BZ>>так и отлично. идеальный кандидат не ограничится простым перечислением своего опыта, а сможет сформулировать общий критерий когда aos или soa может принести пользу. сможешь? A>смогу, если не дай бог попаду к тебе на собеседование. Я одного не пойму, неужели не понятно, что наличие этих знаний ( как и вообще любых узкоспециализированных знаний ) никак не коррелируют с навыками инженера?
главное — чтобы коррелировало с решением реальных задач
Здравствуйте, D. Petrov, Вы писали:
DP>2) Если не помещаются — то однин из массивов (колонку БД например) может таки поместиться в память, а если нет то все равно влезет больше элементов чем в массиве структур. Соответственно реже будешь читать данные с дисков. Плюс к тому же см (1).
А если за одну итерацию тебе нужно большинство полей (по элементу из почти всех массивов)?
DP>3) Можно менять схему\структуру без переформатирования данных на дисках.
А если не на диске?
Что за странное рвение такое, предлагать решение, не зная задачи?
Есть подозрение, что ты, сразу, без заминки ответишь и на этот вопрос: что лучше связный список или массив?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
Для задач документооборота, которые характерны работой с "записями" (например — контакт-лист списка рассылки) удобнее работать с массивом структур.
Для задач математической обработки данных (аналитика, MES системы) — наоборот удобнее работать со структурой массивов (в каждом из которых элемент — это POD).
Здравствуйте, diez_p, Вы писали:
_>Посмотрел на ютубе SoA vs AoS видимо интервьюверы тоже посмотрели это, а вы нет )) _>ВАс просто собеседовали не те люди.
Вообще-то мой ответ был в том же ключе, что и у коллег здесь. Но, видимо, там нужно отвечать четко и по-военному. А я опрометчиво допустил рассуждения
Здравствуйте, Философ, Вы писали:
Ф>Что за странное рвение такое, предлагать решение, не зная задачи?
Если человек в курсе, то ему будет понятно, что это вопрос Column-oriented VS Row-oriented. В вопросе уточняется, что цель — аналитика. С уточнением про аналитику, понятно, что правильный наиболее подходящий ответ Column-oriented.
Что интересно, если углубиться чуть дальше и спросить про распределенный Machine Learning (часто это следующий шаг после аналитики). То правильным ответом сатановится, Row-oriented или Column с масивами внути (как в Spark-е).
Ф>Есть подозрение, что ты, сразу, без заминки ответишь и на этот вопрос: что лучше связный список или массив?
Здравствуйте, D. Petrov, Вы писали:
DP>Здравствуйте, Философ, Вы писали:
Ф>>Что за странное рвение такое, предлагать решение, не зная задачи?
DP>С уточнением про аналитику, понятно, что правильный наиболее подходящий ответ Column-oriented.
что, аналитика бывает только по одной колонке? Что-то я сомневаюсь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
DP>>С уточнением про аналитику, понятно, что правильный наиболее подходящий ответ Column-oriented.
Ф>что, аналитика бывает только по одной колонке? Что-то я сомневаюсь.
Нет конечно. Как я писал в соседней ветке, в аналитике таблицы обычно деномализованные по 10-100 колонок в каждой. Тебе обычно нужны 2-5 из них на каждом шаге. ВОт и получается, что нет смысла читать все данные. К тому же GROUPBY+SUM и всякие мапперы быстрее работают если бегают по массивам чисел, а не по массивам струтур.
Здравствуйте, D. Petrov, Вы писали:
DP>Здравствуйте, Философ, Вы писали:
DP>>>С уточнением про аналитику, понятно, что правильный наиболее подходящий ответ Column-oriented.
Ф>>что, аналитика бывает только по одной колонке? Что-то я сомневаюсь.
DP>Нет конечно. Как я писал в соседней ветке, в аналитике таблицы обычно деномализованные по 10-100 колонок в каждой. Тебе обычно нужны 2-5 из них на каждом шаге. ВОт и получается, что нет смысла читать все данные.
Больше одного значение в элементе — структура.
DP> К тому же GROUPBY+SUM и всякие мапперы быстрее работают если бегают по массивам чисел, а не по массивам струтур.
Вот только GROUPBY делается чаще всего после WHERE по соседним полям, это даже в SQL'ном синтаксисе отражено.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
DP>> К тому же GROUPBY+SUM и всякие мапперы быстрее работают если бегают по массивам чисел, а не по массивам струтур.
Ф>Вот только GROUPBY делается чаще всего после WHERE по соседним полям, это даже в SQL'ном синтаксисе отражено.
Ну да. Я ж говорил 2-5 полей: 1-2 на ключь, 1-2 на SUM, 0-2 на WHERE.
Пусть даже 20 полей. Все равно до 100 еще далеко.
