Comments 42
Лучше поставить SSD на NVME — вот где будет прирост скорости…
начиная с года 2015 все игры, которые я ставил грузили все ядра моего 8 -ядерного процессора. я досихпор помню жаркие холивары на форумах варгейминга когда они под «многопоточностью» релизнули клиент, который юзал всего 2 ядра из возможных. это первый момент.
второй момент… автор статьи поздно спохватился. когда он тут рассуждает о тленности многопоточности, в мире начали уже делать процессоры тензорных вычислений, а это уже другой тип операций. иными словами это всёравно что сейчас рассуждать о том что движок в старой чайке не торт, когда вокруг уже электрокары.
Итого — 30% от 6 ядер — ровно 2 ядра заняты. Играю в HD на ультре.
Остальная нагрузка — у меня там идёт поиск по содержимому файлов + много тяжелого софта ждёт фоном.
Я все игры так проверяю, максимум что пока что видел — 3 ядра реально забитых полностью.
Да и ноутбучные процессоры сильно кастрированы — заметна разница в производительности на тяжёлом софте. По работе использую Siemens TIA Portal — декстоп с HDD уделывает ноут с SSD даже по скорости открытия проекта и объектов в нём :)
Оба теста проводились с одной и той же материнской платы, без прочей нагрузки.
Кроме того протокол sata создавался для HDD и был оптимизован для них. А nvme уже под ssd.
Вы верно заметили, что проблема в мозгах программистов, все программисты страдают тяжелой формой си головного мозга, как последствие засилия си подобных языков, опыта (в основном) однозадачного мышления/управления, и мышления состояниями. В соседних темах про Rust (даже в нем), программисты советовали строить дерево, как мелкие объекты (на куче!), еще раз, в языке для разработки многозадачных приложений (никто не обеспечил инкапсуляцию, элементы дерева, по дизайну, разделяются, блокируются...), местные программисты предложили симулировать си указатель через RC и разделяемое владение… это — финиш.
И в топике Вы поднимаете проблемы, остающиеся как последствие си мышления, какие мьютексы, какие инструкции?!.. откройте же для себя Rust, Erlang и прочая, и прочая.
Инструменты требуют развития, освоения, и реально: (уже) от фон-Неймоновской архитектуры остались только устаревшие встраиваемые soc-системы, которые, опять-же могут оснащаться модемом и создавать не фон-Неймонавские архитектуры. Почитайте работы eao197, он (и не только он) уже эти проблемы решал.
Ну не Си мышление а императивное.)
Тут с вами согласен часто общаясь с коллегами по цеху, большинство которых ориентируется в пределах одого языка или даже одного фрейморка. У них вызывают вопросы казалось бы очевидные, уже давно, моменты. Про минимизации состояния — чистые функции, иммутабельность, о не императивных примитивах для конкурентного программирования и т.д.
Касаемо фон-Неймановской архитектуры или вы что-то не так выразили или не понимаете, сейчас все железо на ней построено как и раньше. Примерять этот термин к языкам как-то не корректно.
все железо на нейПро это и «плачь Ярославны», но в тоже время самый масштабный на Земле процесс — «интернет», или чуть менее масштабные — многомашинные и кластеры; и все это далеко не фон-Неймановские архитектуры. А к языкам корректно только определение: виртуальные процессора-машины (vm), так стоил иерархию Дэйкстра, и к сожалению: си определяет cpu, cpu определяет си, в нашем мире. И эта закостеневшая, в своей цикличности, архитектура захватила весь IT, всех учат преждевременной оптимизации, низкоуровневым примитивам, «ручному закату Солнца» в си стиле. И это еще не пришла эпоха IoT.
… а мы обсуждаем мьютексы, семафоры, барьеры… забывая, что это артефакты аппаратной архитектуры, не имеющие никакого отношения к многозадачности, из-за врожденного дефекта архитектуры и мышления: ограничение по исполнителям, связности.
Параллелизм это самое обычное дело, для серверсайда. Оптимально обслуживать каждого пользователя в отдельном потоке и даже обработку его данных разделять на потоки. Что уменьшает время ответа для конкретного пользователя т.к. ему не нужно стоять в очереди задач вместе с другими пользователями. И очевидно что увеличение ядер(при прочих равных) позволяет повысить фактический параллелизм, а не за счет прерывания.
На домашнем компьютере это пока не сильно важно, при обычном использовании.
Или я неверно понял автора, хотя судя по тому что его удивляет ускорения компиляции при повышении числа ядер(конечно зависит от степени параллелизма самого компилятора), создается восприятие не понимания им вопроса.
Не правильный у вас какой-то сервер-сайд.
Что простите неправильно?)
В правильном сервер-сайде асинхронность > многопоточности.
Термин асинхронность описывает отсутствие порядка выполнения а не параллельность. Когда говорится об участках алгоритма которые могут быть выполнены параллельно используется термин — concurrency. Асинхронность не гарантирует параллельности, например когда у вас есть разделяемый ресурс который несколько задач хотят изменить незавимо, они могут быть выполнены в любом порядке но не одовремнно. Скажем обновление строки в БД. Так что вы, насколько я вижу, как и автор пишите о том что не знаете.
Если этот момент прояснили и по сути вы имели ввиду concurrency >= parallelism. То мною сказанное это не нарушает. Чем больше реальная параллельность(parallelism) за счет ядер, тем больше задач из очереди(concurrency), будет принято на выполенения параллельно. Для конкретного пользователя системы это приведет к уменьшению времени ответа.
Больше чем два ядра в процессоре обычно бесполезны.
Жмём Ctrl + Shift + Esc, видим (цифры у всех разные, но порядки схожие) 137 процессов и 2460 потоков. Про параллелизм на уровне задач автор не слышал.
Не понял о чём статья. Кому сейчас больше двух ядер не нужно? Калькулятору и блокноту? Нужен десктопный юзкейс? Ок, GTA5 уписывает 4 ядра за обе щёки. StarCitizen рекомендует 8. На рабочей машине один только касперский пару ядер греет, а ведь нужно ещё что-то полезное крутить. Под *nix использование zfs прдъявляет суровые требования к CPU. А общем мне пожалуйста в десктоп ядер побольше и подешевле. А в сервера ЕЩЁ больше, 28 на сокет это уже несерьёзно, при наличии возможности запихать в сервер пару-тройку терабай оперативы.
И вообще, не от языка программирования нужно идти к эффективной многопоточности, а от архитектуры ОС — она решает все.
Вот сейчас что-то качается, висят фоновые скайпы и прочие аськи, завтра я посчитаю что-то в расчетной программе типа Open Foam, потом запишу песенку под гитару в Cubase, скину несколько гигов фоток с отдыха, посортирую и слегка поредактирую их, потом порежу видео с концерта, сконвертирую и перешлю друзьям. И да — еще я мог бы поиграть в игрушку (но увы — не играю ни во что по причине лени).
И наконец! Я опять запущу браузер, почитаю хабр и напишу коммент. В общем нам надо больше, больше ядер…
Личный опыт показывает, что даже на "бытовых" задачах для лучшей производительности в рамках одного поколения лучше иметь больше ядер с чуть меньшей частотой, чем меньше, с большей частотой.
"Вызывает интерес вот какой еще разрез" (с)
Вот имеем многоядерный компьютер.
Имеем некое приложение, работающее в один поток, но загружающее ядро на 100 %.
С одной стороны, нагруженное ядро нагревается, и у него уменьшается частота.
С другой стороны, приложение постоянно скачет с ядра на ядро (видно по картинке загрузки ядер).
Помогает ли это против перегрева процессора, сброса частоты и, как следствие, падения производительности?
скорость однопроцессорных систем с 2006 года упёрлась в законы физики
Скорость в герцах, или скорость в количестве инструкций в единицу времени?
Intel свой Skylake выкатила в 2015 году, а не в 2006.
Да что скайлейк, Sandy Bridge вышел в 2011. И тот, и другой очень заметно увеличили одноядерную производительность в сравнении с предшественником.
Так какой еще 2006 год? В 2006 году был Core2Duo на Conroe.
Серьёзные параллельные вычисления на настольных/портативных компьютерах происходят только на GPU
Запустите любую современную игру с открытым миром. Посмотрите на загрузку по ядрам, удивитесь.
Запустите DAW, добавьте несколько треков и навесьте на них плагинов. Тоже удивитесь.
Про видеомонтаж и компиляцию даже не говорю, там и так понятно.
Больше чем два ядра в процессоре обычно бесполезны
Что вы делаете на своем компьютере, что вам всегда хватает 2 ядра?
большинство четырёхъядерных систем основную часть времени не делают ничего, кроме выработки тепла
Любой современный процессор при отсутствии нагрузки почти не потребляет энергии, разница в режиме простоя между 8 и 2 ядрами будет не такая уж большая.
рост производительности идёт от других факторов, таких как переход от HDD к SSD
ССД позволяет не тупить при обращении к жестуому диску — когда вы ищите файлы, грузите какой-то проект/игру, ускоряют скорость загрузки ОС и убирают подвисания в играх с большим миром.
Но когда данные УЖЕ в оперативке, SSD у вас или HDD — не имеет значения.
Производители процессоров хотят, чтобы вы переоценивали функциональные преимущества шикарных новых чипов с ещё большим количеством ядер.
До того как амд разгодилась своими дешевыми 8миядерниками нам годами впаривали 4 ядра, каждый год все дороже.
Пессимизм насчёт многопоточности