Testing Stage’19: Technical | Security | Management and Approach — Early bird till 21 Dec. Hurry up!
×Закрыть

Принципы работы Garbage collection

В этой статье вспомним, что такое Garbage collection (GC), зачем он нужен вообще и какие проблемы решает. Детально рассмотрим режимы работы GC в .NET, поймем, как работает каждый из них, их особенности и различия. Затронем специфику применения некоторых режимов GC в .NET.

Изучим вопрос мониторинга работы GC, какие доступны для этого инструменты и как ими пользоваться.

Введение

Вообще, откуда взялась эта тема? Она появилась из-за поведения наших сервисов, в том числе и на production. Мы увидели, что некоторые приложения начали отнимать 30% CPU. Не могли понять, почему это происходит — ведь по коду все было хорошо. Провели анализ метрик, о которых поговорим позже, и выяснили, что GC потребляет на сборку мусора порядка 30%. И тут возник вопрос — что же с этим делать. Появилось поле для оптимизации. И мы добились хороших результатов, когда после всевозможных манипуляций снизили потребление CPU до 10%, до 5%. Как этого можно добиться, я расскажу ниже.

Когда я задался вопросом и начал готовить эту статью, мне было интересно, а когда у нас появился первый язык, который уже поддерживал сборку мусора. Я даже немного удивился, потому что это был 1964 год. 50 лет назад люди уже задумывались о том, что разработчиков нужно освобождать от занятий с памятью. Это был язык APL. Из языков, которые поддерживают сборку мусора, можно назвать Erlang (1990 год), Eifel, Smalltalk (1972 год), конечно же, C# и любой современный язык, который выходит сейчас, например Go. Это уже must have.

Интересный факт: по исследованиям, разработчики, которые занимаются написанием кода на языках, не поддерживающих сборку мусора, 40% своего продуктивного времени тратят на операции по работе с управлением памятью, что довольно много и, скорее всего, не всегда будет понятно менеджменту.

Что такое Garbage Collection

GC (Garbage Collection — сборка мусора) — высокоуровневая абстракция, которая избавляет разработчиков от необходимости заботиться об освобождении управляемой памяти.

Давайте вспомним основные тезисы по сборке мусора. В .NET сборка мусора основана на трассировке.

