Продолжится ли текущая тенденция добавления ядер в компьютеры?
Да, гонка ГГц окончена. Это не практично, чтобы увеличить скорость на текущей технологии. Физика помешала. В технологии изготовления микросхем может произойти существенный сдвиг, который позволит нам обойти это, но это, очевидно, «не за горами».
Если у нас не может быть более быстрых ядер, единственный способ получить больше энергии - это иметь больше ядер.
Или есть какое-то теоретическое или практическое ограничение на количество ядер, которые могут обслуживаться одним набором памяти?
Абсолютно есть предел. В системе с общей памятью память является общим ресурсом и имеет ограниченную пропускную способность.
Max processes = (Memory Bandwidth) / (Bandwidth required per process)
Теперь - эта цифра «Пропускная способность на процесс» будет уменьшена за счет кэшей, но кэши становятся менее эффективными, если они должны быть согласованы друг с другом, потому что все обращаются к одной и той же области памяти. (Вы не можете кэшировать запись в память, если другому процессору может понадобиться то, что вы написали)
Когда вы начинаете говорить об огромных системах, такие общие ресурсы становятся главной проблемой. Это может быть пропускная способность памяти, циклы процессора, доступ к жесткому диску, пропускная способность сети. Все сводится к тому, как устроена система в целом.
Кажется, вы действительно спрашиваете о видении будущего, чтобы вы могли подготовиться. Вот мой дубль.
Я думаю, мы увидим изменение в том, как разработчики программного обеспечения видят параллелизм в своих программах. В настоящий момент я бы сказал, что многие разработчики программного обеспечения видят, что единственный способ использования нескольких потоков состоит в том, чтобы многие из них делали одно и то же. Проблема в том, что все они борются за одни и те же ресурсы. Это означает, что необходимо ввести много блокировок, которые вызывают проблемы с производительностью, и тонких ошибок, которые приводят в бешенство и занимают много времени.
Это не устойчиво.
Производство начало развиваться в начале 20-го века, самый быстрый способ построить много автомобилей - это не иметь много людей, работающих над одним автомобилем, а затем, когда это будет сделано, перенести их всех на следующий автомобиль. Это должно было разделить процесс сборки автомобиля на множество мелких работ, при этом результат одной работы кормил другую. Они называли это сборочными линиями. В проектировании аппаратного обеспечения это называется конвейерной разметкой, и я думаю, что мы увидим, что проекты программного обеспечения будут все больше и больше переходить к нему, поскольку это минимизирует проблему общих ресурсов.
Конечно - на выходе одного этапа и на входе следующего все еще есть общий ресурс, но он только между двумя потоками / процессами и намного проще в обращении. Можно также использовать стандартные методы создания этих интерфейсов, и библиотеки очередей сообщений, похоже, добиваются здесь больших успехов.
Хотя нет единого решения для всех проблем. Этот тип трубопровода отлично подходит для приложений с высокой пропускной способностью, которые могут поглощать некоторую задержку. Если вы не можете жить с задержкой, у вас нет другого выбора, кроме как пойти по пути «много рабочих на одной задаче». Это те, которые вы в идеале хотите использовать на SIMD-машинах / процессорах Array, таких как графические процессоры, но на самом деле это превосходит только проблемы определенного типа. Эти проблемы связаны с тем, что существует много данных, которые обрабатываются одинаково, и между элементами данных очень мало или вообще нет никакой зависимости.
Хорошее понимание методов очереди сообщений и аналогичных методов для конвейерных систем, а также использование мелкозернистого параллелизма на графических процессорах через библиотеки, такие как OpenCL, предоставят вам представление об обоих концах спектра.