High performance
Programming
Algorithms
Concurrent computing
CPU
Comments 42
+1
Я уже давно понял, что всякие там I7 с 6-10 ядрами — это просто «пальцы веером». Куда эффективнее купить простой I5 с 4-6 ядрами, при этом максимальная частота на 1 ядро хоть чуть, но выше. Всё равно в повседневном использовании редко используется даже 3 ядра. Сборка крупных программ (тот же GCC в Gentoo) производится очень редко, отсюда и выигрыша от количества ядер не видно особо.
Лучше поставить SSD на NVME — вот где будет прирост скорости…
+5
Это не пальцы веером. Многопоточные — для обработки видео, трассировки лучей, физические симуляции и тп. Кому -то надо, а кому-то и нет. Каждый подбирает по себе в зависимости от задач и бюджета.
0
Я имел в виду домашнее применение. Да и для повседневной разработки выигрыш в пару минут при времени сборки проекта около 2 минут на 4 ядрах — сомнительно, потому что всё равно 99% времени сидим «тупо пялясь в код» ;)
+3
У вас Вас все равно стоит весьма многопоточный GPU и он Вам нужен, если Вы только не сторонник интерфейса командной строки:) Поговорим о пользе многопоточности?
0
Многопоточность полезна, я говорил о избыточности ядер в домашних ПК, куда «ради понтов» ставят i7, которые не будут утилизироваться в принципе. Или вы хотите сказать, что рядовой пользователь способен часами нагружать на 100% 8 ядер полезной нагрузкой? Игра (1-2 потока, редко 3 потока) + браузер (много потоков, но нагрузка мизерная) — рядовой случай дома.
+1
Вопрос с понтами не такой простой как кажется. Мне без разницы по какой причине рядовые пользователи покупают i7-i9. Но благодаря именно им эти процессоры массовые и доступные. И мне не надо брать ссуду, когда мне нужен именно многоядерный процессор для работы дома. Тоже касается и GPU разработка которого оплачена геймерами.
+3
вы малость застряли во времени.

начиная с года 2015 все игры, которые я ставил грузили все ядра моего 8 -ядерного процессора. я досихпор помню жаркие холивары на форумах варгейминга когда они под «многопоточностью» релизнули клиент, который юзал всего 2 ядра из возможных. это первый момент.

второй момент… автор статьи поздно спохватился. когда он тут рассуждает о тленности многопоточности, в мире начали уже делать процессоры тензорных вычислений, а это уже другой тип операций. иными словами это всёравно что сейчас рассуждать о том что движок в старой чайке не торт, когда вокруг уже электрокары.
+1
Ок. Запустил танки, открыл ProcessExplorer:
Скрин
image

Итого — 30% от 6 ядер — ровно 2 ядра заняты. Играю в HD на ультре.
Остальная нагрузка — у меня там идёт поиск по содержимому файлов + много тяжелого софта ждёт фоном.
Я все игры так проверяю, максимум что пока что видел — 3 ядра реально забитых полностью.
0
у меня максимум было 4 потока. но это уже явно не 2, как у автора)
0
А я в качестве хобби массивы картинок обрабатываю. Там несколько программ: фотошоп — для выравниваяния/склеивания панорам, фотоматикс — для шдр-инга. Поскольку получить то, что нравится получается не сразу (нужно несколько итераций), то весь массив картинок приходится обрабатывать по нескольку раз и по-разному. В среднем фотоматикс грузит оба ядра ноутбука на 100% на несколько минут для одного прогона. Поэтому я подумываю о многоядерном монстре от АМД, чтобы получать результат не через полчаса, а сразу
0
Тут я с Вами соглашусь, на ноутбуке обрабатывать картинки довольно странно, для этого есть десктопы :)
0
Мсье знает толк в извращениях.
Да и ноутбучные процессоры сильно кастрированы — заметна разница в производительности на тяжёлом софте. По работе использую Siemens TIA Portal — декстоп с HDD уделывает ноут с SSD даже по скорости открытия проекта и объектов в нём :)
0
Лучше поставить SSD на NVME — вот где будет прирост скорости…