Существует понятие корневых элементов приложения. Корневым элементом (root) называется ячейка в памяти, в которой содержится ссылка на размещаемый в куче объект. Строго говоря, корневыми могут называться такие элементы:

  • Ссылки на глобальные объекты (хотя в C# они не разрешены, но CIL-код позволяет размещать глобальные объекты).
  • Ссылки на любые статические объекты или статические поля.
  • Ссылки на локальные объекты в пределах кодовой базы приложения.
  • Ссылки на передаваемые методу параметры объекта.
  • Ссылки на объект, ожидающий финализации.
  • Любые регистры центрального процессора, которые ссылаются на объект.

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

Фазы сборки мусора:

  1. Маркировка (mark phase).
  2. Чистка (sweep phase).
  3. Сжатие (compact phase).

Поколения объектов: нулевое, первое, второе поколение.

Нулевое и первое поколения еще называют эфемерными поколениями. Они нужны для ускорения отклика нашего приложения.

Для работы приложения CLR инициализирует 2 сегмента виртуального адресного пространства — Small object heap (объекты до 85 КБ) и Large object heap (объекты свыше 85 КБ, в некоторых случаях массивы и связанные списки (linked list), не достигшие данного размера).

Конфигурирование GC довольно простое, что отображено на следующем рисунке:

Рисунок 1. App.config

Конфигурировать режимы работы GC можно путем добавления в app.config секции, показанной на слайде выше, с помощью параметров gcConcurrent, gcServer.

Режим рабочей станции

Рисунок 2. Процесс сборки мусора в режиме рабочей станции

Если мы откроем любую книгу по .NET, любую статью по .NET, где у нас описано, как работает Garbage Collection, обычно это звучит так: работает приложение, не хватает памяти для того, чтобы выделить следующий объект, и происходит запуск GC. При этом все активные потоки приложения приостанавливаются. Это самый простой процесс сборки мусора — workstation non-concurrent mode.

Недостатком этого подхода является то, что во время сборки мусора приложение не занимается ничем другим, кроме сборки мусора. Можно ли этого избежать и как-то повысить отклик нашего приложения?

Идея, как повысить производительность приложения, довольно проста: если нулевое и первое поколения собираются очень быстро, то почему бы их не очищать отдельно от второго поколения. Возможно ли так сделать, чтобы при сборке второго поколения, наше приложение и дальше продолжало аллоцировать объекты? Да, возможно.

Параллельная сборка мусора

Рисунок 3. Параллельная сборка мусора

Для этого существует режим параллельной сборки мусора (workstation concurrent GC).

Параллельная сборка мусора в .NET 1.0–3.5

До выхода .NET 4.0 очистка неиспользуемых объектов проводилась с применением техники параллельной сборки мусора. В этой модели, при выполнении сбора мусора эфемерных объектов, сборщик мусора временно приостанавливал все активные потоки внутри текущего процесса, чтобы приложение не могло получить доступ к управляемой куче вплоть до завершения процесса сборки мусора.

По завершении цикла сборки мусора приостановленным потокам разрешалось снова продолжить работу. К счастью, в .NET 3.5 сборщик мусора был хорошо оптимизирован, и потому связанные с ним короткие перерывы в работе с приложением редко становились заметными.

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

Фоновая сборка мусора

Рисунок 4. Фоновая сборка мусора

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

Механизм сборки мусора в .NET 4.0 был улучшен так, чтобы на приостановку потока, связанного с деталями сбора мусора, требовалось меньше времени. Благодаря этим изменениям процесс очистки неиспользуемых объектов поколения 0 и 1 стал оптимальным. Он позволяет получать более высокий уровень производительности приложений.

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

Режим сервера

Особенности работы GC в режиме сервера.

  • Сборка выполняется в нескольких выделенных потоках, выполняемых с приоритетом THREAD_PRIORITY_HIGHEST .
  • Для каждого процессора предоставляется куча и выделенный поток, выполняющий сборку мусора, и сборка куч выполняется одновременно. Каждая куча содержит кучу небольших объектов и кучу больших объектов, и все кучи доступны из пользовательского кода. Объекты из различных куч могут ссылаться друг на друга.
  • Так как несколько потоков сборки мусора работают совместно, для кучи одного и того же размера сборка мусора сервера выполняется быстрее сборки мусора рабочей станции.
  • В сборке мусора сервера часто используются сегменты большего размера. Однако обратите внимание, что это только обобщение: размер сегмента зависит от реализации и может изменяться. При настройке приложения не следует делать никаких предположений относительно размера сегментов, выделенных сборщиком мусора.
  • Сборка мусора сервера может оказаться ресурсоемкой операцией. Например, если на компьютере с 4 процессорами выполняется 12 процессов, в каждом из которых применяется сборка мусора сервера, будут использоваться 48 выделенных потоков сборки мусора. В случае высокой загрузки памяти, если все процессы запускают сборку мусора, сборщику мусора понадобится выполнить планирование работы 48 потоков.

При запуске сотен экземпляров приложения рассмотрите возможность использования сборки мусора рабочей станции с отключенной параллельной сборкой мусора. Это уменьшит число переключений контекста, что может повысить быстродействие.

Рисунок 6. Визуализация работы Garbage Collection в режиме сервера

На рисунке 6 показана визуализация того, как все это работает в режиме сервера. Как видим, главное отличие заключается в том, что сборка мусора выполняется для каждого доступного процессора.

Рисунок 7. Server Background Mode

Начиная с .NET Framework 4.5, фоновая сборка мусора сервера является режимом по умолчанию для сборки мусора сервера. Этот режим функционирует аналогично фоновой сборке мусора рабочей станции, описанной выше, однако с некоторыми отличиями. Для фоновой сборки мусора рабочей станции используется один выделенный поток фоновой сборки мусора, тогда как для фоновой сборки мусора сервера используется несколько потоков — обычно по одному выделенному потоку для каждого логического процессора.

Инструменты мониторинга

GC class

Что можно сделать с помощь GC class из кода подробно описано в статье, но стоит сразу отметить, что это будет просто логирование нужной нам информации в лог, а затем анализ этой информации с помощью каких-то доступных средств. Не очень хороший способ — это не выход из ситуации.

Performance Monitor

Одним из самых мощных инструментов для обнаружения проблем с производительностью в Windows являются встроенные счетчики производительности, так называемые Performance counters. Оснастка Performance monitor — основной инструмент для управления ими.

Performance Viewer

Performance Viewer основан на трассировке событий Windows. Чуть позже поговорим о том, что это такое, зачем это нужно и что можно вообще мониторить с его помощью.

SOS Debugging Extension

SOS Debugging Extension стоит отметить, но уже мало кто использует этот инструмент.

dotMemory

Платный представитель от JetBrains. Стоит отметить, что его open source конкуренты на текущий момент мало в чем ему уступают.

Concurrency Vizualizer

Concurrency Vizualizer — расширение для Visual Studio. К мониторингу памяти относится очень косвенно. При этом оно очень информативное, так как позволяет увидеть множество параметров по работе приложения в многопоточной среде. С помощью этой утилиты можно проанализировать, когда потоки приостанавливаются, восстанавливают свою работу и т. д.

Performance Monitor

Рисунок 8. Счетчики Performance Monitor

Какие счетчики (counter) предлагает Performance Monitor? Первый счетчик, на который стоит обратить внимание — это процент времени, которое было потрачено самим GC. Этот счетчик делает замеры между двумя сборками мусора, считает циклы процессора, циклы, которые были потрачены в общем и которые были потрачены на сборку мусора. Например, если между двумя сборками прошел 1 миллион циклов процессора и при этом из них 300 тысяч потрачено на сборку мусора, то, соответственно, наше приложение 30% времени тратит просто для того, чтобы собирать мусор.

На какое значение нужно обращать внимание? Это довольно сложный вопрос. К примеру, мы получили цифру 17. Что мне с этой цифрой делать дальше? Из опыта рекомендую обращать внимание на значение 50%. Если 50% — значит половину времени мы тратим впустую. Если это время тратится еще в дата-центрах, то тратятся деньги. И с этим надо что-то делать. Если мы видим цифру в 10 %, то для того, чтобы опустить ее на 5, нужно потратить столько денег, что даже не стоит в это вкладываться.

Следующий параметр, на который стоит обращать внимание — Allocated bytes/second. Он показывает число байтов в секунду, которые мы можем аллоцировать в памяти. Можем посмотреть, какой размер занимает нулевое поколение, первое, второе поколение, сколько занимает Large Object Heap, как перетекают объекты из нулевого поколения в первое, из первого — во второе, количество выживших объектов и т. д.

Finalization Survivors — это счетчик, который показывает количество объектов, которые ушли с очереди финализации и готовы к тому, чтобы началась их чистка.

Пример, как использовать этот инструмент, показан на рисунке 9.

Рисунок 9. Работа с Performance Monitor

Performance Viewer

На мой взгляд, это один из лучших инструментов на текущий момент. Также радует, что производители уже начали задумываться о том, что же делать с Linux, что очень актуально для приложений, написанных под .NET Core. Уже сейчас на их сайте есть небольшой туториал, как снимать метрики с докер хостов. Надеюсь, они будут продолжать развиваться, и мы получим очень хороший инструмент.

Инструмент позволяет мониторить практически все аспекты, которые нужны разработчику для анализа: CPU, стек, есть возможность сделать дамп памяти и проанализировать его, можно посмотреть статистику по GC.

Рисунок 10. Работа с Performance Viewer

Инструмент довольно простой (см. рисунок 10): нажимаем collect и собираем нужные нам метрики. Совет для тех, кто будет использовать — не собирайте метрики долго. Сделал большую ошибку: собрал метрики за минуту и потом ждал пока распарсится минут семь, потом бросил. Должно хватить 5-10 секунд, чтобы понять, что происходит с вашим приложением и что с ним делать. Инструмент может показать все, что связано с GC. На слайде выделены данные, которые касаются GC-статистики. Показывается режим GC, в котором запущено наше приложение, время, которое было потрачено на паузы GC, процессорное время, которое было потрачено, количество сборок мусора в каждом из поколений, минимальные паузы, пики.

События трассировки

Если посмотреть определение в MSDN или в литературе, то трассировка событий — это высокоэффективная масштабируемая система трассировки с минимальными затратами ресурсов, которая реализуется в Windows. Если немного заглянуть под капот, то очень грубо говоря, этот процесс выглядит так: мы запускаем трассировку наших приложений, это все ложится в обычные файлики, эти файлики потом парсятся, и мы исследуем, что происходит с нашим приложением.

Что вообще можно мониторить в .NET в среде CLR? GC, Runtime, Exceptions, Thread pool, Stack и т. д. Детально о всех метриках можно почитать здесь.

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

На GitHub есть библиотеки, которые позволяют научиться работать с данными событиями. К примеру, TraceEvent Library позволяет нам написать приложение, которое будет выполнять трассировку другого приложения. И всю эту информацию спокойно собирать, дебажить и что-то с ней делать.

На рисунке 11 показан небольшой пример, как можно запустить трассировку событий используя TraceEvent Library.

Рисунок 11. Пример кода

На рисунке 12 происходит магия в части того, как мы собираем все эти счетчики. А вот что из всего этого вышло уже отображено на рисунке 13.

Рисунок 12. Пример кода

Мы получили следующую информацию: когда у нас начал выполняться GC и сколько времени заняла пауза на GC, какая по счету сборка мусора, с каким поколением работал GC, в каком режиме работает наше приложение.

GC-визуализация

Рисунок 13. Визуализация GC

Есть довольно интересный блог, который ведет Мэт Уоррен. В нем можно найти очень много интересной и полезной информации: как работает Garbage Collection, что же происходит на самом деле «под капотом».

Рисунок 14. Визуализация GC от Мэта Уоррена

На рисунке 14 отображена визуализация работы GC, основанная на трассировке событий, написанная автором блога. Всем, кому интересно понять, как же работает GC, рекомендую разобраться с ним.

Рисунок 15. Таблица данных тестирования в разных режимах

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

Выводы

Каждый из нас рано или поздно сталкивается с проблемами неоптимальной работы написанного приложения, причины могут быть разные. При их анализе довольно часто мы не смотрим на то, как в таких случаях работает GC, как его работа влияет на работу приложения, оптимальный ли режим GC выбран именно для текущего приложения. А ведь многие ответы как раз и могут быть получены при таком анализе.

Полезные ссылки

LinkedIn

73 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

mattwarren.org/...​dotNET-Garbage-Collector
объяснение последовательности ETW событий для foreground and background GC

интересная статья. теперь любопытно, насколько различаются реализации в разных языках

Очень существенно. Можно сказать, что в них общее только то, что есть какое-то GC, которое eventually срабатывает ;)

