Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: - Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
Вообще их требования к вакансии на удивление точно совпадали с моими скиллами в резюме.
Я даже удивился, как такое бывает. Обычно кандидат подгоняет резюме под вакансию, а не наоборот
Каюсь, я конкретного ответа на вопрос не дал, ибо для меня было недостаточно вводных данных в вопросе.
За что через 5 минут после начала интервью был признан незнающим организацию компьютерной памяти, на чем интервью и закончилось.
Поэтому прошу всезнающих коллег объяснить мне, какой должен быть правильный ответ.
ЗЫ:
В самой конторе (банк из первой сотни, кстати):
1. Девочка на ресепшене искала себе другую работу прямо на рабочем месте (говорила по телефону с агентами).
2. Сотрудница по персоналу со мной не поздоровалась, украдкой посмотрела в лицо, все как-то бочком-бочком и с глубоко несчастным видом.
3. Мощный интервьюер не рассказал чем они там таким архиважным занимаются, что стоят перед проблемой выбора структур массивов и массивов структур, но зато после собеседования при мне кинул мое резюме в шредер привычным жестом. На прощание он руки мне не подал. Тоже расстроился, наверное, как и сотрудница по персоналу.
В общем, конторе еще учиццо и учиццо уважительному отношению к посетителям.
Как клиента они меня не получат никогда!
lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
Здравствуйте, wamaco, Вы писали:
W>Здравствуйте, lgb, Вы писали:
lgb>>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
W>структура массивов
Здравствуйте, LuciferSaratov, Вы писали:
lgb>>В самой конторе (банк из первой сотни, кстати): LS>ну так сообщи имя героя (название компании), чего стесняешься-то?
lgb>>>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
W>>структура массивов
lgb>Без подробностей?
потому как, с точки зрения обработки аналитики удобнее и проще обрабатывать однотипные данные (массивы),
нежели обработать упорядоченный набор данных (массив) сложные типы данных (структуры)!
пример, дерево!
простейший случай — структура (ветви) данных (значения)
представьте, массив деревьев! ужос и бред!
+ еще структура может описывать аналитические интегральные данные, данные как раз агрегируются в конечных массивах!
Здравствуйте, lgb, Вы писали:
W>>структура массивов
lgb>Без подробностей?
Это называется columnar format. В последнее время все чаще используется на разных Big-Data\Hadoop платформах. См. формат Parquet например.
1) Если данные помещаются в память то итерируя по одному-двум полям ты будешь работать с локализованными данными и процесор чаще будет попадать в кэш.
2) Если не помещаются — то однин из массивов (колонку БД например) может таки поместиться в память, а если нет то все равно влезет больше элементов чем в массиве структур. Соответственно реже будешь читать данные с дисков. Плюс к тому же см (1).
3) Можно менять схему\структуру без переформатирования данных на дисках.
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
lgb>Поэтому прошу всезнающих коллег объяснить мне, какой должен быть правильный ответ.
Простой ответ (практика) — делаем слой абстракции (например на шаблонах, 0 оверхеда), реализуем оба варианта, сравниваем производительность
Нормальный ответ (теоретика) — данные к которым нужен доступ должны лежать рядом.
Если надо экономить память — то тоже лучше структура массивов, не надо тратиться на выравнивание.
Если надо обработать только одно поле, то с точки зрения кеша и всяких префетчей в процессоре лучше структура массивов.
С точки зрения распараллеливания (в т.ч. simd) — тоже лучше работать с массивами.
Но если надо обращаться сразу ко всем полям записи, и соседние записи не нужны — то массив структур.
Ответ разработчика из Сколково — пишем как удобнее (массив структур), потом заводим тикет на исследование возможностей повышения производительности.
Умный ответ — "а зачем велосипед городить? вы же наверняка такую задачу уже решали, производительность разных подходов замеряли, код писали — вот его и реюзнем".
Здравствуйте, wamaco, Вы писали:
W>потому как, с точки зрения обработки аналитики удобнее и проще обрабатывать однотипные данные (массивы), W>нежели обработать упорядоченный набор данных (массив) сложные типы данных (структуры)!
Это из области угадай о чем я думаю...
Для меня структура массивов подразумевает — некую структуру — содержащие разные массивы данных.
Массив структур вполне может быть представлением таблицы базы данных.
W>пример, дерево! W>простейший случай — структура (ветви) данных (значения)
Пример из под палки.
W>представьте, массив деревьев! ужос и бред!
А если структура вполне может содержать массивы структур?
W>+ еще структура может описывать аналитические интегральные данные, данные как раз агрегируются в конечных массивах!
W>отсюда -> структура массивов
Здравствуйте, D. Petrov, Вы писали:
DP>1) Если данные помещаются в память то итерируя по одному-двум полям ты будешь работать с локализованными данными и процесор чаще будет попадать в кэш. DP>2) Если не помещаются — то однин из массивов (колонку БД например) может таки поместиться в память, а если нет то все равно влезет больше элементов чем в массиве структур. Соответственно реже будешь читать данные с дисков. Плюс к тому же см (1). DP>3) Можно менять схему\структуру без переформатирования данных на дисках.
По сути идет оптимизация чтения одного-нескольких полей из базы данных. Это выгодно в тех задачах, когда редко интересен полных набор полей. Интересный подход.
Вы описываете преимущества структуры массивов — но про преимущества массивов структур ни слова.
Но не правильно утверждать, что одно лучше другого. Все зависит от поставленной задачи.
Здравствуйте, Abyx, Вы писали:
A>Простой ответ (практика) — делаем слой абстракции (например на шаблонах, 0 оверхеда), реализуем оба варианта, сравниваем производительность
A>Нормальный ответ (теоретика) — данные к которым нужен доступ должны лежать рядом. A>Если надо экономить память — то тоже лучше структура массивов, не надо тратиться на выравнивание. A>Если надо обработать только одно поле, то с точки зрения кеша и всяких префетчей в процессоре лучше структура массивов. A>С точки зрения распараллеливания (в т.ч. simd) — тоже лучше работать с массивами. A>Но если надо обращаться сразу ко всем полям записи, и соседние записи не нужны — то массив структур.
A>Ответ разработчика из Сколково — пишем как удобнее (массив структур), потом заводим тикет на исследование возможностей повышения производительности. A>Умный ответ — "а зачем велосипед городить? вы же наверняка такую задачу уже решали, производительность разных подходов замеряли, код писали — вот его и реюзнем".
Есть еще операции добавления и удаления.
В место того чтобы обновить 1 массив, приходится обновлять сразу несколько.
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур? lgb>Каюсь, я конкретного ответа на вопрос не дал, ибо для меня было недостаточно вводных данных в вопросе. lgb>За что через 5 минут после начала интервью был признан незнающим организацию компьютерной памяти, на чем интервью и закончилось. lgb>Поэтому прошу всезнающих коллег объяснить мне, какой должен быть правильный ответ.
по существу:
правильный ответ — "а мы покупаем, или продаем?". примеры:
если нужно выполнить запрос типа (from p in points select p.x where p.y == 123) — быстрее отдельно хранить массив всех p.y, т.к. для поиска нужно прочесть с диска в 2 раза меньше данных
если поиск производится редко, а элементы добавляются часто, то проще хранить массив структур, т.к. меньше возни при добавлении
по жизни:
из описанного читается классическая ситуация — кто-то выше хочет найти человека. собеседущюий вас в новом человеке не заинтересован (скорее всего, боится потерять свою позицию), поэтому ищет повод завалить всех кандидатов.
Здравствуйте, omgOnoz, Вы писали:
O>По сути идет оптимизация чтения одного-нескольких полей из базы данных. Это выгодно в тех задачах, когда редко интересен полных набор полей. Интересный подход.
Ага. Для удобства аналитики данные в Hadoop обычно де-нормализованные. 100 полей в одной таблице — обычное дело. Для анализа это удобнее чем нормализованные 30 таблиц по 2-10 полей.
Еще одни аспект вспомнил:
4) Степень архивации — Если данных много и они хранятся блоками, то помещая в блоки части отдельных массивов (часть столбца таблицы) вместо массивов структур (несколько из запесей теблицы) повышается степерь сжатия этих блоков т.к. там данные однотипные. Тот же Parquet умеет сжимать. Некоторые даже в памяти хранят сжатые данные.
Здравствуйте, omgOnoz, Вы писали:
BZ>>вот это и надо было задвинуть. а каких именно тебе данных не хватало?
O>А этот вопрос смысл имеет при подобном отношении?
каком отношении? человек считай не смог ответить сколько будет 2*2. выглядит так что у него просто нет опыта нихкоуровневой оптимизации, а именно это интересовало спрашивающего. для сравнения почитай ответы в треде
Здравствуйте, BulatZiganshin, Вы писали:
BZ>каком отношении? человек считай не смог ответить сколько будет 2*2. выглядит так что у него просто нет опыта нихкоуровневой оптимизации, а именно это интересовало спрашивающего. для сравнения почитай ответы в треде
По мне это вопрос из какой-то методички.
Прикладные задачи, требующие подобных знаний редки. Эти знания специфичны — туже методичку почитай, за день освоишься.
Сейчас вспомнил, что 1 раз сталкивался, но хорошо про неё забыл.
Здравствуйте, lgb, Вы писали:
lgb>Как клиента они меня не получат никогда!
Не факт, что они хотели получить и как работника. Бывает, что интервьюер интервьюирует потому что должен интервьюировать иначе его уволят, а так он покажет какую титаническую работу проделал.
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
Вопрос с подвохом. Есть row-based DB, есть сolumn-based DB. Первая это массив структур, вторая структура массивов.
Есть ситуации, когда сolumn DB выигрывают, есть когда наоборот. Column DB выгодны в некоторых паттернах, где они очень серьезно снижают нагрузку на диски.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>>>вот это и надо было задвинуть. а каких именно тебе данных не хватало? O>>А этот вопрос смысл имеет при подобном отношении? BZ>каком отношении? человек считай не смог ответить сколько будет 2*2. выглядит так что у него просто нет опыта нихкоуровневой оптимизации, а именно это интересовало спрашивающего. для сравнения почитай ответы в треде
Да, я не занимался низкоуровневой оптимизацией. Я прикладник с развитым здравым смыслом Из резюме как бы можно было бы это понять.
А контора (да и не только лишь эта ) могла бы предварительно сообщать, на какие темы будет интервью. Для всех польза. Например, серьезные буржуины так делают, но я понимаю, что они нам не указ.
A>Простой ответ (практика) — делаем слой абстракции (например на шаблонах, 0 оверхеда), реализуем оба варианта, сравниваем производительность A>Нормальный ответ (теоретика) — данные к которым нужен доступ должны лежать рядом. A>Если надо экономить память — то тоже лучше структура массивов, не надо тратиться на выравнивание.
Если речь идет об аналитике, то это очень возможно что Big Data. Если dataset лезет в оперативную память, то это уже не бигдата. Кеши, выравнивания, префетчи — человек явно занимается мелкими оптимизациями вместо архитектуры. Архитектура в данном случае в выборе типа базы данных — c разными типами хранения (RAM, SSD. HDD), с разными типами организации хранения (row, columns).
Это же банк. Какой тут C++ и работа с оперативной памятью,
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
В компьютерной графике, компьютерном зрении и вообще, когда используются GPU с конвейерной архитектурой, выгоднее держать данные массивов отдельно, то есть это что-то вроде структуры массивов, но именно, что вроде.
В базах данных лучше всего использовать типа массив структур, как бы типа, потому что там всё называется по другому, но суть та же. Для повышения скорости доступа используются поисковые индексы, которые идут как бы отдельно, причём они замедляют остальные операции.
Так вот весь смысл в том, что в каждом случае выгоднее использовать что-то своё, нет универсальных решений. Оптимальность понятие относительное, это жертва одним в угоду другому. Чем больше опыта, тем сложнее общаться с обычными людьми. У тех всегда есть кажущиеся им простые вопросы, на которые они ждут простых ответов.
У профи же есть большая карта выбора в которой для выбора структур данных задаётся множество уточняющих вопросов. Более того, помимо этого ещё целый список устаревших (deprecated) приёмов (структур данных, алгоритмов).
По идее работодатель сам знает или не знает какой программист ему нужен, но это его проблема, а не ваша. Работодатель может взять программиста, который ему не подходит, или не взять того, кто ему бы подошёл идеально. Никогда не знаешь, где найдёшь, где потеряешь.
O>По мне это вопрос из какой-то методички.
O>Прикладные задачи, требующие подобных знаний редки.
Для тебя редки, а некоторые только этим и занимаются.
O>Эти знания специфичны — туже методичку почитай, за день освоишься.
Ага, это типа как "С++ за 21 день". Выучить можно (наверное), полноценно работать после этого — нет.
O>Сейчас вспомнил, что 1 раз сталкивался, но хорошо про неё забыл.
Это означает, что в прикладном коде будешь непрерывно косячить, пока это не вылезет где-нибудь в критичном случае и тебе не объяснят, как делать правильно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
lgb>Поэтому прошу всезнающих коллег объяснить мне, какой должен быть правильный ответ.
А понятия не имею . Зависит от размера самой структуры и что делать нужно с этими структурами и массивами структур. А также от алгоритмов. По умолчанию я бы выбрал массив структур. Ибо удобнее работать со всем этим. Быстренько пробежались по массиву, на каждый элемент запустили бы задачу, и каждая задача бы работала со своей памятью, распределенной линейно. Задача поиска по произвольным полям, например, достаточно оптимально бы сработала в случае массива структур — распределяем по потокам задачу поиска, и каждый поток работает со своей памятью, не пересекается с другими. Был бы достаточно легкий поддерживаемый код, приемлемый по производительности. Вычисление контрольной суммы для записи структуры вообще будет гораздо шустрее, чем в случае со структурой массивов. Да и вообще все операции непосредственно с одной записью в структуре будет гораздо шустрее, ибо данные рядом лежат.
Но если нужно, например, суммировать какие значения по одному полю, то структура массивов будет оптимальнее — мы просто тупо пробегаем по массиву, расположено все линейно в памяти, соответственно все довольно шустро отработает. Массив структур при всех его достоинствах будет тормозить на конкретно этой задаче.
lgb>>Как клиента они меня не получат никогда! C>Не факт, что они хотели получить и как работника. Бывает, что интервьюер интервьюирует потому что должен интервьюировать иначе его уволят, а так он покажет какую титаническую работу проделал.
вообще это многое говорит о организации работы в этой организации вообще. так что у ТС правильный вывод.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Для тебя редки, а некоторые только этим и занимаются.
Это узкая специализация
ХГД>Ага, это типа как "С++ за 21 день". Выучить можно (наверное), полноценно работать после этого — нет.
Я думаю тут на много меньше времени надо, чтобы подготовится.
ХГД>Это означает, что в прикладном коде будешь непрерывно косячить, пока это не вылезет где-нибудь в критичном случае и тебе не объяснят, как делать правильно.
Я вообще ленивый программист — предпочитаю не изобретать велосипед, а заюзать/интегрировать готовую технологию.
Здравствуйте, omgOnoz, Вы писали:
O>Здравствуйте, wamaco, Вы писали:
W>>потому как, с точки зрения обработки аналитики удобнее и проще обрабатывать однотипные данные (массивы), W>>нежели обработать упорядоченный набор данных (массив) сложные типы данных (структуры)!
O>Это из области угадай о чем я думаю...
O>Для меня структура массивов подразумевает — некую структуру — содержащие разные массивы данных.
O>Массив структур вполне может быть представлением таблицы базы данных.
W>>пример, дерево! W>>простейший случай — структура (ветви) данных (значения)
O>Пример из под палки.
W>>представьте, массив деревьев! ужос и бред!
O>А если структура вполне может содержать массивы структур?
W>>+ еще структура может описывать аналитические интегральные данные, данные как раз агрегируются в конечных массивах!
W>>отсюда -> структура массивов
O>Необоснованный бред.
O>Смотри ниже http://rsdn.ru/forum/job/6096356.1
Для обработки структура массивов однозначно лучше. Структура массивов = структура матриц, это открывает дорогу использованию многочисленных матричных численных методов, оптимизированных по самое немогу.
ХГД>>Для тебя редки, а некоторые только этим и занимаются.
O>Это узкая специализация
Спасибо, кэп. Именно человека с такой узкой специализацией нанимающему, очевидно, и недоставало.
ХГД>>Ага, это типа как "С++ за 21 день". Выучить можно (наверное), полноценно работать после этого — нет.
O>Я думаю тут на много меньше времени надо, чтобы подготовится.
Думать, конечно, можно о чем угодно, но пока не познакомился плотно с предметной областью, с реальностью это будет иметь не очень много общего.
ХГД>>Это означает, что в прикладном коде будешь непрерывно косячить, пока это не вылезет где-нибудь в критичном случае и тебе не объяснят, как делать правильно.
O>Я вообще ленивый программист — предпочитаю не изобретать велосипед, а заюзать/интегрировать готовую технологию.
Значит на эту позицию скорее всего возьмут кого-то другого.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Спасибо, кэп. Именно человека с такой узкой специализацией нанимающему, очевидно, и недоставало.
Это херня какая-то.
ХГД>Думать, конечно, можно о чем угодно, но пока не познакомился плотно с предметной областью, с реальностью это будет иметь не очень много общего.
Пока что не сталкивался с проблемами, обычно на изучение новой предметной области уходит немного времени.
ХГД>Значит на эту позицию скорее всего возьмут кого-то другого.
Здравствуйте, omgOnoz, Вы писали:
ХГД>>Спасибо, кэп. Именно человека с такой узкой специализацией нанимающему, очевидно, и недоставало.
O>Это херня какая-то.
Что херня? Что на некоторые позиции ищут узких специалистов или хотя бы людей с подходящим бэкграундом? Это правда жизни
ХГД>>Думать, конечно, можно о чем угодно, но пока не познакомился плотно с предметной областью, с реальностью это будет иметь не очень много общего.
O>Пока что не сталкивался с проблемами, обычно на изучение новой предметной области уходит немного времени.
Это говорит только о широте вашего опыта Есть, как ни странно, темы, куда за неделю не въедешь
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, omgOnoz, Вы писали:
O>Здравствуйте, Abyx, Вы писали:
A>>Простой ответ (практика) — делаем слой абстракции (например на шаблонах, 0 оверхеда), реализуем оба варианта, сравниваем производительность
A>>Нормальный ответ (теоретика) — данные к которым нужен доступ должны лежать рядом. A>>Если надо экономить память — то тоже лучше структура массивов, не надо тратиться на выравнивание. A>>Если надо обработать только одно поле, то с точки зрения кеша и всяких префетчей в процессоре лучше структура массивов. A>>С точки зрения распараллеливания (в т.ч. simd) — тоже лучше работать с массивами. A>>Но если надо обращаться сразу ко всем полям записи, и соседние записи не нужны — то массив структур.
A>>Ответ разработчика из Сколково — пишем как удобнее (массив структур), потом заводим тикет на исследование возможностей повышения производительности. A>>Умный ответ — "а зачем велосипед городить? вы же наверняка такую задачу уже решали, производительность разных подходов замеряли, код писали — вот его и реюзнем".
O>Есть еще операции добавления и удаления.
O>В место того чтобы обновить 1 массив, приходится обновлять сразу несколько.
В многопоточном приложении "структура массивов" открывает двери для огромного количества загадочных и мистических последствий в плане performance, как положительных, так и отрицательных.
пример: псевдокод lock-free алгоритма для распараллеливания операций на массиве
int[] data; //какой-то массив
int num_threads; //кол-во потоков для обработки
class Thread
{
int threadID; //ID потока, от 0 до num_threads-1
Thread(int _threadID) {
threadID = _threadID;
}
void run() {
ctr = 0;
i = 0; //index of array element to be accessed
while (i < data.length)
{
i = ctr*num_threads + threadID; //Calculate index of next data item to process
mydata = data[i];
//do some update on mydata
data[i] = mydata;
ctr = ctr+1;
}
}
}
void main()
{
Threads[] threads;
for (i=0; i<num_threads; i++)
threads[i] = new Thread(i);
//start all threads
}
Казалось бы — красота, никаких lock'ов!
На самом деле подобный алгоритм при некоторых количествах потоков из-за false sharing работает гораздо медленнее чем lock-based producer-consumer или "массив структур".
Так что однозначного ответа данный вопрос не имеет. Все зависит от алгоритма и программы.
Здравствуйте, Sealcon190, Вы писали:
S>Для обработки структура массивов однозначно лучше. Структура массивов = структура матриц, это открывает дорогу использованию многочисленных матричных численных методов, оптимизированных по самое немогу.
А если использовать массив массивов ... да... шикарно получается.
Здравствуйте, lgb, Вы писали:
lgb>Давеча на собеседовании был спрошен в контексте правильной стратегии использования памяти: lgb>- Если есть набор данных (например, аналитика) и их нужно обработать, то какая организация данных оптимальнее: структура массивов или массив структур?
я думаю вопрос был про AoS vs SoA ( just google it ), и человеку, который далёк от, скажем, GPGPU или активного использования SIMD, это может ни о чём не говорить, так что вопрос имхо бессмысленный в плане оценки профессиональных качеств разработчика, сойдёт просто для оценки эрудиции/кругозора.
lgb>Как клиента они меня не получат никогда!
эк вас задело. будьте проще, 90% собеседующих — некомпетентны в профессии, а из оставшихся 90% некомпетентны в собеседовании, так что всё ок.
Здравствуйте, 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 еще далеко.
Бывает, что интервьюер интервьюирует потому что должен интервьюировать иначе его уволят, а так он покажет какую титаническую работу проделал.
