potwierdzam wszystkie testy
@Paweł Jasiak
mialem taki sam blad ;-)

Podobnie jak kolega wyżej mam wątpliwości co do tych testów, średni czas 0.5s.

Dla amatorów mniejszych k: wykonałem testy Marcina wymuszając k = 2 lub 3 (zignorowałem resztę wejścia). W outach wypisana odległość: http://students.mimuw.edu.pl/~mw277619/small_out.rar

@Piotr Godlewski - mam wątpliwości co do testów 6-8 oraz 28.
Pozostałe potwierdzam.

Również potwierdzam wszystkie testy.

Potwierdzam testy Maćka i Wojtka.

To wogóle możnaby sprytnie na jednym rdzeniu zasymulować.

Trzeba by:
- sprytnie pilnować czasu zegara w każdym wątku (zegar[i]),
- zawsze wątek z najstarszym zegarem odpalać (ten z min zegar[i])
- puszczać wątek i-ty aż zużyje (timelimit-zegar[i]) czasu (jeśli tak to TLE) albo się zablokuje (na jakimś receive, zakładam, że bufory są na tyle duże że send się nie blokuje)
- zegar[i] += ile_czasu_procka_zużył

Oczywiście komunikaty międzymaszynowe trzeba ostemplowywać czasem zegarowym (wysyłającego wątku) w momencie ich wysłania i nie można ich dostarczyć przed tym czasem.

Jeśli w pewnym momencie wszystkie wątki czekają na dane, to patrzymy na zakolejkowane wiadomości, które można by dostarczyć (tzn. ktoś na nie czeka), spośród nich bierzemy tą którą można najwcześniej dostarczyć, docelowy procesor przeskakuje w przód w czasie do momentu wysłania/dostarczenia wiadomości, wiadomość dostarczamy i kontynuuje się zabawa.

Jeśli w pewnym momencie wszystkie wątki czekają na dane i nie ma nic do dostarczenia do się program zakleszczył i jest TLE.

(albo jakoś takoś)

Rozumiem ze mowimy o tescie:

4 3 3
1 1 1 1

3 2
4 2
2 1

4 2
3 2
1 3

wpierw laczymy 3+2 i to reaguje, powstaje 2 osadu, zostaje 1 0 0 1, nie zaleznie od tego co zrobimy to 1+4 nie przereaguje bo nie ma takiej reakcji, wiec wynik to "2".

--

nb. Potwierdzam wszystkie testy (czasy do 0.6s).

Mogłyby być dopuszczone wątki przy zadaniach rozproszonych... skoro i tak rozpraszamy. Oczekiwanie na dostarczenie wiadomości nie blokowałoby maszyny.

Mój błąd, przepraszam masz rację ;D

Michał Szostek sprawdzając twój test na kartce wydaje mi się że poprawną odpowiedzią jest 4.

Z drugiej strony gdyby Receive() nie zużywało procesora to można by pomyśleć o takim kontrprzykładzie:

1. instancja coś liczy i wysyła wynik do instancji 2.
i. (1<i<n) instancja odbiera od i-1, coś liczy i wysyła wynik do instancji i+1.
n. instancja odbiera od n-1, coś liczy i wypisuje wynik na stdout.

W takim wypadku max czasów procesora byłby stały i zależał tylko od czasów obliczeń, natomiast ciężko mówić tu o jakimkolwiek zrównolegleniu (tylko jedna instancja coś liczy w danym momencie).

IMHO najlepiej byłoby żeby Receive() nie wisiało na procku, ale czas trwania był liczony z zegara a nie z procesorów.

Potwierdzam outy Piotrka i te dwa testy wrzucone przez Wojtka. Odnośnie sytuacji z nieudostępnieniem wyjścia do testów Konrada to w paczce, którą udostępniłem dodałem test, który moim zdaniem pokaże mu gdzie ma błąd. Brak odpowiedzi na jego testy wynikał z czystego lenistwa, a nie złośliwości :)

A czy tym, co tutaj wrzucali outy działa na tych testach wklepanych z palca?
In:
9
3 5 3 4
3 4 3 5
4 6 4 5
5 6 2 4
2 4 2 3
2 3 4 6
5 7 5 6
6 7 1 3
1 3 1 2
Out:
1
1 7 1 6

In:
12
11 13 1 2
12 13 1 3
3 6 2 3
3 4 2 5
7 10 4 5
9 10 4 7
5 6 6 9
5 8 8 9
1 2 8 11
1 4 10 11
11 12 10 13
9 12 12 13
Out:
1 13 1 13

Potwierdzam testy Piotra.