А так, например:
A1. Удаление только по недостижимости из корневого набора: JVM, .NET, большинство LISPʼов, PyPy, Lua, Go, большинство движков JS...
A2. Удаление по обнулению счётчика ссылок и дополнительно по недостижимости: CPython.
A3. Удаление только по обнулению счётчика ссылок: PHP, как минимум до 7-го, AFAIR; Perl, если не считать не встречающийся в реале вариант остановки интерпретатора из сишного владельца.
B1. Аллокация объектов средствами стандартного распредителя libc (malloc/free, new/delete): CPython, Lua, Perl...
B2. Аллокация из собственных крупных пулов: JVM, .NET...
C1. Перемещение объектов для уплотнения занятой памяти: JVM, .NET... — обычно коррелирует с B2.
C2. Перемещения объектов нет: CPython, Lua, Perl...
D1. Ссылками считается только то, что явно прописано в структуре объектов как ссылки: JVM современные, .NET, CPython, PyPy, Go...
D2. Ссылками считается любое машинное слово в структуре объекта, которое как адрес указывает в пул («консервативный» сборщик): ранние JVM, Boehm GC для C++...
E1. Есть поколения объектов: JVM, .NET, CPython, PyPy...
E2. Нет поколений объектов: Lua, Go...
F1. Ориентация на суммарную скорость работы, полный stop-world: многие движки LISP, включая emacsʼовый.
F2. Ориентация на гладкость работы, пусть даже в ущерб суммарной производительности, GC только инкрементальный: Lua, Go, Azul JVM (хотя в Lua можно стандартными рукоятками запросто затюнить и в stop world, кому надо).
F3. «Усреднённый» между F1 и F2: большинство JVM, .NET реализация, CPython, PyPy... (вообще большинство).
G1. Критерий для срабатывания GC в жёстком пороге по памяти: ранние JVM, можно и сейчас такое делать.
G2. Критерий для срабатывания GC в превышении динамического порога (от прошлого результата): Lua, часть логики современных JVM.
G3. Критерий для срабатывания GC по счётчикам аллокаций: CPython...
H1. Из финализатора можно «реанимировать» объект, создав на него сильную ссылку: CPython, PyPy.
H2. Из финализатора нельзя «реанимировать» объект: JVM, .NET...

