Средства и методы разработки

Жаль, что с многомашинными конфигурациями пока как-то глухо… их даже в пределах одной материнки можно было бы реализовать из «чисто одинарных» камней. Просто к материнке добавить несколько «наноматеринок» из камня и памяти, связанных с главной по PCIe, и загрузчик, который умеет только высасывать бутовый образ от главной. Взаимно видеться они могут, скажем, как сверхскоростная сеть, например. Т. е. на главной поднимается что-то типа ПХЕ, собирается загрузочный образ с каким-нибудь консольным линухом, суётся туда серверная часть своей ненаглядной программулины и слепоглухонемые наноматеринки подсасывают этот образ стандартными средствами сетевого бута. Получается кластер, по которому можно сетевые пакеты гонять со скоростью PCIe, что резко облегчает распараллеливание задачи почти до уровня обычного многопоточника. Ну, латентность повыше из-за всей этой прослойки виртуальной сети. Но всё равно гигабайт данных тому камню отдать, гигабайт данных этому кинуть — уже не вопрос. И сотнями метров промежуточных на лету обмениваться. Но ещё больше мне нравится идея «null-PCIe» соединения, чтобы полноценные материнки эдак вязать :) Я уже рассказывал, типа на ночь ушли работники, а их машинки вяжутся кластером не по гигабитной сети, а прямо по PCIe, и там такая зверь-машина получается, что можно инопланетян искать вместе с экзопланетами :) Ну, только что рабочие места придётся делать в общем корпусе (ибо длина связей PCIe), но в офисных условиях не проблема же. Там я, помнится, домечтался до того, чтобы специальным драйвером делать виртуальные ядра, которые реально на соседней машине, а данные туда и обратно подкидываются, как своп. И политика, как у свопа — то, что много друг с другом обменивается, держим на одной машине, те процессы, которые обмениваются редко — прозрачно для них самих разносим по разным машинам. Не все процессы такое стерпят, но закон 20%/80% не дремлет.