Forum jest zablokowane. Podczas blokady nie można dodawać ani edytować wiadomości.
Temat: About the time limit of 4B
I find the judge machine is strangely slow..
On my computer, my program can get the answer of a 40000*40000 size input within 2s using 20 nodes. But it ran 12 seconds when I submitted it to problem test.
Is there anyone have this strange problem too?
On my computer, my program can get the answer of a 40000*40000 size input within 2s using 20 nodes. But it ran 12 seconds when I submitted it to problem test.
Is there anyone have this strange problem too?
I have the very same problem and I've already wasted a few testruns trying to figure the reason out. I still don't understand it at all.
Polish version: Mam ten sam problem i zmarnowałem już kilka testrunów, by dowiedzieć się o co chodzi. Wciąż nie rozumiem.
Polish translation of the post above: Sprawdzaczki są dziwnie wolne. Lokalnie mam 2s na 20 instancjach dla planszy 40k x 40k, a submitnięte jako test programu działa 12 sekund. Ktoś ma ten sam problem?
Polish version: Mam ten sam problem i zmarnowałem już kilka testrunów, by dowiedzieć się o co chodzi. Wciąż nie rozumiem.
Polish translation of the post above: Sprawdzaczki są dziwnie wolne. Lokalnie mam 2s na 20 instancjach dla planszy 40k x 40k, a submitnięte jako test programu działa 12 sekund. Ktoś ma ten sam problem?
Same here. I wasted one afternoon and can't figure out the problem. It seems the running time is the sum of all nodes (just like the performance of a single node).
If it's a bug in the contest, I hope round 4 can be extended.
If it's a bug in the contest, I hope round 4 can be extended.
I've managed to read 75000x75000 input and do a lot of other stuff in 4.6s with 100 nodes (on test dzi0c) so I don't see the problem with time limit. Are you sure it is't sth else than reading? If you declare a lot of memory while program is running it could take some time.
I think it's rather usual that time of execution on sio2 is longer than on contestant's computer, but time limit in this task is enough to solve it... Have 2.18s on dzi0c after submission.
Spróbujemy przyjrzeć się tej sprawie. Gdy tylko coś ustalimy, damy znać.
We'll try to investigate this issue. As soon as we find something out, we'll immediately let you know.
We'll try to investigate this issue. As soon as we find something out, we'll immediately let you know.
I agree that there is something fishy going around here. I have exactly the same problem, I have a code that (for 30000x30000) on my computer works for 8s in total and max instance runs 0.8s and on testrun max instance runs 6.34s (which effectivale scales to significant TLE on maxtest)... By using a lot of testruns and a lot of my wasted time I identified part of code that causes this problem - I don't declare there any memory, I don't send any messages, I don't use reading functions.
And I think that extending fourth round is a very good idea, I devoted a lot of my time to investigate this issue (and I have llimited time today) which turned out to be clearly a problem with distributed judge.
And I think that extending fourth round is a very good idea, I devoted a lot of my time to investigate this issue (and I have llimited time today) which turned out to be clearly a problem with distributed judge.
I don't understand the problem, isn't last example max test? If you pass it, why should you bother with 30Kx30K or something simillar?
I don't pass it. Even if I passed it, wouldn't you see any problem with not passing some other tests allowed by the constraints?
(!!)
Wygląda na to, że w pewnych (niezrozumiałych jeszcze przez nas) przypadkach wysyłanie wiadomości o rozmiarze przekraczającym 64 KB może być istotnie wolniejsze. Jako workaround polecamy więc wysyłanie wiadomości mniejszych niż 64 KB.
It seems that in some rare cases (we don't understand them yet), huge messages (larger than 64 KB) may take very long to be sent between the nodes. As a workaround, we suggest that you avoid sending large chunks of data at once.
Wygląda na to, że w pewnych (niezrozumiałych jeszcze przez nas) przypadkach wysyłanie wiadomości o rozmiarze przekraczającym 64 KB może być istotnie wolniejsze. Jako workaround polecamy więc wysyłanie wiadomości mniejszych niż 64 KB.
It seems that in some rare cases (we don't understand them yet), huge messages (larger than 64 KB) may take very long to be sent between the nodes. As a workaround, we suggest that you avoid sending large chunks of data at once.
Czy dotyczy to też zadania 4A (skup akcji)?
Oba zadania testowane są na tych samych maszynach. Analogiczny problem mógłby więc teoretycznie pojawić się i w 4A.