Wykorzystując uruchomienia próbne poeksperymentowałem z prędkością komunikacji. Biblioteczka z gotowca, małe dane, niecałe 100kb danych (BTW. tyle pozwalają przesłać).
komputerów - ms
1 10 (inna wersja programu, bez używania komunikacji)
10 14
20 20
50 31
100 52
Bardzo ładnie układają się w linię.
Dodatkowo na 100 komputerach i danych wielkości 42 - 51ms

Program był liniowy, wszystkie instancje (wliczając o indeksie 0) wysyłały do komputera nr0 4 liczby int64_t (32 bajty), pierwsza maszyna je odbierała (wymuszając kolejność, skończyły się próby na wersję Recive(-1)) i obrabiała liniowo.

W metameriach potyczek o zadaniach rozproszonych można znaleźć benchmarki.
10 20 50 100
chain 0.11 0.15 0.32 0.59
chain-multi 1.60 1.98 2.85 3.45
chain-big 0.77 1.56 3.72 7.32
star 0.12 0.14 0.24 0.31
star-big 0.52 0.99 1.88 3.48

Po ich znalezieniu przestałem się dziwić, dlaczego mój program jest taki wolny, a zacząłem, dlaczego ta komunikacja jest taka wolna. Od biedy mógłbym przepisać na mpi (open albo chyba łatwiej opakowanie z boost) ale posta napisać jeszcze łatwiej;) do tego rozsądne sprawdzenie odbyłoby się na 4 instancjach ze wspólną pamięcią, nie o to chodzi.

Syntetyczne benchmarki samego openmpi sugerują znacznie większe prędkości.
http://www.open-mpi.org/performance/v1.9/2013/mustang/

Skąd więc bierze się ten narzut. Tak być musi i będzie, bo [coś np o architekturze sieciowej], czy jest to celowo dopisane opóźnienie mające podnieść jakość rozwiązań?

Czy z tego wynika, że w rozwiązaniu zadania z rundy rozproszonej trzeba będzie uwzględniać stopień wykorzystania komunikacji między komputerami w zależności od rozmiaru danych?
Chyba nie o to chodzi w programowaniu rozproszonym.

Raczej nie. Nawet dla mikroskopijnych danych limity to coś rzędu sekundy. Komunikacja między stoma instancjami rozwiązującymi zadanie dla 7 ;-) czy 40 liczb mieści się w takim limicie.

Pytanie jest bardziej na boku, czy MPI tak ma, czy to celowe uatrakcyjnienie rozgrywki.

Edit: W sumie nie wiem, czy można się zgodzić z ostatnim stwierdzeniem. Branie pod uwagę prędkości działania sieci i dobieranie liczby węzłów do potrzeb jest jak najbardziej elementem prawdziwego programowania rozproszonego. Co najwyżej przez warunki konkursu (spore limity dla małych danych) można tę kwestię olać.

No racja. Nie przemyślałem swojego wniosku.
A co do konkursu, to miejmy nadzieję, że rzeczywiście limity będą tak dobrane, że nie trzeba będzie brać pod uwagę szybkości komunikacji.

Edit:
Teraz zauważyłem, że są wyniki z rundy próbnej. Limity są ok. W swoim rozwiązaniu nie uwzględniłem stopnia wykorzystania komunikacji w zależności od wielkości danych i przeszło 10/10.