Отступление: то, что ОС не имеет значения для производительности, в общем , очевидно, ложно. Ссылка на загрузку ЦП во время простоя мне кажется довольно «своеобразной» идеей: конечно, можно надеяться, что когда не выполняется ни одно задание, ОС не тратит впустую энергию. В противном случае измеряют скорость / пропускную способность ОС, когда она предоставляет услугу (т. Е. Обеспечивает доступ к оборудованию / ресурсам).
Чтобы избежать назойливой MS Windows против Linux против Mac OS X битва, я буду ссылаться на концепцию исследовательской ОС: exokernels . Суть exokernels заключается в том, что традиционная ОС является не только посредником для доступа к ресурсам, но и реализует политики . Такие политики не всегда способствуют повышению производительности вашего режима доступа к ресурсу. С концепцией exokernel исследователи предложили « уничтожить все абстракции операционной системы » (.pdf), сохранив за собой роль мультиплексора. Таким образом :
& hellip; Результаты показывают, что обычные немодифицированные приложения UNIX могут пользоваться преимуществами exokernels: приложения либо работают сравнимо с Xok / ExOS и BSD UNIX, либо работают значительно лучше. Кроме того, результаты показывают, что настраиваемые приложения могут существенно выиграть от контроля над своими ресурсами (например, с коэффициентом 8 для веб-сервера). & Hellip;
Таким образом, обходя обычные политики доступа к ОС, которые они получили для настроенного веб-сервера, увеличение производительности составило около 800%.
Возвращаясь к исходному вопросу: * обычно верно, что приложение выполняется без или незначительными издержками ОС, когда:
- имеет ядро с интенсивными вычислениями , где такое ядро не вызывает API-интерфейс ОС;
- памяти достаточно или доступ к данным осуществляется таким образом, чтобы не вызывать чрезмерного подкачки;
- все несущественные службы, работающие в одних и тех же системах, отключены.
Возможны и другие факторы, в зависимости от оборудования / ОС / приложения.
Я предполагаю, что ОП верен в грубой оценке требуемой вычислительной мощности . ОП не определяет природу таких интенсивных вычислений, поэтому трудно давать предложения. Но он написал:
Сумма Расчеты огромны
«Вычисления», по-видимому, намекают на вычислительно-интенсивное ядро , для которого, я думаю, требуется скомпилированный язык или - быстрый интерпретируемый язык с операторами нативных массивов, например APL , или современный вариант, такой как J , A + или K (потенциально, по крайней мере: я не знаю, используют ли они преимущества современного аппаратное обеспечение).
В любом случае, первый совет - потратить некоторое время на изучение быстрых алгоритмов для вашей конкретной задачи (но при сравнении алгоритмов помните, что асимптотическая запись не учитывает постоянные факторы, которые иногда не являются ничтожными ).
Для последовательной части вашей программы хорошее использование кэшей ЦП имеет решающее значение для скорости. Посмотрите на алгоритмы кеширования алгоритмы и структуры данных.
Для параллельной части, если такая программа поддается распараллеливанию (помните как закон Амдала и закон Густафсона ), существуют различные виды параллелизма рассмотрим (они не являются взаимоисключающими):
- Параллелизм на уровне инструкций : об этом заботится аппаратная часть / компилятор;
- параллелизм данных :
- битовый уровень: иногда для такого параллелизма используется акроним SWAR (SIMD в регистре A) .Для задач (или некоторых их частей), где может быть сформулировано представление данных, которое может быть отображено на битовые векторы (где значение представлено 1 или более битами);поэтому каждая инструкция из набора команд потенциально является параллельной инструкцией, которая работает с несколькими элементами данных (SIMD).Особенно интересно на машине с 64-битными (или большими) регистрами.Возможно на CPU и некоторых GPU .Поддержка компилятора не требуется;
- мелкозернистый средний параллелизм: ~ 10 операций параллельно на процессорах x86 с SIMD расширениями набора команд, такими как SSE преемники, предшественники и тому подобное;требуется поддержка компилятора;
- мелкозернистый массивный параллелизм: сотни операций параллельно на GPGPU (с использованием обычных графических карт для вычислений общего назначения), программируемых с помощью OpenCL (открытый стандарт), CUDA (NVIDIA), DirectCompute (Microsoft), BrookGPU (Стэнфордский университет) и Intel ArrayСтроительные блоки .Требуется поддержка компилятора или использование выделенного API.Обратите внимание, что некоторые из них также имеют серверные части для инструкций SSE:
- грубый скромный параллелизм (на уровне потоков, а не отдельных команд): это не является необычным для CPU на текущемнастольные ПК / ноутбуки, чтобы иметь более одного ядра (2/4) в одном и том же пуле памяти ( shared-memory ).Стандарт для параллельного программирования с общей памятью - OpenMP API , где, например, в C / C ++, директивы
#pragma используются вокруг циклов.Если я не ошибаюсь, это можно считать параллелизмом данных, эмулируемым поверх параллелизма задач;
- параллелизм задач : каждое ядро в одном (или нескольких) процессорах (s) имеет свой независимый поток выполнения и, возможно, работает с различными данными.Здесь можно использовать понятие «поток» напрямую или модель программирования более высокого уровня, которая маскирует потоки.Я не буду вдаваться в детали этих моделей программирования здесь, потому что очевидно это не то, что нужно OP.
Я думаю, этого достаточно для того, чтобы OP самостоятельно оценил, как различные языки и их компиляторы / среды выполнения / интерпретаторы / библиотеки поддерживают эти формы параллелизма.