64 бита не нужны

← →
Смысл (2007-08-01 02:11) [0]

Пересмотрел свои программы, ни одной 64 бита не нужно. Все и так прекрасно обходятся. Да и памяти ( физически ) столько нету.

Кроме того прежде чем пожертвовать совместимостью - сорок раз подумаешь.

А вам 64 бита реально нужны? Если да, то где, в чём?

← →
celades © (2007-08-01 02:56) [1]

> А вам 64 бита реально нужны? Если да, то где, в чём?
>

У меня весь софт на компьютере 64битный и вроде как хуже не стало. А субъективно даже как-то пошустрее всё крутиться и вертиться. Всё-таки "64битность" это не только 64битная адресация

← →
TUser © (2007-08-01 03:24) [2]

Мне мало 64 битов. Мне не меньше трехсот гигов надо.

← →
SlymRO © (2007-08-01 04:52) [3]

integer стал в 2 раза больше это сулит:
1. integer операции 2 раза быстрее ("длинная" математика)
2. Пересылки через регистры 2 раза быстрее (на длинных массивах), в т.ч. с применением REP MOVSX
3. Доп. команды распараллеливания целочисленных вычислений
4. Вроде, но могу ошибаться, регистров добавили, пожно ныкаться не только по eax,edx,ecx (или чтотам):)
5. Необходимый объем стека удваивается, и памяти в целом, т.к. выравнивание hard_int= 8байт :(

← →
Alex Konshin © (2007-08-01 06:38) [4]

Насчет ускорения в два раза ты не прав. Если регистр стал в два раза больше это не значит, что арифметика стала в два раза быстрее. 2+2 будет исполняться столько же. И в длинной арифметике ты не прав. Например, умножение в столбик и деление будет выполняться в четыре раза быстрее.
Регистров стало и впрямь много больше. Т.е. оптимизация может дать больший эффект.

Так что на некоторых приложениях будет очень существенный рост производительности (не в 2 раза, как думают некоторые). Например, в криптографии.

В некоторых приложениях производительность ухудшится. Это произойдет в том случае, если в приложении много указателей, например, массивы ссылок на объекты. Это приведет к более интенсивной работе с памятью и возможно, к свопингу.

← →
SlymRO © (2007-08-01 07:16) [5]

Alex Konshin © (01.08.07 6:38) [4]
в длинной арифметике ты не прав. Например, умножение в столбик и деление будет выполняться в четыре раза быстрее
Откуда цифра 4?
на int1024 RSA idiv32 выполнится 1024/32=32 раза
а idiv64 16 раз, 32/16 = 2
тоже касаемо imul
на крипто приложениях с длинной целочисленной математикой выигрыш в 100%
40000! (сорактышь факториал)
calc32.exe: 11сек
calc64.exe: 5сек

← →
tesseract © (2007-08-01 09:51) [6]

Просто пока идёт преодоление "стены". Разработчики не хотят переписывать софт заточенный под 32 на 64 пока не будет достаточно клиентов с 64-битными версиями windows. Драйверов и ПО под 64 пока мало, поэтому и пользователи не спешат на неё переходить. Вот под nix уже куча народу перешла на x64 - софт то достаточно просто пересобрать. Хотя с оперативкой больше 4 гигов под *nix проблем никогда и не было :-)

← →
Mystic © (2007-08-01 11:00) [7]

Еще серьезное увеличение производительности в шахматах, там где используется bitboard. Среди моих знакомых, все кто перекомпилировал Linux под 64 бита на глаз отмечают увеличение производительности в полтора-два раза.

> Пересмотрел свои программы, ни одной 64 бита не нужно.

А что за программы? Большинству приложений и 32 битов не надо :) Вполне себе могли бы работать и в Win16.

Есть программы, которым вообще ничего не нужно.

> Регистров стало и впрямь много больше. Т.е. оптимизация
> может дать больший эффект.

Соглашение stdcall в 64-битном режиме таково, что большая часть аргументов передается через регистры.

← →
Mystic © (2007-08-01 11:07) [8]

А вот в .NET 64-битный JIT-компилятор явно не фонтан. Например, этот код

