| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | tourist | 4009 |
| 2 | jiangly | 3823 |
| 3 | Benq | 3738 |
| 4 | Radewoosh | 3633 |
| 5 | jqdai0815 | 3620 |
| 6 | orzdevinwang | 3529 |
| 7 | ecnerwala | 3446 |
| 8 | Um_nik | 3396 |
| 9 | ksun48 | 3390 |
| 10 | gamegame | 3386 |
| Страны | Города | Организации | Всё → |
| № | Пользователь | Вклад |
|---|---|---|
| 1 | cry | 167 |
| 2 | Um_nik | 163 |
| 3 | maomao90 | 162 |
| 3 | atcoder_official | 162 |
| 5 | adamant | 159 |
| 6 | -is-this-fft- | 158 |
| 7 | awoo | 157 |
| 8 | TheScrasse | 154 |
| 9 | Dominater069 | 153 |
| 9 | nor | 153 |
Добрый день!
На текущий момент времени 32битная архитектура практически умерла. Тем не менее во всех соревнованиях по программированию продолжают использоваться 32битные компиляторы. Есть какая-то скрытая причина этого? Или просто "так принято" и "так все привыкли"?
Когда с 8-разрядной на 16-разрядную или потом с 16-разрядной на 32-разрядную архитектуру переходили — это было круто, важно, насущно — коротких чисел ощутимо не хватало. Сейчас же задач (прикладных в первую очередь) для которых не хватает 4млрд значений 32-битного инта не так много. Это сильно тормозит развитие и самих 64-битных решений, и софта и компиляторов для них.
(я не спорю что для какой-нибудь конкретной спортивной задачки с большими числами 64-битная архитектура может дать ускорение в несколько раз)
Если в ближайшие лет 10 пригрядёт переход на 128-битные архитектуры, боюсь он будет ещё медленне входить. Таким числам место в сопроцессорах, чипах видеокарт и т.п. — а не в CPU...
Насколько я неправ?
Не совсем так. Причина появления x64 — необходимость выделять более 4 гигабайтов памяти. На текущий момент разумных причин для x128 я не вижу, но, возможно, они появятся
Ну для этого 64-разрядность проца необязательна. На 16-разрядных ведь памяти всегда было больше 65кб... ;-)
Это только для работы с линейным блоком памяти было бы важно, но поскольку во-первых случаи когда нужен массив больше 4Гб реально редки, во-вторых обработка 4Гб занимает секунды, потому разница между например одним 16-гиговым блоком или четырьмя сегментами по 4гб вряд ли кого-то волновала бы...
Полагаю, что так принято, привыкли и не везде есть 64-битные машины. У 64-битных компиляторов иногда обнаруживаются спецэффекты (если не ошибаюсь, в Java были какие-то забавные баги именно в 64-х битной версии).
Существенный для меня аргумент — указатели весят в два раза больше. Поэтому, например, всякие деревья на указателях (мне так сильно удобнее писать) автоматически занимают больше памяти. На informatics, вроде, была задача с ML=64, в которой пришлось переписать на массивы, иначе не входило.
Больше причин не вижу
Ну, я особо за железом не слежу, но мне казалось, что уже несколько лет 32битные процы для десктопов не делают. Или я не прав?
А мл в 64 мб — ну то же же пережиток уже. Ну и пока что можно оба варианта иметь на сервере
.
Я не говорю, что это надо вводить везде и сразу в приказном порядке. На рыбинском ЧФ сравнительно недавно перешли на 32битную архетектуру. Но мне кажется там, где есть такая возможность (кф, опенкап, tc) — надо предоставлять в качестве опции 64битные компиляторы
Надеюсь, это опечатка? Или на самом деле сравнительно недавно всех радовал Borland Pascal? :)
Говорить что 32х битная архитектура умерла пока рановато. Например у нас почти на всех университетских компах 32 бита. Не думаю что в других университетах школах ситуация сильно другая. А поскольку в соревнованиях по программированию участвуют в основном студенты и школьники думаю это и есть одна из главных причин.
это звучит непатриотично, но измерять современные информационные технологии компьютерами в университетах в России немного странно :)
Казалось вопрос не в том что современно, а в том что актуально)
Вот еще пример из недавних новостей http://it.tut.by/321877. С 64bit пока и mozilla не может справится.
Тот факт, что плагины для Firefox плохо совместимы с 64-битной Mozilla — это, конечно, повод не добавлять 64-битный компилятор, да
Не так :) У них там плагины для Firefox плохо совместимы с 64-битным Firefox :)
Заголовок жёлтый, они просто временно отменили ежедневные 64-битные сборки.
В любом случае хоронить 32биную архитектуру рано. :)
Мне кажется, что плюсов у перехода сейчас на 64-битные компиляторы, если это вообще возможно сделать для всех поддерживаемых языков, практически нет. В общем-то, какие они для соревнований? А минусы видны: мало того, что это затраты на обновление, так еще и участников придется переучивать :)
Один плюсик всё-таки имеется: GCC на x86-64 поддерживает целочисленный тип
__int128:-)Весомых причин для перехода сейчас нет. Но рано или поздно переходить всё равно придётся. Поэтому поддерживаю Egor с предложением ввести 64-битные компиляторы как опцию. Есть же на CF и OpenCup отдельная опция посылать код как C++11, не так ли? Те, кто хочет, смогут использовать. Да и интерес к архитектуре x86-64 возрастёт, больше людей ознакомится с её особенностями.
Да, указатели в два раза длиннее. Зато и в два раза больше регистров, в несколько раз быстрее операции с 64-битными числами, MMX/SSE/SSE2 включены по умолчанию — вполне себе компенсация.
Хорошая логика "причин сейчас нет, а потом придётся"... :-)
Почему бы вместо этого не начать юзать многоядерность в решениях спортивных задач? Это куда эффективнее, по-моему.
А с 64-битными компиляторами/решениями прежде чем обсуждать стоило бы подробные бенчмарки запустить. Не удивлюсь если найдутся хитрецы которые покажут задачи для которых 64-битное решение работает медленнее 32-битного на том же железе...
UPD: по поводу "одного плюсика" — насколько часто встречаются задачи для таких чисел? Гораздо чаще по-моему на просто длинную арифметику (которой в C++ из коробки вообще нет, зато есть в java и python-е, гы — кстати в последнем вроде всё что больше 32 бит считается длинным числом, что кагбе намекает на актуальность 64-битных чисел)
По-моему, __int128 это скорее недостаток: участники, использующие GCC, получат неоправданное преимущество перед использующими MSVC++ и Java. У них и так есть long double, но он хоть почти бесполезен :)
Есть одно "но": на CF на виртуалках стоит WinXP. 32-битная.