64->32

производительность скорее повысится

>64bit maple я не нашёл

32-хбитный разве не пашет?

>32-хбитный разве не пашет? просто так не пашет, а извращаться с чруутом неохото, темболее всё равно вайфай только в 32 получится поднять.. так что там с производительностью?

никакой разницы в плане производительности, по крайней мере "на глаз"

Производительность повысится. Сам из-за этого не ставлю 64-битную ось. Юзаю 32 бита.

> 64bit maple я не нашёл

Если у тебя Maple 10, то 64-битную версию выдает по запросу Technical Support, а с Maple 11 она идет в коробке. В чем проблема?

Какой проц?

От этого несколько зависит, что ты выиграешь/проиграешь...

timth@laptop:~$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 104
model name	: AMD Turion(tm) 64 X2 Mobile Technology TL-58
stepping	: 1
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips	: 1652.36
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 104
model name	: AMD Turion(tm) 64 X2 Mobile Technology TL-58
stepping	: 1
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips	: 1652.36
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

Скорее всего, производительность упадёт на 3-5% при переходе к 32-м битам. В некоторых специфических задачах вроде сжатия разница может быть больше, до 20%.

Сам перешел с 64 на 32 недавно. Особой разницы не заметно ни на иргушках, ни на работе сервисов, ни при разработке. А если не видно разницы, зачем платить больше? (ц) :-)

> Скорее всего, производительность упадёт на 3-5% при переходе к 32-м битам. В некоторых специфических задачах вроде сжатия разница может быть больше, до 20%.

Почему?

Я правильно понимаю, что 64х разрядность при объёме ОЗУ <= 4GB лишь впустую увеличивает размер указателей и таблиц дескрипторов, которые перегружаются из памяти же при переключении контекстов, таким образом лишь забивая и без того медленный канал мекжду процом и памятью? А у него ещё и х2.

> А у него ещё и х2.

Можно подробнее?

> Можно подробнее?

"model name : AMD Turion(tm) 64 X2 "

-> два я дра одновременно от меееедлеееееннооооой памяти байтов хотят.

Перефразирую. Почему X2=медленно? Или ты считаешь, что любой двухъядерный работает с памятью вдвое медленнее одноядерного?

Одноядерный работает медленнее собственной памяти, что уж говорить о двухъядерном? ДДР способна более-менее быстро отдавать непрерывные куски мозга, но так ли часто это требуется? Сейчас один демон тащит данные из одного участка памяти, через мгновение другой демон на другом ядре запросит данных из совсем другого участка, при этом, в случае промаха в кеше, он будет дожидаться освобождения шины первым ядром, выставлять адрес на шину, дожидаться ответа и, когда он считает свой байт или слово, шину снова захватит первое йадро, и будет мучительно долго снова выставлять на ней адрес своих данных и читать свой байт, а потом случится прерывание и второе йадро будет дожидаться шины и пытаться затолкать состояние своих регистров в стек и после этого считать стек процесса, к которому было передано управление по прерыванию.. Кеш, конечно, отчасти это дело компенсирует, но насколько, каков у этого кеша должен быть размер - вот ис зе квещен.

Преимущества архитектуры — типа большего числа регистров — у 64-х битов есть. Только у Core2 в 64-х битном режиме отключаются некоторые фичи для повышения производительности.

И, так как на интеле до памяти от проца ещё бутолочное горлышко FSB, то на нём указанный вами фактор проявляется сильнее.

И тесты показывают, что на Core2 производительней 32 бита, а на K8 — 64.

128bit наше всьо!!! =))

> Я правильно понимаю, что 64х разрядность при объёме ОЗУ <= 4GB лишь впустую увеличивает размер указателей и таблиц дескрипторов

Там же регистры 64битные, я так понимаю он может mov'ить 64 бита за столько же за сколько 32битная система 32 бита? Тогда скорость должна увиличиваться охрененно на 64 битах...

>Преимущества архитектуры — типа большего числа регистров

ох уж эти городские легенды

во всех x86-32 процах уже давным-давно несколько десятков регистров, курите про переименование регистров

производительность шины памяти от увеличения разрядности процессора сама собой не растет

> во всех x86-32 процах уже давным-давно несколько десятков регистров, курите про переименование регистров

угу а еще там RISC ядро, абалдеть!
но вот софт и системный и прикладной может использовать только 8 регистров на x86 и 16 на x86-64(в long mode). Т.е. появилась возможность меньше юзать стек для передачи параметров, хранения локальных переменных, etc.

> Я правильно понимаю, что 64х разрядность при объёме ОЗУ <= 4GB лишь впустую увеличивает размер указателей и таблиц дескрипторов, которые перегружаются из памяти же при переключении контекстов, таким образом лишь забивая и без того медленный канал мекжду процом и памятью? А у него ещё и х2.

Неправильно.

> может использовать только 8 регистров на x86 и 16 на x86-64(в long mode)

чушь

http://en.wikipedia.org/wiki/Register_renaming

> > может использовать только 8 регистров на x86 и 16 на x86-64(в long mode)

> чушь
> http://en.wikipedia.org/wiki/Register_renaming

А теперь покури, сынок, что такое "register allocation унд scheduling" в gcc.

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

точно так же на не-vliw архитектурах компилятор толком не может параллелизовать код

Интересно почему еще никто не запостил http://en.wikipedia.org/wiki/128-bit

Потому что уже пора писать http://en.wikipedia.org/wiki/256-bit

А может http://en.wikipedia.org/wiki/1024-bit ?

> http://en.wikipedia.org/wiki/128-bit

Кстати, хоть кто-нибудь по ссылке сходил? :)

>Кстати, хоть кто-нибудь по ссылке сходил? :)

Да, когда её на ЛОРе первый раз давали :)

> Кстати, хоть кто-нибудь по ссылке сходил? :)

А зачем?

> Там же регистры 64битные, я так понимаю он может mov'ить 64 бита за столько же за сколько 32битная система 32 бита?

Но только не в|из RAM.

> Тогда скорость должна увиличиваться охрененно на 64 битах...

От использования 64-битных операндов скорость может увеличиваться только у приложений оперирующих такими большими числами. Если вы будете крутить 8-разрядный ГИМП или приложения, работающие большей частью со строками, пусть даже это будут строки wchar_t, думаю эти приложения не будут использовать R*X регистры ибо незачем.