Ostatnie posty

Podrzucam wieeele małych testów dla N <= 20.

Plik wejściowy: pleX.in, wyjściowy: pleX.out, 1 <= X <= 50000. Dla X > 40000 wartości współrzędnych są małe.

http://speedy.sh/SUfAU/ple-small.tar.gz

Potwierdzacie? ;)

// Edit: brakuje ple42773.out, odpowiedź to:
// 1
// 1 23 3 23
Również potwierdzam wszystkie testy :)
Cholera, zgłupiałem. Ten też się nie otwiera. Myślałem, że coś z 7z. Odinstalowałem, ściągnąłem nowy, zainstalowałem - to samo.
Czyżby coś z tym cholernym Win7??
Odnośnie generowania - za słaby jestem na takie rzeczy.
Wy wszyscy poruszacie się dla mnie na niebotycznych wyżynach fachowości, o których nawet nie marzę.
Pierwsza paczka spakowana 7zip'em: http://www.speedyshare.com/A7yH7/cia-tes.7z
A co do testów z mniejszym k, to możesz wygenerować swoje i wrzucić chętnie przetestuję :)
Prośba cd.
Albo kilka pojedynczych, najprostszych Z PARZYSTYM k, wrzuconych do jednego pliku.
L. P.
Prośba do Marcina:
Czy mógłbyś spakować te testy czymś innym (7-zip?) i udostępnić?
Nie mogę rozpakować Twojego tar-a (komunikat 7-zip: 'Nie można otworzyć pliku cia-tes.tar jako archiwum').
Z góry dziękuję,
L. P.
Potwierdzam.
Każde TLE było puszczone przez system 3 razy. Istnieje dość niezaniedbywalny koszt podnoszenia liczby 3.
Paczka losowych max testów (W outach podane są jedynie odległości, za względu na mnogość poprawnych odpowiedzi)
http://www.speedyshare.com/XaKta/cia-tes.tar.gz
Ktoś potwierdzi/zaprzeczy?
Chętnie też poznam wasze czasy, ja mam rzędu 2-2.5s.
Podrzuciłby ktoś jakieś mniejsze testy poprawnościowe?
Outy Piotra są dobre, a przynajmniej teraz mój program zwraca takie same. Dzięki!

O co chodzi z tym podpowiadaniem? Testy na forum zawsze były.
Potwierdzam.
897558650862
Sugerowałbym, żeby wszystkie TLE przepuścić jeszcze raz przez system, i zrobić tak z 5 razy.
#include <stdio.h>

#include "message.h"

volatile b;

int main (void) {
int NoN = NumberOfNodes();
int i;

for (i = 0; i < 400000000; ++i) ++b;

for (i = 0; i < NoN; ++i) Send(i);
for (i = 0; i < NoN; ++i) Receive(i);
}

Procek "Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz" (2 cores x 2 HTs = 4 cpus)

1 Instancja:
real 0m1.050s
user 0m1.004s
sys 0m0.044s

(Jak widac tak dobrane zeby chodzilo ~sekunde)

100 Instancji:
real 0m35.150s
user 2m12.257s
sys 0m3.550s

user+sys = 135.8s, czyli (z Dirichleta) ktoryś z wątków musiał chodzić 1.358s

czyli max czas procesora po wszystkich instancjach >= 1.358s.
A wiadomo, że powinno chodzić bliżej sekundy.

Ktoś powie że te 0.358s to czas synchronizacji stu instancji.
Dobra zwiększamy 400,000,000 pięciokrotnie do 2,000,000,000.

1 Instancja:
real 0m4.595s
user 0m4.552s
sys 0m0.041s

(Jak widać nie całkiem 5 razy dłużej bo koszty rozruchu są spore)

100 Instacji:
real 2m47.122s
user 10m52.864s
sys 0m9.606s

user+sys = 662.47s, czyli któryś z wątków musiał chodzić 6.6247s
a wiadomo, że powinno być 4.6, czyli ~2s nadmiaru.

(bez petli zuzywajacej czas)

1 Instacja:
real 0m0.089s
user 0m0.041s
sys 0m0.046s

100 Instacji:
real 0m1.966s
user 0m2.220s
sys 0m1.288s

user+sys = 3.5s, czyli synchronizacja okolo 0.035s per instancje.

Widać, że to się nie zgadza i większość tych nadmiarów powyżej jest zupełnie sztuczna i wynikiem nie-blokującej natury Receive().
niech ktoś powie, które outy są zlę, a które dobre bo ja się już zgubiłem.