это сильно неполный список и только по основным параметрам, которые видны программисту на этих средствах, что сталкивается с последствиями таких особенностей.
А ещё внутри может быть своей специфики тоннами, и частного тюнинга.

В сумме, это сейчас огромный отдельный мир.

Рекомендую (там где это уместно) пути по уменьшению выделения памяти :
1. Object pooling
2. Порт LMAX Disruptor для .NET (lock free ring buffer)
3. Подправив немного код Mono можно писать числа в поток (файл) без создания экземпляров строки.

Cool .NET Profiler:
www.yourkit.com/.net/profiler

1. Насколько я понял, операция «найти все root-объекты» всё равно не решается пока без одновременной остановки всех ниток?

2. Вот к этому

а когда у нас появился первый язык, который уже поддерживал сборку мусора. Я даже немного удивился, потому что это был 1964 год.

статья про GC говорит:

> Garbage collection was invented by John McCarthy around 1959 to simplify manual memory management in Lisp.

или вы почему-то явно отвергаете этот случай?

1. Насколько я понял, операция «найти все root-объекты» всё равно не решается пока без одновременной остановки всех ниток?

STW паузы да есть.
Эта статья, как я понимаю, больше не про новшества рассказать в контексте .net, а просто рассказать как профилировать память и какие техники для оптимизиации GC доступны.

Если интересно про инновации .net смотрите .net core, core fx — там уже и веб сервера быстрые появились и векторные операции с графикой и SIMD делают на C# и перформансом меряются C++. Но это не столько GC быстрый, сколько просто api удобное не создающее GC pressure и без необходимости писать unsafe код.

