Если мне нужно будет прочитать много файлов, будет ли быстрее, если я разбью задачу на несколько потоков?

Question

Недавно у меня было интервью с NetApp на роль C ++ (они занимаются системами хранения больших данных).Я написал код для ответа на вопрос интервью.Их ответ был «Ты провалился».Было очень сложно получить обратную связь, как это обычно бывает после провала интервью.После некоторой очень вежливой просьбы об обратной связи я получил немного.Но это все еще не совсем имело смысл.

Вот проблема:

Учитывая кучу файлов в каталоге, прочитайте их все и посчитайте слова.Создайте несколько потоков для параллельного чтения файлов.

Консенсус в NetApp (люди, которые много знают о хранилище), заключается в том, что оно должно работать быстрее с большим количеством потоков.Я думаю, что в большинстве случаев вы настолько ограничены вводом / выводом, что после 1 или 2 он станет медленнее. Я просто не понимаю, как можно ускориться, если вы не знакомы с особыми обстоятельствами (такими как SAN или, возможно, RAID-массивы).Даже в этих случаях количество последовательных каналов к диску насыщается, и вы снова подключаетесь к вводу / выводу после нескольких потоков.

Я думаю, мой код был великолепен (конечно).Я пишу C ++ много лет.Я думаю, что знаю кое-что о том, что делает хороший код.Это должно было пройти только по стилю.Хехе.Как правило, оптимизация производительности - это не то, о чем вы должны догадываться, она должна быть протестирована и измерена.У меня было только ограниченное время для проведения экспериментов.Но теперь мне любопытно.

Код находится в моей учетной записи GitHub здесь:

https://github.com/MenaceSan/CountTextWords

У кого-нибудь есть какие-либо мнения по этому поводу?Пролить свет на то, что они могли думать?Любая другая критика кода?

Я основываю часть своего мнения на этом:

Имеет ли смысл многопоточность для операций, связанных с вводом-выводом?

Answer 1

Ответ, как вы уже догадались, во многом зависит от условий задачи.А также, как вы говорите, вы не можете знать, пока не проведете тестирование.

Тем не менее, это было интервью с крупным поставщиком услуг хранения данных.Возможно, они хотели, чтобы вы либо предположили, что в задаче говорилось о системе, которую вы будете писать для них (т.е. большие объемы очень быстрого сетевого хранилища), либо, по крайней мере, расскажите им о своих предположениях относительно этой задачи.Кроме того, они, возможно, хотели, чтобы вы говорили о таких вещах, как размер файла и количество файлов, и как это повлияет на вещи.(И все остальные факторы - объем памяти компьютера, на котором выполняется чтение, скорость процессора, выполняющего обработку и т. Д.)

Вы говорите:

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

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

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

FWIW, похоже, у вас есть разумное представление о задачах этой задачи, по крайней мере, длятипичная конфигурация машины, которую кто-то вроде меня использует каждый день.Я бы не стал тебя обижать, если бы вы объяснили, что вы предполагаете.Но не все, проводящие интервью, думают одинаково.Извините, что вы не получили работу, но, судя по звуку, вы найдете ее достаточно скоро!