"640 k ought to be enough for anyone"

[lamantyn]

прошло каких-то 25 лет; и, пожалуйста, 4gb памяти стоят сто баксов с хвостиком,
а винды могут использовать только 3.25 GB.

Фотошоп же, саббака, видит только 1.7GB.
Прийдется читать мануалы и выянять - знают ли адобовские программисты про PAE/4GT/AWE32 ...

Comments

[iburyl.livejournal.com]

Есть 64-битные оси... Я вот ни как не пойму почему все до сих пор сидят на 32-битных осях, в то время как каждый первый проц, который вы можете купить в наше время, поддерживает работу с 64-битными адресами... И особенно это относится к программистам из Adobe! Они до сих пор не выпустили продукт под 64-битную адресацию... Тут они объясняют почему... Главная проблема - пользователи не переходят, потому что девелоперы не уделяют этому достаточно внимания, а девелоперы считают, что еще не достаточно много пользователей сидят на 64-битных осях...

[lamantyn.livejournal.com]

Есть 64-битные оси...

Оси есть, драйверов и приложений нет.
И реально выгодно только если данных много гигов.

пользователи не переходят, потому что

Классический замкнутый круг. Но, лействительно, большинству пользователей это еще не надо.

[iburyl.livejournal.com]

Кроме 64-битной адрессации, есть "честные" 64-битные целые числы и регистров вдвое больше. Только от увеличения количества регистров производительность на казалось бы пустом месте подымается процентов на 10-30 (если кто-то вообще заморачивался писать код худо-бедно оптимизированным)...

[lamantyn.livejournal.com]

Количество регистров - волюнтаризм, от разрядности не зависит.
"честные" int64 хороши когда они действительно есть.
скорость операции 2+2 не увеличится. И, как верно заметили в вашей ссылке, удваиваются расходы на хранение и перенос.
Т.е. с 32b/4GB имеет смысл переходить на 64b/8GB

[iburyl.livejournal.com]

Количество регистров по факту поставляется нам в одном пакете с разрядностью - если Вындовс 32-битный, то и дополнительные регистры не поддерживает.
Про int64 в какой-то мере согласен :) Коли нет, то и нет...
2+2, конечно, остаётся прежним, но если мы начинаем говорить о синусе или, там, экспоненте, то на одном факте наличия дополнительных регистров 10-30% (я этим занимаюсь профессионально и говорю вполне уверенно :)
Про удваивание расходов - это не так! Удваиваются только указатели. Но большая часть данных лежащих в памяти - это вовсе не указатели... Каков процент указателей 2%,5%,15%? Всё зависит от задачи... Тогда при чем здесь удвоение расходов по памяти?

[lamantyn.livejournal.com]

Количество регистров по факту поставляется нам в одном пакете с разрядностью

Насколько я понимаю - нет. Это решение архитектора процессора.
x86-64 - 16, UltraSparc, Power, Alpha - 32,
Itanium - 128. И, надо заметить, не в коня корм.

Удваиваются только указатели

exe/dll файлы автоматически удвваиваются.
int64 MyArray[1000] не может занимать столько же места, столько int32 MyArray[1000].
соотвественно, программа где используется просто integer - раздует расход памяти.

этим занимаюсь профессионально

а чем, если не секрет?

[iburyl.livejournal.com]

"Насколько я понимаю - нет. Это решение архитектора процессора.
x86-64 - 16, UltraSparc, Power, Alpha - 32,
Itanium - 128. И, надо заметить, не в коня корм."

По факту... Если код был скомпилирован под платформу Intel 64 (aka em64t) или оно же AMD64 (aka x86-64)... То мы одновременно получаем больше регистров и большие указатели, но теряем возможность запускаться в 32-бит осях... Если мы скомпилировались 32-битным компилятором, то мы теряем лишние регистры и указатели...

Про Итан - песня отдельная... Архитектура - загляденье, но чисто техническая нехватка герцев - вот это косяк... А писать что-то под Итан на ассемблере - вот оно счастье :)

exe/dll файлы не удваиваются... на практике могут даже уменьшится (не надо тащить спец оптимизации под старые архитектуры)... но в большинстве случаев некоторое увеличение, конечно, происходит... однако не exe'шники занимают подавляющую часть вашего винта/RAM'а ;)

если у вас раньше был int64, то и он занимал 64-бита, но работал медленно (эмулировался софтварно), а теперь быстрее.
если у вас раньше был int32, то и теперь он занимает 32-бита - он ни куда не делся... на примере C/C++ тип int как был раньше 32-битным, так и остался...

а чем я занимаюсь - оптимизацией (в том числе и на уровне ассемблера) кода для нескольких математических библиотек под разные платформы :)

[durman-trava.livejournal.com]

большой объем кода и как следсвие большое количество скрытых багов, которые всплывут при переходе с 32 на 64?

[lamantyn.livejournal.com]

Ну это нельзя назвать именно багами.

http://www.viva64.com/articles/20_issues_of_porting_C++_code_on_the_64-bit_platform.html

[durman-trava.livejournal.com]

Да я неско другое имел в виду - моя недолгая карьера программиста началась с портирования одного проекта с 16 на 32.
В общем, за несколько месяцев тестов ошибок нашли несколько сотен, причем разного характера: от банального переполнения стека или выхода за пределы массивов до путаницы в самом алгоритме. Ну а в итоге 32-битная версия все равно уступала исходной, и по стабильности, и по выдаваемому результату.

Благодарю за инфу

[wahkunaafejo.livejournal.com]

Прочитал, конечно, далеко от моей темы. (http://zimnyayaobuv.ru/) (http://zimnyaya-obuv.ru/)