Да тоже не так много.
NVMe относительно SATA даёт значительный для линейного копирования килотонны информации.
Если нагрузка не состоит из такого, то NVMe смысла практически не имеет.
0
Разница в 2 раза даже на нелинейных задачах. Вот мои результаты синтетики (Samsung 970 EVO M.2 vs OCZ-ARC100 SATA3):
Crystal Disk Mark
970 Evo OCZ

Оба теста проводились с одной и той же материнской платы, без прочей нагрузки.
0
В синтетике всё прекрасно. Но винда как грузилась пять секунд, так и грузится(
0
Ну, у меня сейчас большую часть загрузки занимает POST, даже в FastBoot'е. Совсем от этого уйти нельзя. А сама винда грузится очень быстро. Тут уже упирается в процессор, как понимаю в загрузке Win.
0
Ну для Optane 900P скорее всего sata уже будет маловато.
Кроме того протокол sata создавался для HDD и был оптимизован для них. А nvme уже под ssd.
+2

В моём хобби-проекте достаточно файлов, чтобы шестиядерный 12-поточный i7 3930k был хорошо загружен (полная сборка — где-то 8 минут), и при этом я задумывался бы о всяких тредрипперах. Да и всякое там индексирование файлов в IDE многопоточное.


Кроме того, есть ряд вычислительных задач, для которых дешевле купить многоядерный процессор, чем переносить их на GPU.


А вот NVMe ставить совсем не вижу необходимости. /usr/include очень быстро закешируется в памяти.

0

Долгая компиляция с нуля — признак большого количества файлов:


% find ./ -name "*.cpp" | wc -l 
1832

И упарывания темплейтами, да.

+2
Счастье — дело техники! (с) КО
Вы верно заметили, что проблема в мозгах программистов, все программисты страдают тяжелой формой си головного мозга, как последствие засилия си подобных языков, опыта (в основном) однозадачного мышления/управления, и мышления состояниями. В соседних темах про Rust (даже в нем), программисты советовали строить дерево, как мелкие объекты (на куче!), еще раз, в языке для разработки многозадачных приложений (никто не обеспечил инкапсуляцию, элементы дерева, по дизайну, разделяются, блокируются...), местные программисты предложили симулировать си указатель через RC и разделяемое владение… это — финиш.
И в топике Вы поднимаете проблемы, остающиеся как последствие си мышления, какие мьютексы, какие инструкции?!.. откройте же для себя Rust, Erlang и прочая, и прочая.
Инструменты требуют развития, освоения, и реально: (уже) от фон-Неймоновской архитектуры остались только устаревшие встраиваемые soc-системы, которые, опять-же могут оснащаться модемом и создавать не фон-Неймонавские архитектуры. Почитайте работы eao197, он (и не только он) уже эти проблемы решал.
0

Ну не Си мышление а императивное.)
Тут с вами согласен часто общаясь с коллегами по цеху, большинство которых ориентируется в пределах одого языка или даже одного фрейморка. У них вызывают вопросы казалось бы очевидные, уже давно, моменты. Про минимизации состояния — чистые функции, иммутабельность, о не императивных примитивах для конкурентного программирования и т.д.
Касаемо фон-Неймановской архитектуры или вы что-то не так выразили или не понимаете, сейчас все железо на ней построено как и раньше. Примерять этот термин к языкам как-то не корректно.

