Как проверить процессор на 64-разрядность?

Что за процессор?

lscpu

или поискать флаг lm

http://pastebin.com/q6xsJLma

4й пень, 32 разряда, стало быть.

Rinaldus

в связи с чем придется ставить 64-разрядный дистрибутив

Зачем себя мучить? Просто поставь ядро с PAE

Так он вроде поддерживает 64 разряда. Флаг lm есть и по lscpu он явно это пишет.

4.2
http://en.wikipedia.org/wiki/Pentium4#Prescott

Дай вывод lspci -nn

У этого процессора в поддержке EM64T есть ошибки.

http://pastebin.com/KVeYDT9g

Хорошая материнка, 4 гб все откроет. не могу вспомнить, что за ошибка у этого процессора в 64 битном режиме. По этой причине флеш сегфолтится.

А core 2 не могут тебе установить?

Обещали поменять процессор, но не раньше лета. А сейчас только пообещали апгрейдить оперативную память с 2 ГБ до 4.

Так все же лучше наверное 32-разрядное ядро с PAE, если в 64-разрядном режиме у него ошибки?

Rinaldus

Так все же лучше наверное 32-разрядное ядро с PAE

да. для вашего CPU и для 4х Гб - да. И кстати PAE у вас наверняка УЖЕ есть - просто воткните память, и радуйтесь.

lm есть, значит 64 бита держит

Reset

lm есть, значит 64 бита держит

а надо-ли? В смысле, это будет быстрее, или памяти добавится?

Математический софт на 64х битах быстрее работает не зависимо от размера памяти. Некоторые вещи тоже быстрее будут работать, так как можно сделать mmap больших файлов и работать с ними прозрачно, а в 32х битном режиме надо изобретать свой тормозной велосипед.

Reset

Математический софт на 64х битах быстрее работает не зависимо от размера памяти.

с чего-бы вдруг, если математический сопроцесссор со времён 80486 на кристалле, и с 8087 80и битный? А для целых чисел во первых intel гарантирует 64х битную точность на сопроцессоре, а во вторых есть MMX & SSE, причём последняя так вообще минимум 128и битная. Ну и зачем нужны ваши 64и бита ещё и в самом CPU? Ну кроме подсчёта указателей на огромную память.

Reset

Некоторые вещи тоже быстрее будут работать, так как можно сделать mmap больших файлов и работать с ними прозрачно, а в 32х битном режиме надо изобретать свой тормозной велосипед.

на 4х гб ничего изобретать не нужно. Вот когда у вас на процесс пойдёт более 64Гб - тогда поговорим.

с чего-бы вдруг, если математический сопроцесссор со времён 80486 на кристалле, и с 8087 80и битный?

Хотя бы потому, что на 64х битах по-дефолту сопроцессор не используется, а используются simd инструкции.

на 4х гб ничего изобретать не нужно.

Как не нужно? На процесс 3 гига, а файл у меня 1Tb.

На процесс 3 гига, а файл у меня 1Tb.

Такие проблемы решаются давно отработанными костылями. Нельзя же в угоду удобству приносить в жертву святую 32-хбитность.

Reset

Хотя бы потому, что на 64х битах по-дефолту сопроцессор не используется, а используются simd инструкции.

вы уверены, что они будут быстрее 128и битных SSE?

Reset

Как не нужно? На процесс 3 гига, а файл у меня 1Tb.

такой файл по любому не влезет в 4Гб. Да и вообще, было-бы у ТС хотя-бы 8Гб и нормальный CPU - я-бы и не спорил. А так...

да. для вашего CPU и для 4х Гб - да. И кстати PAE у вас наверняка УЖЕ есть - просто воткните память, и радуйтесь.

Нет, у меня еще PAE нет, но поскольку у меня Calculate, то отметить одну галочку и пересобрать ядро - не проблема. Значит, как только воткнут 4 гига памяти, я не буду ставить 64-битный дистрибутив, а просто пересоберу ядро.

угу. и не забудьте отписаться...

вы уверены, что они будут быстрее 128и битных SSE?

А sse это по твоему не simd ?

такой файл по любому не влезет в 4Гб. Да и вообще, было-бы у ТС хотя-бы 8Гб и нормальный CPU - я-бы и не спорил. А так...

А мне и не надо его вмещать в 4Gb, мне надо его заммапить в адресное пространство.

такой файл по любому не влезет в 4Гб.

Зато легко замапится в адресное пространство.

Reset

А sse это по твоему не simd ?

оно. Частный случай. Но почему

Математический софт на 64х битах быстрее работает

?

В 64х битных какое-то иное SSE?

Reset

А мне и не надо его вмещать в 4Gb, мне надо его заммапить в адресное пространство.

