![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
"640 k ought to be enough for anyone"
прошло каких-то 25 лет; и, пожалуйста, 4gb памяти стоят сто баксов с хвостиком,
а винды могут использовать только 3.25 GB.
Фотошоп же, саббака, видит только 1.7GB.
Прийдется читать мануалы и выянять - знают ли адобовские программисты про PAE/4GT/AWE32 ...
а винды могут использовать только 3.25 GB.
Фотошоп же, саббака, видит только 1.7GB.
Прийдется читать мануалы и выянять - знают ли адобовские программисты про PAE/4GT/AWE32 ...
no subject
no subject
Оси есть, драйверов и приложений нет.
И реально выгодно только если данных много гигов.
Классический замкнутый круг. Но, лействительно, большинству пользователей это еще не надо.
no subject
no subject
"честные" int64 хороши когда они действительно есть.
скорость операции 2+2 не увеличится. И, как верно заметили в вашей ссылке, удваиваются расходы на хранение и перенос.
Т.е. с 32b/4GB имеет смысл переходить на 64b/8GB
no subject
Про int64 в какой-то мере согласен :) Коли нет, то и нет...
2+2, конечно, остаётся прежним, но если мы начинаем говорить о синусе или, там, экспоненте, то на одном факте наличия дополнительных регистров 10-30% (я этим занимаюсь профессионально и говорю вполне уверенно :)
Про удваивание расходов - это не так! Удваиваются только указатели. Но большая часть данных лежащих в памяти - это вовсе не указатели... Каков процент указателей 2%,5%,15%? Всё зависит от задачи... Тогда при чем здесь удвоение расходов по памяти?
no subject
Насколько я понимаю - нет. Это решение архитектора процессора.
x86-64 - 16, UltraSparc, Power, Alpha - 32,
Itanium - 128. И, надо заметить, не в коня корм.
exe/dll файлы автоматически удвваиваются.
int64 MyArray[1000] не может занимать столько же места, столько int32 MyArray[1000].
соотвественно, программа где используется просто integer - раздует расход памяти.
а чем, если не секрет?
no subject
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-битным, так и остался...
а чем я занимаюсь - оптимизацией (в том числе и на уровне ассемблера) кода для нескольких математических библиотек под разные платформы :)
no subject
no subject
http://www.viva64.com/articles/20_issues_of_porting_C++_code_on_the_64-bit_platform.html
no subject
В общем, за несколько месяцев тестов ошибок нашли несколько сотен, причем разного характера: от банального переполнения стека или выхода за пределы массивов до путаницы в самом алгоритме. Ну а в итоге 32-битная версия все равно уступала исходной, и по стабильности, и по выдаваемому результату.
Благодарю за инфу