Forum jest zablokowane. Podczas blokady nie można dodawać ani edytować wiadomości.
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
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ę.
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ę :)
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.
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.
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.
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.
O co chodzi z tym podpowiadaniem? Testy na forum zawsze były.
Potwierdzam.
897558650862
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().
#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.