Forum jest zablokowane. Podczas blokady nie można dodawać ani edytować wiadomości.
Ostatnie posty
INI_ERR - jeden z testów wstępnych (wymienionych w treści zadania) nie przeszedł pomyślnie sprawdzanie. Dostał MLE (przekroczenie pamięci), WA (zła odpowiedź), TLE (przekroczony limit czasu).
U mnie różnorodność na komputerze 3s, na stronie OI 2s.
0 OK 0.00s / 0.50s 0 / 0
1ocen OK 0.00s / 0.50s 0 / 0
2ocen OK 0.00s / 0.50s 0 / 0
3ocen OK 0.00s / 0.50s 0 / 0
4ocen OK 0.02s / 0.50s 0 / 0
5ocen OK 27.55s / 30.00s 0 / 0
1ocen OK 0.00s / 0.50s 0 / 0
2ocen OK 0.00s / 0.50s 0 / 0
3ocen OK 0.00s / 0.50s 0 / 0
4ocen OK 0.02s / 0.50s 0 / 0
5ocen OK 27.55s / 30.00s 0 / 0
Co oznacza błąd wstępny , w testach próbnych wychodzi wszystko ok a jak próbuję wysłać to dostaję INI_ERR
Oczywiście, używanie stabilnych, bezpiecznych wersji oprogramowania jest jak najbardziej w porządku (inna sprawa, że tu gcc 4.8 się nie łapie, wsparcie c++11 w nim jest takie, że są pewne funkcjonalności które nie do końca poprawnie działają, tu przydałby się update) a nawet konieczne w takich systemach jak SIO, gdzie błędy nie powinny występować i system musi zawsze działać poprawnie (nie wyobrażam sobie SIO postawionego na Archu bleeding-edge). Jednak czy to oznacza, że OITT nie może wspierać nowszych systemów by nieco ułatwić życie zawodnikom, zapewniając jednocześnie obsługę dotychczasowych wersji by zapewnić dalsze stabilne działanie systemu? Ostatni update był 2 lata temu, może czas pomyśleć o kolejnym?
O ile mi wiadomo, UTF-8 jest powszechnie obsługiwanym standardem, a UTF-16 nie jest jakoś szczególnie popularny.
Do czego jest Ci potrzebny UTF-16?
Do czego jest Ci potrzebny UTF-16?
Jest powód, dla którego Olimpiada używa sprawdzonych jako stabilne wersji oprogramowania, a nie najnowszych – rozumiem to nawet jako użytkownik Archa. Poza tym data end-of-life kernela 3.16 przypada dopiero w 2020 roku, a ostatnia jego aktualizacja wyszła miesiąc temu, więc jest to wciąż działający, bezpieczny kernel i nie powinno być problemów z jego użyciem. Jeżeli ktoś nie chce sobie "brudzić" głównego systemu, to może odpalić wirtualną maszynę z Debianem 8 (również wspieranym do 2020 roku).
Tymczasowe rozwiązanie zostało przedstawione w tym poście: https://sio2.mimuw.edu.pl/c/oi25-1/forum/62/649/#forum-anchor-4101 , jednak dalej uważam, że OITT powinien wspierać nowsze, a nie jedynie kilkuletnie, wersje oprogramowania, po coś są w końcu tworzone.
Dziękuję bardzo, zaraz wypróbuję tą metodę. Jedno pytanie, czy czas to na pewno ilość (instrukcji / 2000000), a nie (ilość instrukcji / 3000000)? Tutaj: http://oi.edu.pl/l/srodowisko/ na samym końcu możemy przeczytać, że "Zakładamy zegar procesora o częstotliwości 3GHz."
Dlaczego OITT nie wspiera nowszych wersji pina? To, że Olimpiada używa ponad 2-letniej wersji GCC, nie znaczy, że nikt na świecie nie aktualizuje używanego przez siebie oprogramowania, w tym np. kernela. Wersja 3.16 została wydana PONAD 3 LATA temu. Rozumiem, że żeby brać udział w OI, trzeba mieć komputer nieaktualizowany od kilku lat?
Warto wiedzieć, że środowisko olimpiady to 32-bitowe Ubuntu 14.04 z jądrem 3.13. Sama instalacja wspomnianego jądra powinna wystarczyć. Niestety Pin w wersji 3.x różni się w dużym stopniu od 2.x, więc sama rekompilacja biblioteki nie wystarczy.
Na szczęście nie trzeba tego robić - OITimeTool tylko zlicza ilość wykonanych instrukcji [chociaż posiada też zaimplementowaną symulację dostępu do pamięci - jeżeli dostęp do pamięci jest nieliniowy naliczany jest dodatkowy czas - co ciekawe nie wygląda żeby było to używane na OIu czy na Szkopule].
Czas (w ms) to (ilość instrukcji / 2000000). Przykładowa biblioteka robiąca dokładnie to samo znajduje się w dystrybucji Pina - w folderze source/tools/SimpleExamples - wystarczy wykonać make w danym folderze po pobraniu najnowszego Pina i użyć wyjściowej biblioteki obj-intel64/inscount2_mt.so
Pozostaje wywołać pina:
$ ./pin -t *.so -- ./zadanie < wejscie.in > wyjscie.out
i odczytać wyjście z narzędzia:
$ tail wyjscie.out | grep Count
Czasy będą odstawać, ale powinny być bardzo podobne do ostatecznych.
Dla ciekawskich zapraszam na repozytorium z implementacją próbującą naśladować OITimeToola (tylko x86 i Pin v2.x): https://github.com/PowerOfDark/Sjudge
Na szczęście nie trzeba tego robić - OITimeTool tylko zlicza ilość wykonanych instrukcji [chociaż posiada też zaimplementowaną symulację dostępu do pamięci - jeżeli dostęp do pamięci jest nieliniowy naliczany jest dodatkowy czas - co ciekawe nie wygląda żeby było to używane na OIu czy na Szkopule].
Czas (w ms) to (ilość instrukcji / 2000000). Przykładowa biblioteka robiąca dokładnie to samo znajduje się w dystrybucji Pina - w folderze source/tools/SimpleExamples - wystarczy wykonać make w danym folderze po pobraniu najnowszego Pina i użyć wyjściowej biblioteki obj-intel64/inscount2_mt.so
Pozostaje wywołać pina:
$ ./pin -t *.so -- ./zadanie < wejscie.in > wyjscie.out
i odczytać wyjście z narzędzia:
$ tail wyjscie.out | grep Count
Czasy będą odstawać, ale powinny być bardzo podobne do ostatecznych.
Dla ciekawskich zapraszam na repozytorium z implementacją próbującą naśladować OITimeToola (tylko x86 i Pin v2.x): https://github.com/PowerOfDark/Sjudge
Proszę spróbować z wersją 2.14 ("Kit" 71313), którą można znaleźć tutaj: https://software.intel.com/en-us/articles/pin-a-binary-instrumentation-tool-downloads. Jeżeli chodzi o działanie na linuxie, to niestety ta wersja pina nie wspiera nowszych wersji (np, wersji 4.9, 4.12) kernela, a więc i oitimetool na nich nie działa. Można za to spróbować z starszymi wersjami jądra - np, 3.13, 3.16 (na których na pewno działa).
Idźmy dalej, wersja biblioteki pin wymieniona na githubie timetoola (61208) nigdy chyba nie istniała. Można znaleźć starą listę wersji na wayback machine (https://web.archive.org/web/20150325123148/https://software.intel.com/en-us/articles/pin-a-binary-instrumentation-tool-downloads), ale tam jest 61206 (oczywiście na serwerach intela już jej nie ma więc nie da się jej pobrać). Czy organizatorzy byliby w stanie udostępnić funkcjonalną wersję OITT? Albo chociaż przyjrzeć się problemowi?
Taki sam błąd mam na Manjaro 17.0.6, więc to nie kwestia konkretnej dystrybucji.
Również potwierdzam.