-2
все железо на ней
Про это и «плачь Ярославны», но в тоже время самый масштабный на Земле процесс — «интернет», или чуть менее масштабные — многомашинные и кластеры; и все это далеко не фон-Неймановские архитектуры. А к языкам корректно только определение: виртуальные процессора-машины (vm), так стоил иерархию Дэйкстра, и к сожалению: си определяет cpu, cpu определяет си, в нашем мире. И эта закостеневшая, в своей цикличности, архитектура захватила весь IT, всех учат преждевременной оптимизации, низкоуровневым примитивам, «ручному закату Солнца» в си стиле. И это еще не пришла эпоха IoT.
… а мы обсуждаем мьютексы, семафоры, барьеры… забывая, что это артефакты аппаратной архитектуры, не имеющие никакого отношения к многозадачности, из-за врожденного дефекта архитектуры и мышления: ограничение по исполнителям, связности.
+2

Параллелизм это самое обычное дело, для серверсайда. Оптимально обслуживать каждого пользователя в отдельном потоке и даже обработку его данных разделять на потоки. Что уменьшает время ответа для конкретного пользователя т.к. ему не нужно стоять в очереди задач вместе с другими пользователями. И очевидно что увеличение ядер(при прочих равных) позволяет повысить фактический параллелизм, а не за счет прерывания.
На домашнем компьютере это пока не сильно важно, при обычном использовании.
Или я неверно понял автора, хотя судя по тому что его удивляет ускорения компиляции при повышении числа ядер(конечно зависит от степени параллелизма самого компилятора), создается восприятие не понимания им вопроса.

+3
Не правильный у вас какой-то сервер-сайд. В правильном сервер-сайде асинхронность > многопоточности. А ещё лучше, если сервер-сайд умеет и в одно, и в другое.
0
Не правильный у вас какой-то сервер-сайд.

Что простите неправильно?)


В правильном сервер-сайде асинхронность > многопоточности.

Термин асинхронность описывает отсутствие порядка выполнения а не параллельность. Когда говорится об участках алгоритма которые могут быть выполнены параллельно используется термин — concurrency. Асинхронность не гарантирует параллельности, например когда у вас есть разделяемый ресурс который несколько задач хотят изменить незавимо, они могут быть выполнены в любом порядке но не одовремнно. Скажем обновление строки в БД. Так что вы, насколько я вижу, как и автор пишите о том что не знаете.
Если этот момент прояснили и по сути вы имели ввиду concurrency >= parallelism. То мною сказанное это не нарушает. Чем больше реальная параллельность(parallelism) за счет ядер, тем больше задач из очереди(concurrency), будет принято на выполенения параллельно. Для конкретного пользователя системы это приведет к уменьшению времени ответа.

+2
а я созрел сменить дома 2 ядра на 4, пара запущенных браузеров с кучей вкладок визуально отзывчивее.
+4
Больше чем два ядра в процессоре обычно бесполезны.

Жмём Ctrl + Shift + Esc, видим (цифры у всех разные, но порядки схожие) 137 процессов и 2460 потоков. Про параллелизм на уровне задач автор не слышал.
0
… именно потому, что у вас мощный многоядерный процессор. Иначе были бы cpu-wait
0
Откуда мнение, что многопоточное программирование сложно? Бывает сложно задачу разделить на блоки, это да, а программировать потоки — чего сложного то? Если человек вообще не писал параллельное, его ошибки могут быть трудно-обнаруживаемые (для него). Но если вошел в тему — вообще нет никаких проблем с гонкой, дедлоками и прочими ужасами. Особенно, если язык дает возможность не общие данные дергать, а посылать сообщения (Go, Javascript).
+1

Не понял о чём статья. Кому сейчас больше двух ядер не нужно? Калькулятору и блокноту? Нужен десктопный юзкейс? Ок, GTA5 уписывает 4 ядра за обе щёки. StarCitizen рекомендует 8. На рабочей машине один только касперский пару ядер греет, а ведь нужно ещё что-то полезное крутить. Под *nix использование zfs прдъявляет суровые требования к CPU. А общем мне пожалуйста в десктоп ядер побольше и подешевле. А в сервера ЕЩЁ больше, 28 на сокет это уже несерьёзно, при наличии возможности запихать в сервер пару-тройку терабай оперативы.