ну тут ладно, убедили. Хотя 100500 лет обходились без этого. И не очень-то и страдали. Всё равно внешний файл очень медленный, по сравнению с памятью. А 32х бит на доступ к памяти в 4Гб вполне хватит. За то 64х битные указатели вдвое больше, а следовательно вдвое дороже.

В 64х битных какое-то иное SSE?

На любом 64х битном x86-64 процессоре есть SSE, поэтому компиляторы по-дефолту его используют при сборке под x86-64. Плюс ускорения могут получаться за счет большего числа регистров. На своем узкоспецифичном софте я получал местами прирост до 10 раз.

ну тут ладно, убедили. Хотя 100500 лет обходились без этого. И не очень-то и страдали. Всё равно внешний файл очень медленный, по сравнению с памятью.

Во-первых работать с mmap'нутыми файлами проще, а во-вторых быстрее.

Reset

На любом 64х битном x86-64 процессоре есть SSE

а где его нет-то?

Reset

На своем узкоспецифичном софте я получал местами прирост до 10 раз.

вот на таком процессоре: http://pastebin.com/q6xsJLma ? да? там похоже даже SSE3 нет.

Reset

Во-первых работать с mmap'нутыми файлами проще, а во-вторых быстрее.

проще - не факт, ибо лично я напрямую с файлами не работаю. Как и 95% прикладных кодеров ИМХО. А что до «быстрее»... Тоже не факт. В том смысле, что если ускорение и будет, то я сомневаюсь, что это ускорение будет заметным. Ибо код, который долбает несколько одних и тех-же гигов терабайтного файла - это очень специфический код. Или обычный быдлокод. А если нагрузка равномерна, то и мапить файл смысла особого нет (с т.з. скорости).

ЗЫЖ а вообще - посмотреть надо. Что спорить-то?

злостная неправда.

на P4 которые в 775 сокет есть 64bit инструкции.

проще - не факт, ибо лично я напрямую с файлами не работаю.

А как с ними еще работать?

А что до «быстрее»... Тоже не факт.

Факт, хотя бы за счет отсутствия системных вызовов.

В том смысле, что если ускорение и будет, то я сомневаюсь, что это ускорение будет заметным.

Ускорение будет и существенное. Проверено неоднократно.

ktk

на P4 которые в 775 сокет есть 64bit инструкции.

есть на некоторых. на других - нету.

Reset

А как с ними еще работать?

man 2 open, man 2 write...

Reset

Факт, хотя бы за счет отсутствия системных вызовов.

вопрос - сколько стоят вызовы, и сколько - чтение/запись?

Reset

Ускорение будет и существенное. Проверено неоднократно.

будет мне нефиг делать - проверю. Может ТС отпишется...

man 2 open, man 2 write...

и это по твоему проще чем работа с непрерывным куском памяти?

я бы сказал на большинстве есть :)

ktk

я бы сказал на большинстве есть :)

у меня 2 валяются - на одном есть, на другом нет :-)

жуть....

$ sed -n 's/^flags.* lm .*/x86_64/p;T;q' /proc/cpuinfo 
x86_64

Reset

и это по твоему проще чем работа с непрерывным куском памяти?

а твой ммап уже везде работает? Извини, я ПО не только для себя пишу...

В венде тоже mmap есть, только по другому называется. А вообще, в бусте есть обертки.

я не про венду, а про невозможность мапить в 32х битной ОС терабайтами.

Да, так гораздо элегантнее, что-то я сам не додумался, спасибо.

Только всё-таки лучше

grep -qe "flags.*\ lm\ " /proc/cpuinfo && echo 64bit supported

С grep'ом выше элегантнее и понятнее :)

Факт, хотя бы за счет отсутствия системных вызовов.

если речь об экономии на контекст-свитчах, то эксепшены PAGE_FAULT и прочие события сброса блоков на диск обрабатываются также в ядре; тут выигрыш скорее за счет отсутствия лишнего копирования памяти в/из юзер спейс из/в кернел спейс при чтении/записи кусков файла

можно подумать, что вы что-то поняли в моём примере. Когда поймёте - поговорим за элегантность.

в примере с sed'ом есть сущности за которыми придется лезть в ман (p;T;q), в примере с grep всё прозрачно

Reset

в примере с sed'ом есть сущности за которыми придется лезть в ман (p;T;q)

я не лазил ни в какой ман. Как и вы не лазили за grep -qe и bash &&. и echo. Да и вообще, я про первоначальный скрипт писал. Этот появился уже позже.

увеличить оперативную память до 4 ГБ, в связи с чем придется ставить 64-разрядный дистрибутив

Не вижу никакой связи.

Можно подумать, понял. man sed в любом дистрибутиве есть, да и sed тоже несколько раз запускали, ага.
P.S. Не надо так себя вести, некрасиво.