| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | tourist | 3993 |
| 2 | jiangly | 3743 |
| 3 | orzdevinwang | 3707 |
| 4 | Radewoosh | 3627 |
| 5 | jqdai0815 | 3620 |
| 6 | Benq | 3564 |
| 7 | Kevin114514 | 3443 |
| 8 | ksun48 | 3434 |
| 9 | Rewinding | 3397 |
| 10 | Um_nik | 3396 |
| Страны | Города | Организации | Всё → |
| № | Пользователь | Вклад |
|---|---|---|
| 1 | cry | 167 |
| 2 | Um_nik | 163 |
| 3 | maomao90 | 162 |
| 3 | atcoder_official | 162 |
| 5 | adamant | 159 |
| 6 | -is-this-fft- | 158 |
| 7 | awoo | 156 |
| 8 | TheScrasse | 154 |
| 9 | Dominater069 | 153 |
| 10 | nor | 152 |
Есть 2 решения, который принципиально ничем не отличаются.
1) http://mirror.codeforces.com/contest/375/submission/5504829
2) http://mirror.codeforces.com/contest/375/submission/11947758
Одно ловит TL, другое нет. Причем разница примерно в 2 раза.
Совершенно непонятно в чем проблема.
Ну у меня вот два одинаковых решения есть, с разницей более чем в два раза:)
http://mirror.codeforces.com/contest/555/submission/11948033 http://mirror.codeforces.com/contest/555/submission/11948051
Может дело в компиляторах ?
Нет, дело не в них. Я отправлял под всеми возможными компиляторами.
Сейчас решил отправить еще разок одно решение.
http://mirror.codeforces.com/contest/375/submission/5504829
http://mirror.codeforces.com/contest/375/submission/11947972
Они совершенно одинаковые.
Это наверное все из-за "новизны" компилятора.
В прошлой правке не тот компилятор был. Теперь они точно одинаковы
Может эта разница обоснована тем что решения на границе кэша процессора? Раз влезло, раз нет. Рандом. Не считал) Просто пальцем в небо.
Отослано:
2013-12-24 18:25:02
тут много чего изменилось за это время же.
Первое решение было отправлено в 2013 — судя по всему, до смены серверов КФ. Отсюда понятна разница в два раза.
Это точно связано с обновлением сервером и/или компиляторов. Просто переотправил свое старое решение — тот же результат. Старое AC: 5507973, новое TL: 11948850.
В mingw 4.9.2 чтение из cin стало заметно медленнее работать.
А может можно оставить какую-нибудь старую версию, в которой он еще нормально работает? Или вообще добавить честный g++ под linux (кажется, я слышал, что КФ поддерживает инвокеры под разными ОС(хотя и не использует их сейчас))
Навсегда оставить? Не выглядит это хорошим решением. А как же лучшая поддержка C++11 и прочие радости (на горизонте же С++14 и дальше)? Все знают, что cin/cout медленные, когда большой i/o используют scanf/printf и прочие радости.
C linux не всё так просто. У нас тестирующие компьютеры используются и в учебном процессе, там Windows нужен. Кроме того, большая часть пользователей Codeforces работает под Windows и это удобнее тестировать ближе к рабочему окружению участника. Не забывайте и про честный C#, Visual Studio С++. Огромное количество чекеров написано на Delphi (в тренировках, например) и они просто так не заработают на FreePascal. С Windows удобнее, что популярный в Linux компилятор имеет порт под Windows, но не наоборот.
До лучших времен, по крайней мере (пока вдруг снова не станет работать быстро) Есть же Java 7. (Да и Java 6 вроде не очень давно выпилили)
Мне кажется, что версия c++ с быстрым cin'ом куда полезнее, чем версия c++ без c++11 (чтобы написать код, который не работает под c++11 и работает под c++98, надо постараться, а быстрый cin всем пригодится)
C++14 кажется уже не на горизонте, а текущее настоящее:) (Его люди в продакшне используют)
Что значит все знают? По-моему, год назад(условная дата) все знали, что они одинаково быстро работают(естественно, если предварительно iostream затвикать). Я процентов на 90 уверен, что на моем pc и на моем компиляторе они и в данный момент отличаются только на погрешность.
Я имел ввиду часть компиляторов оставить под Windows, часть под Linux. С тем, что при полном переезде на linux часть языков не удастся сохранить, я не спорю. Что же до windows у участников: не уверен, что выберут большинство участников под windows: g++ или mingw
Не хочется разводить разные компиляторы (о разнице которых будут догадываться только избранные): "GNU C++ 4.7.2" (для быстрого ввода cin/cout), "GNU C++ 5.1.0" (для лучшей поддержки последних фич), "GNU C++ 4.9.2 (в нем исправлены критичные баги оптимизации, пока не обнаружены другие), "GNU C++ 3.4.6" (для поддержки расширений
<?и>?). А еще взламывать будет веселее.Ага, например
printf("%lf\n", 1.0);(так пишет половина участников).Отличались они. Кстати, и сейчас трюк
sync_with_stdio(false)позволяет считать и вывести пять миллионов интов секунд за 5. На типичных ограничениях (сотни тысяч) это будет небольшая доля от TL. На mingw 5.1.0 немного быстрее, перспектива радует.Даже в предположении, что есть возможность поставить linux-инвокеры (а её нет): часть из инвокеров может простаивать в случае очереди (а другая может оказаться перегружена, и вообще будет нечестно как-то в случае очереди) + значительно усложниться поддержка зоопарка.
Ну у меня работает вот такой код: http://mirror.codeforces.com/contest/557/submission/11953399
Немного цифр:
вывод 1e7 интов
http://mirror.codeforces.com/contest/553/submission/11953619 printf 2277мс
http://mirror.codeforces.com/contest/553/submission/11953617 cout 4632мс
Больше чем в два раза разница.
g++-4.9.1 (текущий дефолтный на последней убунте LTS)
0,89s user 0,44s system 99% cpu 1,337 total
cout
1,08s user 0,35s system 99% cpu 1,432 total
printf
погрешность меньше 10%, даже в пользу cout. Это к тому, что они одинаковые
cin/scanf примерно та же история локально. Если подскажете задачу, где можно потестить(или можете сами запустить) можно посмотреть что будет твориться на CF.
Да, я понимаю, что 1е7 интов обычно не вводится/выводится, но для сравнения можно посмотреть у меня попытки по задачи (327D — Башни из кирпичей) (код пользователь poikniok) Код с cout работает 1.8с, с printf ~0.5. Разница времени работы составляет больше половины TL
И все-таки я не понимаю, чем это производит больший зоопарк, чем c++98, Java7/8 и 4 версии питона.
Не подскажете, что такое
<?и>??обсуждение на кодфорсес
у меня нет существенной разницы. Было: 5525184, стало: 11948932
переписал на scanf/printf, стало даже медленнее: 11949033
видимо дело в промахах кэша, векторизации циклов и прочей магии.
Ну, разница в 30мс — это не медленне =) А у меня после переписывания под scanf/printf стало на полсекунды медленнее, чем было тогда: 11949097. Хотя сравнивать с тем результатом, пожалуй, некорректно.