System.Drawing.Color Color = System.Drawing.Color.Black; if (Color == System.Drawing.Color.Black) System.Console.WriteLine("Catastrophic execution");

транслируется в следующее:

; System.Drawing.Color Color = System.Drawing.Color.Black; 0000005c lea rcx,[rsp+40h] 00000061 call FFFFFFFFF5A8CBF0 00000066 mov qword ptr [rsp+000000D0h],rax 0000006e lea rcx,[rsp+40h] 00000073 mov rax,qword ptr [rcx] 00000076 mov qword ptr [rsp+20h],rax 0000007b mov rax,qword ptr [rcx+8] 0000007f mov qword ptr [rsp+28h],rax 00000084 mov rax,qword ptr [rcx+10h] 00000088 mov qword ptr [rsp+30h],rax ; if (Color == System.Drawing.Color.Black) 0000008d lea rcx,[rsp+20h] 00000092 mov rax,qword ptr [rcx] 00000095 mov qword ptr [rsp+58h],rax 0000009a mov rax,qword ptr [rcx+8] 0000009e mov qword ptr [rsp+60h],rax 000000a3 mov rax,qword ptr [rcx+10h] 000000a7 mov qword ptr [rsp+68h],rax 000000ac lea rcx,[rsp+70h] 000000b1 call FFFFFFFFF5A8CBF0 000000b6 mov qword ptr [rsp+000000D8h],rax 000000be lea rcx,[rsp+70h] 000000c3 mov rax,qword ptr [rcx] 000000c6 mov qword ptr [rsp+000000B0h],rax 000000ce mov rax,qword ptr [rcx+8] 000000d2 mov qword ptr [rsp+000000B8h],rax 000000da mov rax,qword ptr [rcx+10h] 000000de mov qword ptr [rsp+000000C0h],rax 000000e6 lea rcx,[rsp+58h] 000000eb mov rax,qword ptr [rcx] 000000ee mov qword ptr [rsp+00000090h],rax 000000f6 mov rax,qword ptr [rcx+8] 000000fa mov qword ptr [rsp+00000098h],rax 00000102 mov rax,qword ptr [rcx+10h] 00000106 mov qword ptr [rsp+000000A0h],rax 0000010e lea rdx,[rsp+000000B0h] 00000116 lea rcx,[rsp+00000090h] 0000011e call FFFFFFFFF5A7DEA0 00000123 mov byte ptr [rsp+000000E0h],al 0000012a movzx eax,byte ptr [rsp+000000E0h] 00000132 test eax,eax 00000134 je 0000000000000148 ; System.Console.WriteLine("Catastrophic execution"); 00000136 mov rcx,12969090h 00000140 mov rcx,qword ptr [rcx] 00000143 call FFFFFFFFF81DFAE0

← →
ZMRaven © (2007-08-01 11:13) [9]

а в обработке видео(видеозахват и запись) прирост будет ?

← →
tesseract © (2007-08-01 11:19) [10]

> а в обработке видео(видеозахват и запись) прирост будет
> ?

Захват/запись вряд-ли, куда там больше. А вот основной тормоз - видеокодирование/обработка должен дать прирост и неплохой, если конечно заоптимизировать.

← →
alex_*** © (2007-08-01 11:31) [11]

Программист на заказчика работает. Скажет заказчик - хочу софт под 64 бита, сразу себе и поставишь

← →
tesseract © (2007-08-01 11:35) [12]

> Программист на заказчика работает.

Не все работают по заказам, вон Adobe сказала "фигушки вам а не photoshop 64".

← →
Alex Konshin © (2007-08-01 12:28) [13]

> SlymRO © (01.08.07 07:16) [5]
> Alex Konshin © (01.08.07 6:38) [4]
> в длинной арифметике ты не прав. Например, умножение в столбик
> и деление будет выполняться в четыре раза быстрее
> Откуда цифра 4?
> на int1024 RSA idiv32 выполнится 1024/32=32 раза
> а idiv64 16 раз, 32/16 = 2
> тоже касаемо imul
> на крипто приложениях с длинной целочисленной математикой
> выигрыш в 100%
> 40000! (сорактышь факториал)
> calc32.exe: 11сек
> calc64.exe: 5сек