Годная статья)

А можно технические статьи не из 20 а из 21 века?
Например про квантовые вычисления?

В финансах. Уже есть тут срачь в стиле — жители племени мумбу-юмбу обсуждают спутник НАСА, что к Солнцу недавно прилетел.

И вообще, что в Украине в ИТ есть из 21 века?

GC вполне себе 21й век, активно развивается.
Квантовые вычисления — ещё неизвестно, получится из них что-то полезное или нет. Пока только теория и средства решения задач, которые никому не нужны.

Без них есть чем заняться многим уже сейчас. Опять начинает всплывать тема об архитектурах компов. В текущей уже уперлись во всё, что там есть.
И мне кажется, что в ближайшее время в выч.технике будет движение в область смены архитектуры — а она может позволить ускорение многих решений раза в 2.
Причина проста — заставить память и процессор быстрее уже никак, но можно добавить больше ядер и тут мы упираемся в архитектуру железа.

Опять начинает всплывать тема об архитектурах компов. В текущей уже уперлись во всё, что там есть.

Да, реально проблема.

Фактически рост мощности остановился, а рост потребностей программ — нет. Если в 12-м году лаптоп «чтобы не тормозил» можно было добыть за 400$, то сейчас без 800 и не приближайся. Цены на ключевые компоненты типа RAM почти не упали, а местами и поднялись.
Начинаю опасаться того, что у меня текущий проект на Python, и это не запускалка каких-то numpy/etc., а на нём вся тяжёлая логика. Конкуренты могут обойти на повороте просто за счёт более быстрого языка реализации.

Начинаю опасаться того, что у меня текущий проект на Python, и это не запускалка каких-то numpy

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

Да, реально проблема.

Фоннеймановская архитектура сильно давит на реализацию многопоточности и необходимости кучи барьеров и синхронизаций. Ну и второе — это тяжесть потоков, что в винде, что в линухе. Запуск потока — это долго. В итоге с потоками приходиться изворачиваться. Поднимать пул заранее и в пуле уже обрабатывать задания и т.п. навороты.
И переход на гарвардскую уже многое бы облегчил и ускорил. Но и это половинчатое решение.
Вопрос вообще в коммуникациях между ядрами и памятью, структурой памяти. Для многих задач хорош GPGPU, но там 2 проблемы — коммуникация с ним и скорость самих ядер. Причем первая — это конретные тормоза и нехилое добавление сложности к программе, чтобы обойти это узкое место — шину. А широкая шина стоит очень дорого.

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

Поднимать пул заранее и в пуле уже обрабатывать задания и т.п. навороты.

И в чём там «навороты»? Ты решаешь задачи массовой коммуникации когда миллионы леммингов ломятся на десятки ядер и каждый лемминг мелкий настолько чтобы даже на йоту загрузить ядро но их миллионы? Или у тебя чистая числодробилка где задачу порезал на куски раздал всем десяти ядрам и они знай себе молотят а момент «разрезал на части и раздал» по времени существенно меньше чем сама задача?

Или у тебя просто старость и от морозов суставы ломит и ты ворчишь? ))

Вопрос вообще в коммуникациях между ядрами и памятью, структурой памяти.

Что у тебя за задачи такие что у тебя узким местом становится коммуникация с памятью а не вычислительная мощность ядер? Ты определись с задачами то ))

чтобы обойти это узкое место — шину.

Эта «шина» работает на 10 гигабайт в секунду на современных «бытовых» реализациях если ты вычислительно успеваешь проглатывать такой поток данных (а ведь его ещё надо откуда-то читать и куда-то писать) то может у тебя вычисления не настолько суровы и даже одного ядра хватит с головой?

обработка видео ... чтобы вписаться в реалтайм

Это что за задачи такие? Встроенную рекламу на ютубе в 4К клеить?

Или у тебя чистая числодробилка где задачу порезал на куски раздал всем десяти ядрам и они знай себе молотят а момент «разрезал на части и раздал» по времени существенно меньше чем сама задача?

Если бы так всё просто было. Это в твоей голове существует только 2 варианта, что ты написал, а в реальном мире много и другого есть.

Что у тебя за задачи такие что у тебя узким местом становится коммуникация с памятью а не вычислительная мощность ядер? Ты определись с задачами то ))

Обработка видео. А частности треккер объектов на видео. Сейчас вот пытаюсь сделать самообучающийся. Например для pdist2 пришлось заюзать MKL BLAS, но и он не удовлетворяет меня по скорости, нужно уменьшать количество векторов и оценивать при каком уменьшении качество не упадет, причем и придумать как это уменьшать (придумать решение, как определять менее значимые и более значимые фичи). kNN будет быстрее, но с ним и химичить много надо, влоб не работает так, как мне нужно.

