https://opennet.dev/openforum/vsluhforumID3/44449.html Компания Adobe выпустила (http://blogs.adobe.com/penguin.swf/2008/10/flash_player_10_is_live.html) финальный релиз<br>Flash Player 10 (http://labs.adobe.com/technologies/flashplayer10/releasenotes.html) (10.0.12.36 (http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15507&sliceId=1)) для платформ Linux, MacOS X и Windows. Версия для Solaris по прежнему имеет статус экспериментальной. <br><br>Главные новшества Adobe Flash Player 10:<br><br><br><br><br>- Реализована поддержка возможности создания 3D эффектов;<br>- Поддержка определения пользовательских фильтров;<br>- Новый движок для работы с текстом;<br>- Поддержка протокола RTMFP (Real Time Media Flow Protocol);<br>- Поддержка аудиокодека Speex;<br>- Реализован улучшенный API для отрисовки объектов и управления цветом;<br>- Значительно увеличена производительность отображения информации (GPU Compositing, GPU Blitting, новый движок для операций анти-алиасинга, поддержка векторных типов данных);<br>- Режим wmode transparent/opaque (Flash блок без созд...<br><br>URL: http://blogs.a https://opennet.dev/openforum/vsluhforumID3/44449.html#58 Mon, 20 Oct 2008 20:14:02 GMT &gt;Функция _всегда_ обязана сохранять в стек все используемые в ней регистры, <br><br>А не факт.Если заранее об этом договориться.И договариваются (это называется calling conventions): дескать вот в тех регистрах - исходные аргументы, а вон те вы не имеете права гробить и если они вам нужны, извольте сохранить их и потом вернуть как было, а вон те дескать - ваши и можете их засрать в свое удовольствие (а если они за каким-то вдруг нужны caller'у - пусть сам сохраняет!).<br><br>&gt;потому что в вызвавшей её функции они тоже могут использоваться. <br><br>Подсказываю: гуглим: AMD64 calling conventions. Например вот: http://www.x86-64.org/documentation/abi-0.99.pdf<br><br>&gt;Больше регистров, да еще и 64 битных - тормознее вызов функции. <br><br>В идеальном случае (обычная не очень сложная функция с небольшим числом параметров на вход которые указатели или числа, что чаще всего и бывает + не очень зубодробильные расчеты которые лезут в временные регистры отведенные для вызываемой функции) - насколько я понимаю тех push и pop которые делает х8 https://opennet.dev/openforum/vsluhforumID3/44449.html#57 Mon, 20 Oct 2008 10:11:09 GMT &gt;А их больше. Поэтому нужда сохранить регистры в стэк возникает гораздо реже.<br><br>Подумай еще раз.<br><br>Функция _всегда_ обязана сохранять в стек все используемые в ней регистры, потому что в вызвавшей её функции они тоже могут использоваться. Больше регистров, да еще и 64 битных - тормознее вызов функции. В остальном да - сложные функции используют стек меньше внутри себя - это те самые относительно редкие случаи где в общем получится более эффективный код.<br> https://opennet.dev/openforum/vsluhforumID3/44449.html#56 Fri, 17 Oct 2008 19:33:37 GMT &gt;Выгода только на очень узком множестве задач, <br><br>Это узкое множество задач - везде где переменные не влезают в 32 бита.А это ... ну, например, любая современная файловая система позволяет файлы крупнее 4Gb.А это автоматически означает работу с 64-битными числами.А как еще адресовать данные за пределами 2^32? :)<br><br>&gt;где голая математика и минимум обращений к памяти. <br><br>Память в современных системах не является узким местом AFAIK.Как ни странно.<br><br>&gt;В общем же случае пофик - что add+addc, <br><br>В х86 поскольку регистров не дофига только этим не отделаетесь.Придется скорее всего еще push-нуть регистры, потом pop-нуть.Ну и так далее.Сколько оно там займет времени и лишнего кода - тот еще вопрос.Посему когда заходит вопрос об интенсивных 64-битных вычислениях, х86 в 32-битном режиме заметно сливает.Что впорчем неудивительно - быстрее хардварного выполнения операций "в лоб" в равноправных регистрах трудно что-то придумать.<br><br>&gt;что addq выполнятся мгновенно по сравнению с обращениями к памяти. <br><br>У современной многока https://opennet.dev/openforum/vsluhforumID3/44449.html#55 Fri, 17 Oct 2008 18:14:54 GMT &gt; В общем же случае пофик - что add+addc, что addq выполнятся мгновенно по сравнению с обращениями к памяти. Распараллеливание инструкицй тоже никто не отменял, так что в итоге прироста там - от силы несколько процентов.<br><br>adc ждет результата add и следовательно распараллеливание идет лесом.<br>Так же пара add+adc может застопорить конвеер. Спасти может только смешивание этих инструкций с другим кодом, что не всегда возможно.<br><br>Время обращения к памяти -- это проблема... Но не в данном случае.<br>Скорость чтения/записи одного 64битного числа в регистр больше, чем чтение 32бит в регистр (одновременная загрузка в кэш) и после выполнения add чтение из кэша следующих 32бит.<br><br><br>&gt;&gt; не надо лишний раз бесполезно сохранять\восстанавливать дурные х86 регистры<br>&gt;Да что ты? А `не дурные' 64битные регистры не надо значит сохранять/восстанавливать?<br><br>Речь не про ширину регистров, а про их количество.<br> https://opennet.dev/openforum/vsluhforumID3/44449.html#54 Fri, 17 Oct 2008 16:32:14 GMT &gt;бред полный, скорость растет только на операциях где много вычислений типо шифрования, <br>&gt;все остальное работает или так-же или медленнее <br>&gt;http://www.fcenter.ru/online.shtml?articles/hardware/processors/11868 <br><br>Статья от 08.02.2005 ::LoL::<br>В 2005 году нативных программ для win64 практически небыло, а эмуляция win32 для запуска старых программ, скорости добавить не могла по определению.<br><br>В задачах шифрования используется сверх большие числа (&gt;128бит).<br>Замена 4 операций 32бит на 2 операции 64бита _может_ увеличить скорость в 2 раза.<br>Но это -- частный случай, и рассматривать далее нет смысла.<br><br>При перекомпиляции на 64бита, оптимизатор получает бОльший регистровый пул.<br>Следовательно:<br>1) ускоряется передача параметров при вызове функций/процедур<br>2) возможно хранить больше временных переменных в сверх-быстрой памяти<br>3) планировщик инструкций сможет оптимальней загрузить конвеер<br><br>Так-же компилятору не надо ограничиваться устаревшими инструкциями, <br>для мифической совместимости с i80386.<br><br>&gt;на флеше https://opennet.dev/openforum/vsluhforumID3/44449.html#53 Fri, 17 Oct 2008 12:38:43 GMT &gt;А Вы еще на 32 ??? <br><br>тогда мы идем к вам ))))))))))))))<br><br> https://opennet.dev/openforum/vsluhforumID3/44449.html#52 Fri, 17 Oct 2008 08:51:49 GMT &gt; Тут кой-кто имхо неправ - если обычный код оперирует 64-битными переменными то ему<br>&gt; 64-битные регистры здорово удобнее - потребная операция часто делается 1 машинной командой.<br><br>Выгода только на очень узком множестве задач, где голая математика и минимум обращений к памяти. В общем же случае пофик - что add+addc, что addq выполнятся мгновенно по сравнению с обращениями к памяти. Распараллеливание инструкицй тоже никто не отменял, так что в итоге прироста там - от силы несколько процентов.<br><br>&gt; не надо лишний раз бесполезно сохранять\восстанавливать дурные х86 регистры<br><br>Да что ты? А `не дурные' 64битные регистры не надо значит сохранять/восстанавливать?<br> https://opennet.dev/openforum/vsluhforumID3/44449.html#51 Fri, 17 Oct 2008 04:21:49 GMT А вот новый gnash порадовал!<br>Многое увидел впервые :)<br> https://opennet.dev/openforum/vsluhforumID3/44449.html#50 Fri, 17 Oct 2008 00:08:53 GMT &gt;почти во всех :-))! какой размер регистра в FPU? <br><br>Тут кой-кто имхо неправ - если обычный код оперирует 64-битными переменными то ему 64-битные регистры здорово удобнее - потребная операция часто делается 1 машинной командой.<br><br>Еще стоит заметить что в х64 режиме регистры не просто 64-битные, их еще и заметно больше и они равноправны.Даже код которому 64 бита в переменных не надо может выиграть на том факте что не надо лишний раз бесполезно сохранять\восстанавливать дурные х86 регистры чтобы в них поделать что-то еще - в х64 регистров куда чаще будет хватать на все вычисления без бесполезных push и pop которые в сумме обычно эквивалентны NOP по результату и нужны только чтобы в занятых регистрах можно было временно поделать еще что-то другое :)<br>