Вот что значит отсутствие мат.образования.
Ты хоть раз реализовывал длинную арифметику? А я реализовывал.
А calc64 при желании можно написать так, что он и медленнее будет calc32, что твой пример и доказывает.

Я намекну: сколько умножений нужно сделать, чтобы перемножить 4-х значное число на 4-х значное? И сколько для того, чтобы перемножить два 2-х значных?

В алгоритмах умножении и делении столбиком обратная квадратичная зависимость от разрядности цифры (это термин из длинной арифметики).

← →
DevilDevil © (2007-08-01 13:00) [14]

А я всегда думал, что 64битный процессор сохраняет обратную совместимость для 32битных комманд...

Следовательно, програмы, написанные под 32b должны успешно выполняться на 64b процессоре без необходимости перекомпиляции.

В чём я заблуждаюсь? каковы причины такой реализации?

← →
Skyle © (2007-08-01 13:07) [15]

> DevilDevil © (01.08.07 13:00) [14]

Ни в чём не заблуждаешься. У процессора есть режим работы на 32 бита, именно в нём и выполняются 32битные программы, при этом совершенно не ощущая разницы.

Другое дело что хочется использовать 64бита в полный рост :)

← →
DevilDevil © (2007-08-01 13:16) [16]

Если я поставлю 64 битную ОС, буду иметь требуемое железо... то мои 32b программы заработают ?

Лучшей скорости можно добиться (при наличия 64-ного компилятора) при обработке переменных int64 (которых имхо используется мало). + вроде бы при умножении двух 32int будет прирост.

В остальных случаях могет быть потери в скорости

← →
Alex Konshin © (2007-08-01 13:29) [17]

У меня вот сейчас работает именно Windows XP 64-bit и даже не пиратская.
Работает большинство 32-бит приложений, но не все. Просто в некоторых писатель не знал, что бывают 64-бит Windows и интсталяторы отказываются ставить приложение. А у некоторых действительно есть проблемы.

Я так специально себе XP 64-bit поставил, чтоб о проблемах знать.

> DevilDevil © (01.08.07 13:16) [16]
> Если я поставлю 64 битную ОС, буду иметь требуемое железо.
> .. то мои 32b программы заработают ?
>
> Лучшей скорости можно добиться (при наличия 64-ного компилятора)
> при обработке переменных int64 (которых имхо используется
> мало). + вроде бы при умножении двух 32int будет прирост.
>
>
> В остальных случаях могет быть потери в скорости

У вас получается слишком много остальных случаев. Мягко скажем, вы не в курсе.

← →
DevilDevil © (2007-08-01 14:02) [18]

на 32битных процессорах работа с 32битными операндами выполняется быстрее, чем с 16 и 8 битными. Смею предположить, с 64 битами полная аналогия.

← →
Alex Konshin © (2007-08-01 14:22) [19]

> DevilDevil © (01.08.07 14:02) [18]
> на 32битных процессорах работа с 32битными операндами выполняется
> быстрее, чем с 16 и 8 битными. Смею предположить, с 64 битами
> полная аналогия.

Я к тому, что есть много "остальных" случаев, когда будет не потеря, а прибавление.

← →
ya00011 (2007-08-01 14:27) [20]

а 64битное ПО будет выполняться на обычной винде?

← →
DrPass © (2007-08-01 14:28) [21]

> ya00011 (01.08.07 14:27) [20]
> а 64битное ПО будет выполняться на обычной винде?

А ты как думаешь?

← →
Рамиль © (2007-08-01 14:30) [22]

> а 64битное ПО будет выполняться на обычной винде?

Будет, так же как и 32 разрядное в досе.

> Я к тому, что есть много "остальных" случаев, когда будет
> не потеря, а прибавление.

- копирование памяти
- ZeroMemory
- присвоение структуры (Rec1 := Rec2;)

что ещё?

Win x64 использует WoW (windows on windows). Эта "фича" транслирует 32-команды в 64-битные (не помню как точно описывается, но примерно так). Поэтому 32-битные приложения в винде работают медленнее на 5-15% чем в обычной ХРюше. Давно как-то читал статейку с выкладками по времени исполнения операций программами. Хотя щас могло все и поменяться - время прошло, мож чего-то наворотили в этом направлении.