Встроенную рекламу на ютубе в 4К клеить?

4K — это сейчас фантастика. FULLHD — это предел, где еще можно, исхитрившись вложиться в реалтайм.

Если бы так всё просто было. Это в твоей голове существует только 2 варианта, что ты написал, а в реальном мире много и другого есть.

а ну ок ))

но математика на нем или что-то другое посложнее — это гарантированные тормоза.

У меня там обработка сложных развесистых структур, поэтому C/C++ заметно не в тему. Требуется что-то managed.

И переход на гарвардскую уже многое бы облегчил и ускорил.

Эээ... ты ничего не путаешь? Гарвардская в отличие от принстонской — это всего лишь принципиальное разделение памяти программ и данных. В таких задачах это разделение или нереально, или бессмысленно. Эмуляцию гарварда через разделение сегментов кода и данных (как в 8086) и через права на страницы — нельзя считать чем-то существенным.

Нет, это позволит ускорить работу с памятью. Там еще разделение на чтение и запись для памяти на уровне железа возможно. А это уменьшит количество барьеров, но и к шине удорожающие ее требования прилагаются.

Простое разделение на 2 и больше независимых канала памяти даст результат лучше и гибче.

Возможно, я не спорю. Но это уже не чисто фоннейманская архитектура будет.
Но это потребует расширения шины или двух шин и контроллера.
А как я понимаю — это наибольшая сложность в архитектуре современного железа — расширять шины или увеличивать их количество.

Так «не чисто фоннеймановская» сейчас фактически везде. Добавь несколько ядер и неоднородную память — всё, приехали.
И многоканальному доступу к памяти даже в x86 уже лет 20, первые материнки с «ставьте модули одинаковыми парами, будет заметно быстрее» я помню для P-III.

А как я понимаю — это наибольшая сложность в архитектуре современного железа — расширять шины или увеличивать их количество.

Это как раз отработано. См. как Intel меняет сокет каждые пару лет :)

Но суть то программинга не изменилась.

Тебе шашечки или ехать? ))

ЗЫ: что тебе вообще до «архитектуры современного железа»? да и «сложности» как уже было сказано никакой особой нет вот тебе «расширенная слотовая архитектура современного железа» в которой «ядра делятся» уже по двум уровням сперва «по ядрам» а потом ещё и «по слотам» и каждый свой отдельный слот по сути имеет свою отдельную оперативку и соотв. ты свои расширения с параллелизацией можешь масштабировать ещё на +1 уровень до 4-х слотов за раз насколько я помню опять же ж на худой конец можно перейти к кластерной архитектуре где масштабирование задачи зависит уже только от возможности её разбиения а каждая отдельная нода на «+1 масштабируется» чисто линейно а опять же ж входной балансировкой заниматься можно и нужно а входные каналы у тебя вряд ли выходят за пределы 1 гигабит которого пока ещё достаточно для передачи full-hd даже в непожатом виде если аккуратно немного ужаться... хотя нет стоп вру даже 100 мегабит хватает да?

Дай ссылки. Почитать интересно и как это в программинге юзать.
Только не про кластеры на толпе компом — это отдельный вопрос.

язать что? load balancing? вот прямо по словам гугли и дальше уже разворачивай что становится тебе ближе и твоей теме «теплее» общий принцип там прост скажем «на пальцах» тебе на вход заходят кадры 1-2-3-4-5 ты их просто по очереди разбрасываешь на 4 ноды которые уже «чисто параллелятся» и «обсчитывают» каждая соотв. по кадру причём эта штука масштабируется почти линейно.

Если ты про слоты многопроцессорных системы то это NUMA опять же ж гуглить прямо по нему и дальше по тому же ж принципу «что тебе ближе по теме».

ЗЫ: более того насколько я понимаю есть специальные пакованы из реально 100500 ядер вроде как даже какого-то уровня ARM которые на такие штуки «сверхпараллелизм» как раз и заточены честно не помню для чего это они но вроде как есть но тут таки «помню вроде видел» и «мне кажется (помню вроде видел)».

На NUMA обращу внимание. Что-то интересное.

Своєчасно підвозити дані з пам’яті — найбільша проблема. Шини можна зробити широкими-широкими, тільки вони будуть жерти струм та нічого особливо корисного не робити.

У вас что-то в консерватории надо менять )) у меня компы 12-13 г.г. всё отлично работает конечно немного жалею что летом не закупился новыми 6-ядерными и5 но в целом может и правильно потому что новые ядра уже есть и они уже лучше.

Насчёт «лаптопов» где-то в 2008-м я покупал свой первый не самый мощный но достаточный тогда даже без ССД )) и это стоило $800 этим летом я покупал «бизнес класса» уже и5 уже ИПС уже фуллХД уже ССД уже «16 гигов с каропки» и это стоило уже чуть больше $700.

