О смысле всего сущего

...при свопе вообще на винт мапится... грамотная политика раскидывания выделенной памяти -- и вполне даже ничего так можно будет потоки разводить. Не, ну и по гигабиту можно такое написать, но PCIe на порядок лучше и по bandwidth, и по latency. Короче, разложу всё по полочкам. Поднять такую фишку можно хоть по RS-232, и она даже будет работать, мапить память и разводить потоки по машинам. Вопрос только в том, какой процент ПО это будет использовать, а какой система оставит на одной машине, потому что потери в скорости на передаче данных по факту окажутся больше потерь от ожидания освобождения ядра/несвопанной памяти на локальной машине. Если потоки часто обмениваются небольшими объёмами, то есть тупо синхронизируются постоянно -- без хорошей latency начнутся лаги, система вздохнёт и вернёт поток к его братьям, потому что фактическая производительность упадёт. Если потоки редко обмениваются большими объёмами, важна bandwidth, без которой тоже начнутся лаги, и система грустно вернёт поток к тем, которые ему эти данные поставляют -- подождать свободного ядра стало дешевле, чем гонять данные для/от этого потока. Что своп, что кэши давно работают по похожему принципу. Смотрят по факту обращений, что поближе держать, что подальше. Для проги это прозрачно, прозрачным будет и маппинг по многомашинной системе. Он чуть посложнее просто политики кэширования, но принципы в общем те же. Забавно то, что запуск ПО, не требующего мощного экранного вывода, на слабой машине при свободной мощной (ну мало ли, у слабого ноута моник ярче %) при такой политике должен тупо и быстро вытеснить ВСЮ задачу на мощную машину, переведя их интимные отношения почти что в разряд удалённого рабстола %) У меня есть целая одна программа, которую такая система даже через 10Мб локалку бы выставила на другую машину: там поток всего два раза в секунду с остальными контачит, получает 10 килобайт и отдаёт полмегабайта, а остальное время ворочает сам в себе вышмат. Остальные тоже не ворон считают, да и он такой индивидуалист там не один, так что раскидались бы весьма бодренько. Так что принципиальная возможность, на которую я чуть выше опрометчиво наехал, конечно, существует. Можно сделать на гигабитке. Вопрос в том, какой процент парка ПО этим по факту воспользуется, и какого, так сказать, жанра будет это ПО. По гигабитке -- скромный % и в основном всякие тяжёлые фотожопы. По PCIe -- почти всё, даже большинство игрушек. Соответственно, и ширина рынка сбыта-с... Подход к разработке ИМХО довольно банальный: у приложения есть полный объём адресного пространства, в нём данные и код. Что-то можно замапить в реальную раму, что-то в своп, а что-то в память удалённой машины (если совсем всё плохо, там система тоже может что-то вынести в локальный своп, прозрачно или непрозрачно для нас -- пока не суть важно). Естественно, код, замапленный в память удалённой машины, и исполняться начинает тоже на ней (тут есть узкое место с программами, которые определяют возможности проца перед всей работой, а не перед входом в некий оптимизированный участок -- и вдруг проц меняется на ходу, ну да им же можно, памятуя о такой возможности, подсунуть фейковые параметры проца на основании известных данных о машинах в кластере, чтобы работало по гарантированному минимуму). Для этого в основном мы его туда и выносим, не для экономии же памяти. Данные, к которым он часто лазает, туда же перемапливаются. Дальше балансируем нагруженностью и смотрим на межпотоковый обмен, возможно, по факту загруженности шины что-то придётся пересунуть по-другому. Обычная задача оптимизации с открытым финалом. Можно ли таким образом как-то хитро для многопоточника раздвинуть границы 4Гб для 32-битного режима -- сомневаюсь. Если бы было можно, это уже в PAE бы сделали.