Еще помню прибабах был у интеловских камней - они не умели одновременно выполнять 32-битное приложение и 64-битное. А АМД умел (типа архитектура другая и все такое). И было заключено то ли соглашение, то ли еще что-то, но в результате АМД "научила" интел как это делать, а интел в ответ дал разрешение использовать команды SSE3 в АМДшках. Могу где-то напутать, но примерно так обстояло дело. Поправьте меня если что.

← →
Смысл (2007-08-03 02:14) [25]

> Mystic © (01.08.07 11:00) [7]
> А что за программы? Большинству приложений и 32 битов не
> надо :) Вполне себе могли бы работать и в Win16.

О том и речь, что нафиг не нужно.

Всё уже придумано до нас. ©

А в шахматы не играю. Кроме шахмат есть ещё что-нибудь где от 64 есть толк?

> Смысл (01.08.07 02:11)
> Пересмотрел свои программы, ни одной 64 бита не нужно. Все
> и так прекрасно обходятся.

И команды проца ты тоже пересмотрел?
В асме или мнемонике?

> Смысл (03.08.07 02:14) [25]

> А в шахматы не играю. Кроме шахмат есть ещё что-нибудь где
> от 64 есть толк?

нету.... забей и выпей водки

← →
Смысл (2007-08-03 03:19) [28]

> oldman © (03.08.07 02:41) [26]
>
>
> > Смысл (01.08.07 02:11)
> > Пересмотрел свои программы, ни одной 64 бита не нужно.
> Все
> > и так прекрасно обходятся.
>
>
> И команды проца ты тоже пересмотрел?

Ты что, дурак?

> Смысл (03.08.07 03:19) [28]

Я то как раз нет...
Если ты думаешь, что 64 бита твоим программами не используются, это твои проблемы.

Alex Konshin © (01.08.07 12:28) [13]
знаком с длинными целыми - делал начиная от реализации самого длинного целова заканчивая RSA
Я намекну: Int1024 mul Int1024 - сколько умножений оперируя Int32 нужно сделать? и сколько нужно их сделать оперируя Int64?
что мой пример и доказывает что операций mul div при использовании Int64 меньше
Alex Konshin © (01.08.07 12:28) [13]
В алгоритмах умножении и делении столбиком обратная квадратичная зависимость
Ну так откуда цифра 4? обратная зависимость это 2^(1/2) Вот что значит отсутствие мат.образования :)

> Slym © (09.08.07 05:32) [30]
> Alex Konshin © (01.08.07 12:28) [13]
> знаком с длинными целыми - делал начиная от реализации самого
> длинного целова заканчивая RSA
> Я намекну: Int1024 mul Int1024 - сколько умножений оперируя
> Int32 нужно сделать? и сколько нужно их сделать оперируя Int64?
> что мой пример и доказывает что операций mul div при использовании
> Int64 меньше
> Alex Konshin © (01.08.07 12:28) [13]
> В алгоритмах умножении и делении столбиком обратная квадратичная
> зависимость
> Ну так откуда цифра 4? обратная зависимость это 2^(1/2)
> Вот что значит отсутствие мат.образования :)

У вас даже не с мат.образованием, а с арифметикой нелады. Операций меньше, но не в два, а в четыре раза.

1024 = 32 32bit цифр = 16 64bit цифр.
Для умножения столбиком 1024x1024 нужно 32x32 = 1024 32-bit умножений.
Для умножения столбиком 1024x1024 нужно 16x16 = 256 64-bit умножений.
Разница в 4(четыре) раза.

Для деления столбиком подсчитать сложнее и там зависит от конкретной реализации. Сложность даже при хорошей реализации выше, чем при умножении, но порядок тот же.

Короче, плохо вас математике учили. И не вам меня учить.

> Еще помню прибабах был у интеловских камней - они не умели
> одновременно выполнять 32-битное приложение и 64-битное.
>

Этот "прибабах" с Pentium Pro тянеться - он в 16-битном режиме напоминал 486 :-)

64 бита не нужны Найти похожие ветки