ЗЫ: хотя должен признать эти «по $700» на решиться стоили мне как-то психологически сильно дороже чем тогдашние $800 может и у вас там такая же ж «чисто субъективно психологическая фишка» вроде «раньше трава была зеленее а теперь каждый может пойти и купить» ))

Котиков лайкать и на 386 можно было и ничего не тормозило.
И да, простой EM для GMM там тормозил, вот и юзались симбиозы векторного квантования и иерархической кластеризации.

Котиков лайкать и на 386 можно было и ничего не тормозило.

Если просто котиков лайкать — да :) а если через фейсбук — нет, он способен даже HPC кластер затормозить до уровня того же 386.

ой чувак выдыхай! )) на улицу выйди там наверное снег и бабы! ну или котиков сходи полайкай или хотя бы б тот же ж ютуб запусти с котиками и узнаешь чем «котики» времён 386-го (без интернета ага ага) отличаются от «котиков» 2018-го уже с интернетом и прочими наворотами современного «обычного сайта для лайкания котиков».

ЗЫ: ты просто пропустил всё проблема перехода на нормальное отображение видео full-hd на компе стояла вот всего ничего лет 6-8 тому назад и в полный рост а ты говорить «котики на 386-м».

У вас что-то в консерватории надо менять ))

Как минимум веб-страницы стали прожорливей раза в два по всем параметрам (память, процессор и т.п.)
И менять это надо не у меня, а у фронтэндеров.

Вот запрос — я разве хочу чего-то особенного? Просто такую машинку, чтобы не надо было выбрасывать через 2 года.

уже фуллХД уже ССД уже «16 гигов с каропки» и это стоило уже чуть больше $700.

Точную модель покажете?

субъективно психологическая фишка

Нет.

Как минимум веб-страницы стали прожорливей раза в два по всем параметрам (память, процессор и т.п.)

в 2012-м у меня была машинка которая на самом деле nas но попутно раз уж была и (временно) пользовалась в качестве «компа для котиков» что интересно её хватало для всего включая видео (там какой-то amd стоит со встроенной графикой и всякими процессорами для видео ну так получилось) и вот она была отложена уже как чисто nas и закуплена новая потолще именно только потому что «средняя веб-страница» уже где-то 13-го года стала «укладывать» тот бедный проц на все 4 лопатки ))

Ну а я о чём :(
При этом реально рост производительности на доллар остановился (не закон Мура, но близко), лет 10 хватило запаса, чтобы вылизывать откровенный тяп-ляп ранних разработок, а теперь и этот кредит потрачен.

Ну а я о чём :(

я полагаю ниочём ))

там была специальная платка со встроенным процессором и радиатором без вентилятора она расчитывалась только на шуршание дисками и временно использовалась «в качестстве компа» и её в принципе хватало что говорит об том что даже такого «в принципе хватает чтобы использовать в качестве компа».

На планшете проц поди сильно послабше и ничего его тоже хватает.

Точную модель покажете?

х.з. какой-то lenovo thinkpad точно знаю что 14 дюймов и не «480» а либо «460» либо «470» возможно фишка и была в том что «типа распродажа прошлогодней коллекции» х.з. я сильной и вообще разницы в новом как раз не увидел.

Просто такую машинку, чтобы не надо было выбрасывать через 2 года.

х.з. я пока не предвижу чтобы из кейзов куда вообще нужен в эксплуатацию ноут его пришлось бы б «выбрасывать через 2 года» по-моему он даже 4К через hdmi умеет но я не проверял что ещё такого может понадобиться в ближайших 2-5 лет чтобы «надо выбрасывать»?

что ещё такого может понадобиться в ближайших 2-5 лет чтобы «надо выбрасывать»?

Просто современная производительность на уровне прожор от IT.

мало что понял из этого выражения простите )) у меня ноут это то что возится с собой и решает конкретные задачи «то что возится с собой» собственно всё.

Кратче говоря он тупо рубит бабло как скажем машина с рулём можно взять тойота кемри можно взять ауди а4/а6 а можно и тупо шевроле какой-то как там он называется за 10 тыщ он ездит и достаточно хорош в т.ч. на дальние броски остальное меня не волнует ))

у меня ноут это то что возится с собой и решает конкретные задачи «то что возится с собой» собственно всё.

Ну у меня >50% это скорее не возить с собой, а лежать на диване.

ожно и тупо шевроле какой-то как там он называется за 10 тыщ

Вот если бы сравнил с запорожцем на 30 л.с. — тогда это было бы адекватно нынешней обстановке с этой техникой.

Ну у меня >50% это скорее не возить с собой, а лежать на диване.

купи телик и ps4 и будет тибе щасте ))

