Async Programming Cache Agnostic (Scala и другие языки) - PullRequest
0 голосов
/ 22 декабря 2018

Это может быть открытым вопросом, но я начну с языка scala.Scala поддерживает асинхронное программирование.Под Scala будущее - ExecutionContext, который мы можем рассматривать как задачу forkJoinPool, так и поток ThreadPool.Это означает, что некоторый код в другом контексте фактически выполняется в том же потоке, но в том же стеке вызовов код будет разбит на части в разные потоки.Как мы все знаем, все современные процессоры имеют кэш L1 / L2 / L3, если код может использовать кэш L1 / L2 / L3 будет быстрее, чем чтение из основной памяти.Но поскольку асинхронное программирование, один и тот же контекст будет находиться в разных потоках, поток может / не может выполняться в одном и том же процессе, код не может использовать кэш в другом Future, теперь вопрос заключается в том, что асинхронное программирование может выполнять код более эффективно,Разбиение длинного звонка на мелкие кусочки, но это выгодно для чтения кода из кэша процессора.Хорошо это или плохо, или мое понимание совершенно неверно.

1 Ответ

0 голосов
/ 22 декабря 2018

Вы правы, что это слишком широко для этого форума, но вот некоторые комментарии.

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

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

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

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

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

...