Здравствуйте, 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% некомпетентны в собеседовании, так что всё ок.
Бывает, что интервьюер интервьюирует потому что должен интервьюировать иначе его уволят, а так он покажет какую титаническую работу проделал.