Вот если бы сравнил с запорожцем на 30 л.с. — тогда это было бы адекватно нынешней обстановке с этой техникой.

не было бы б ну та ок.

Я типа в курсе что в Родине есть только 2 (два) типа машин 1) БЧЖ и 2) ланос в убер такси.

купи телик и ps4 и будет тибе щасте ))

«Ты что, издеваешься?» (© некто Alex Fogol)

Чем мне они помогут лениво браузить/кодить лёжа под одеялом?

браузерить умеет даже сам телик а кодить а зачем тебе? )) под одеялом не кодить надо кодить надо не здесь! ))

> а кодить а зачем тебе?

Почему нет?

не ну в принципе ты прав в наши дни любой конечно может кодить только потому что «почему нет?» ))

ЗЫ: но плейстейшин лучше!!!

х.з. какой-то lenovo thinkpad точно знаю что 14 дюймов и не «480» а либо «460» либо «470»

вот кстати я смотрю есть такие только памяти 8 гигов что в целом некритично.

16999 грн это сейчас $600 в эквиваленте.

hotline.ua/...​d-e470-20h1006mrt/prices

14 дюймов — за пределами ограничений, что я задавал.

В остальном, да, вкусно (особенно максимум RAM). Себе бы я такой вполне взял (но с условием, что какой-то линукс на нём уже запущен — а у этого конкретного DOS).

(но с условием, что какой-то линукс на нём уже запущен — а у этого конкретного DOS)

ты что издеваешься? ))

Объясни, что тебя не устраивает.

ну не знаю я бы б не сказал что «это меня не устраивает» то что ты не можешь запустить линукс на «голом» ноуте )) скорее даже наоборот ведь тогда мне работы и прочей экспертизы и соотв. денюжки больше достанется!

ЗЫ: чтобы хватило и на диван и на плейстейшин и на одейско хехехе ))

ты не можешь запустить линукс на «голом» ноуте

Смешные у тебя домыслы.

Телик лучше брать от 55 дюймов и 4К ты мне поверь ))

Не поверю, у меня нет «телека» лет 15.

а зачем тебе тогда диван? ))

Без телевизора? Ого... тут хоть салом хоть закусывай хоть незакусывай а суровости бытия уже не скрыть ))

Вот запрос — я разве хочу чего-то особенного?

х.з. я делал так + thinkpad я знаю ещё по IBM когда они были вообще первыми ноутами вообще )) хорошая бизнес машинка достаточно годно показала себя в эксплуатации «другие варианты» рассматривались скорее «формально ну а вдруг».

ЗЫ: маки хороши конечно но последние модели чутка стрёмные ну и решено что дорого и не стоит того для чего это покупается.

hotline.ua/...​724-362379-388371-567537

заставить память и процессор быстрее уже никак

энергонезависимая память может повлиять на архитектуру

О да. Сейчас только регулярные рестарты всего позволяют софту хоть как-то нормально работать.
А когда и этого лишат... мир точно рухнет за пару лет.

А по мне так наконец-то четко расписанная и хорошо оформленная статья. Я приплюснытый, так что мне инфа эта постольку поскольку, но мне кажется, что для новичков в NET статья будет полезна

столько воды чтобы сказать что серверный режим есть...

хабр переехал на доу или я что-то пропустил?:)

По мне так такие статьи интереснее, чем про сырыпопиццот.

Рассказано, какие есть GC в NET и как за ними следить. Написано и оформлено хорошо — это тут редкость. У большинства статей такой я зык, что ощущение, что марсианин вчера язык увидел и набредил на нем. У многих, которые, если и можно читать и не ломать мозг, с картинками полная жопа.

Не могу сказать за суть и материал статьи, это вам дотнетчикам виднее, но сама статья написана хорошо и оформлена прилично.

чем про сырыпопиццот

А что такое хабр? Это тот сайт для тех, кто английский не осилил чтобы первоисточники читать?

За первоисточниками гоняться надо и фильтровать их.
А хабр, кроме перевода, неплохой фильтратор.
К тому же — я, например, не боюсь английского, но читать на нём элементарно медленнее: на русском и украинском могу читать даже не «по диагонали», а вообще «по вертикали», чтобы схватить общий смысл и понять, надо ли вчитываться в конкретный абзац. Для английского так не получается.
Поэтому — хабр в обязательном чтении, просто чтобы быть в курсе «о, и об этом говорят».

Именно. Хабр мне нравиться тем, что там часто на новинки ссылки в заметках дают. Самому за всем не уследить.

на русском и украинском могу читать даже не «по диагонали», а вообще «по вертикали», чтобы схватить общий смысл и понять, надо ли вчитываться в конкретный абзац.

так может фишка в том что остальный абзацы и писать-то не надо? ))

Там таки есть содержание ;)

Подписаться на комментарии