+2
Странно, что говоря о синхронизации потоков упомянуты только mutex, и проигнорированы Events. На мой взгляд, подписки на события должны быть более эффективны.
И вообще, не от языка программирования нужно идти к эффективной многопоточности, а от архитектуры ОС — она решает все.
0
Добавлю, что и CAS в определённых задачах вполне покрывает потребности, а если появится двойной CAS (или одинарный но на 128 бит), то это будет вообще отличная новость.
0
То как выглядит типичный софт напрямую зависит от того что использует большинство целевой аудитории, и если большинство перейдет на многопоточные системы то и софт однозначно за ним подтянется та в общем так сейчас и происходит
+2
Ну господа… Компутер девайс весьма универсален.
Вот сейчас что-то качается, висят фоновые скайпы и прочие аськи, завтра я посчитаю что-то в расчетной программе типа Open Foam, потом запишу песенку под гитару в Cubase, скину несколько гигов фоток с отдыха, посортирую и слегка поредактирую их, потом порежу видео с концерта, сконвертирую и перешлю друзьям. И да — еще я мог бы поиграть в игрушку (но увы — не играю ни во что по причине лени).
И наконец! Я опять запущу браузер, почитаю хабр и напишу коммент. В общем нам надо больше, больше ядер…
0

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


"Вызывает интерес вот какой еще разрез" (с)
Вот имеем многоядерный компьютер.
Имеем некое приложение, работающее в один поток, но загружающее ядро на 100 %.
С одной стороны, нагруженное ядро нагревается, и у него уменьшается частота.
С другой стороны, приложение постоянно скачет с ядра на ядро (видно по картинке загрузки ядер).
Помогает ли это против перегрева процессора, сброса частоты и, как следствие, падения производительности?

0
В целом да. Но — если гонять на домашней машине несколько виртуалок, то многоядерность становится критичной. Отдаёшь каждой машине по два процессора и по отдельному диску — и всё живёт, не спотыкаясь друг о друга. Я лично уже лет 7 почти только из-под виртуалок и работаю. Возможность сохранять произвольные состояния и откатывать их обратно в любой момент очень завлекает.
+1
скорость однопроцессорных систем с 2006 года упёрлась в законы физики

Скорость в герцах, или скорость в количестве инструкций в единицу времени?
Intel свой Skylake выкатила в 2015 году, а не в 2006.
Да что скайлейк, Sandy Bridge вышел в 2011. И тот, и другой очень заметно увеличили одноядерную производительность в сравнении с предшественником.
Так какой еще 2006 год? В 2006 году был Core2Duo на Conroe.
Серьёзные параллельные вычисления на настольных/портативных компьютерах происходят только на GPU

Запустите любую современную игру с открытым миром. Посмотрите на загрузку по ядрам, удивитесь.
Запустите DAW, добавьте несколько треков и навесьте на них плагинов. Тоже удивитесь.
Про видеомонтаж и компиляцию даже не говорю, там и так понятно.
Больше чем два ядра в процессоре обычно бесполезны

Что вы делаете на своем компьютере, что вам всегда хватает 2 ядра?
большинство четырёхъядерных систем основную часть времени не делают ничего, кроме выработки тепла

Любой современный процессор при отсутствии нагрузки почти не потребляет энергии, разница в режиме простоя между 8 и 2 ядрами будет не такая уж большая.
рост производительности идёт от других факторов, таких как переход от HDD к SSD

ССД позволяет не тупить при обращении к жестуому диску — когда вы ищите файлы, грузите какой-то проект/игру, ускоряют скорость загрузки ОС и убирают подвисания в играх с большим миром.
Но когда данные УЖЕ в оперативке, SSD у вас или HDD — не имеет значения.
Производители процессоров хотят, чтобы вы переоценивали функциональные преимущества шикарных новых чипов с ещё большим количеством ядер.

До того как амд разгодилась своими дешевыми 8миядерниками нам годами впаривали 4 ядра, каждый год все дороже.
Only those users with full accounts are able to leave comments. , please.