Компания Adobe выпустила (http://blogs.adobe.com/penguin.swf/2008/10/flash_player_10_i...) финальный релиз
Flash Player 10 (http://labs.adobe.com/technologies/flashplayer10/releasenote...) (10.0.12.36 (http://kb.adobe.com/selfservice/viewContent.do?externalId=tn...)) для платформ Linux, MacOS X и Windows. Версия для Solaris по прежнему имеет статус экспериментальной.Главные новшества Adobe Flash Player 10:
- Реализована поддержка возможности создания 3D эффектов;
- Поддержка определения пользовательских фильтров;
- Новый движок для работы с текстом;
- Поддержка протокола RTMFP (Real Time Media Flow Protocol);
- Поддержка аудиокодека Speex;
- Реализован улучшенный API для отрисовки объектов и управления цветом;
- Значительно увеличена производительность отображения информации (GPU Compositing, GPU Blitting, новый движок для операций анти-алиасинга, поддержка векторных типов данных);
- Режим wmode transparent/opaque (Flash блок без созд...URL: http://blogs.adobe.com/penguin.swf/2008/10/flash_player_10_i...
Новость: http://www.opennet.me/opennews/art.shtml?num=18418
64-битной версии, я так понимаю, нет?
>64-битной версии, я так понимаю, нет?как же вы забодали со своими 64 битами.
что в этих системах такого крутого, из-за чего на них стоит переходить, отказавшись от 32?
разве что только ради нытья, что что-то там разработчики не учли, где-то что-то не поддерживается и т.д. и т.п..
на 16 бит не хотите вернуться?
все равно это случится, многие уже 64 бита юзают, серверы наверное скоро вообще перестанут быть 32 битными - 4ГБ уже не так уж и много, а кое где и мало. И десктопам туда же дорога.
>серверы наверное скоро
>вообще перестанут быть 32 битными - 4ГБ уже не так уж
>и много, а кое где и мало. И десктопам туда же
>дорога.Насколько я понимаю, 32 бита быстрей выполняет многие операции, чем 64
> Насколько я понимаю, 32 бита быстрей выполняет многие операции, чем 64Не правильно понимаешь.
1) Простая перекомпиляция на 64бит увеличивает скорость на ~20%.
2) На системах с озу >= 2ГБ, 64битная система -- необходимость.Итог: Говноподелия от Adobe только тормозят прогресс.
>1) Простая перекомпиляция на 64бит увеличивает скорость на ~20%.бред полный, скорость растет только на операциях где много вычислений типо шифрования, все остальное работает или так-же или медленнее
http://www.fcenter.ru/online.shtml?articles/hardware/process...>2) На системах с озу >= 2ГБ, 64битная система -- необходимость.
на флеше все не сошлось, подумай об отсутствии драйверов например, особенно на старое железо
>бред полный, скорость растет только на операциях где много вычислений типо шифрования, все остальное работает или так-же или медленнее64-х битные системы действительно быстрее (даже только благодаря компиляции. за один такт из ОЗУ в регистр в 2-а раза больше инфы идет. :-D)
но это только на "честных" системах (например, SPARC'ах)
а на обычных машинах:
xxx$cat /proc/cpuinfo
....
address sizes : 36 bits physical, 48 bits virtual
....т.е 2^36 - 68'719'476'736 - за один такт, всё что выше - мультиплексируется
>>2) На системах с озу >= 2ГБ, 64битная система -- необходимость.
>на флеше все не сошлось, подумай об отсутствии драйверов например, особенно на старое железоа при чём здесь флэшь?!!!
речь про ОЗУ!
в 32-битной схеме больше 3Gb процесс получить не может.
>из ОЗУ в регистр в 2-а раза больше инфы идет. :-D)Эээ вы бы разобрались с тем какие биты, сколько и где, если уж откомментить хочется?Есть подозрение что вы ширину шины, разрядность проца и адресное пространство путаете ;)
На самом деле производительность примерно как у 32-бит системы, плюс-минус лапоть.На 64-битных операциях может однако быть и заметно быстрее.Потому что пока из нескольких 32-битных регистров изобразишь аналог 64-битной математической операции - потребуется вагон команд и масса левых действий.В то время как в 32-битном режиме имеющаяся в каждом современном проце х64 часть будет тупо ничего не делать.А вот если в системе 4Gb RAM или более, НЕ использовать х64 - уже слегка дрочерство на мое имхо.
>на флеше все не сошлось, подумай об отсутствии драйверов например, особенно на
>старое железо1) 64 бита и старое железо - плохо своместимые понятия.
2) Расскажите мне плиз каких же таких драйверов мне там не хватает?
А вот адобе отдельный факофф - вот за это я и не люблю проприетарщиков.Сроду пытаются навязать выбор платформ и технологий.Флеш запустить можно и в 32 битах, но это то же самое как в обычной 32-битной винде пользоваться 16-битными програмами из Win 3.1 - вроде работает, но поганенько, через анус и не 100.0% совместимо с 3.1 поэтому все живые вендоры давно переписали виндовые программы на 32-битные варианты.Вот и тут не развалятся под 64 бита скомпилить, фигли.
>бред полный, скорость растет только на операциях где много вычислений типо шифрования,
>все остальное работает или так-же или медленнее
>http://www.fcenter.ru/online.shtml?articles/hardware/process...Статья от 08.02.2005 ::LoL::
В 2005 году нативных программ для win64 практически небыло, а эмуляция win32 для запуска старых программ, скорости добавить не могла по определению.В задачах шифрования используется сверх большие числа (>128бит).
Замена 4 операций 32бит на 2 операции 64бита _может_ увеличить скорость в 2 раза.
Но это -- частный случай, и рассматривать далее нет смысла.При перекомпиляции на 64бита, оптимизатор получает бОльший регистровый пул.
Следовательно:
1) ускоряется передача параметров при вызове функций/процедур
2) возможно хранить больше временных переменных в сверх-быстрой памяти
3) планировщик инструкций сможет оптимальней загрузить конвеерТак-же компилятору не надо ограничиваться устаревшими инструкциями,
для мифической совместимости с i80386.>на флеше все не сошлось, подумай об отсутствии драйверов например, особенно на
>старое железоЭто всё пройденный этап. вспомни переход на 32бита.
Драйвера для _актуального_ железа появились в кратчайшие сроки.
Остальные... когда производители железа поняли, что паровоз ушел.
>1) Простая перекомпиляция на 64бит увеличивает скорость на ~20%.только для чисел с 64-битным представлением, если число умещается в 32, то ни 64, ни 128, и любое 2 в степени n, размер регистра, не изменят вычислений. Весь смысл увеличения разрядности в том, что если раньше число грузилось частями кратными 32 (16), то сейчас оно грузится в регистр сразу целиком (если 64, по две если 128). простая перекомпиляция не даст ничего, если вы не используете плавающую арифметику, или космические числа, 2 в степени 64
числа?
да работа с ними давно уже оптимизирована во всех языках программирования (ну почти во всех :-))! какой размер регистра в FPU?а вот работа со строками, массивами, контейнерами,.. со всякой мультимедия...
и вот здесь даже иногда кроме перекомпиляции под 64 бита особо делать ничего и не надо.
>почти во всех :-))! какой размер регистра в FPU?Тут кой-кто имхо неправ - если обычный код оперирует 64-битными переменными то ему 64-битные регистры здорово удобнее - потребная операция часто делается 1 машинной командой.
Еще стоит заметить что в х64 режиме регистры не просто 64-битные, их еще и заметно больше и они равноправны.Даже код которому 64 бита в переменных не надо может выиграть на том факте что не надо лишний раз бесполезно сохранять\восстанавливать дурные х86 регистры чтобы в них поделать что-то еще - в х64 регистров куда чаще будет хватать на все вычисления без бесполезных push и pop которые в сумме обычно эквивалентны NOP по результату и нужны только чтобы в занятых регистрах можно было временно поделать еще что-то другое :)
> Тут кой-кто имхо неправ - если обычный код оперирует 64-битными переменными то ему
> 64-битные регистры здорово удобнее - потребная операция часто делается 1 машинной командой.Выгода только на очень узком множестве задач, где голая математика и минимум обращений к памяти. В общем же случае пофик - что add+addc, что addq выполнятся мгновенно по сравнению с обращениями к памяти. Распараллеливание инструкицй тоже никто не отменял, так что в итоге прироста там - от силы несколько процентов.
> не надо лишний раз бесполезно сохранять\восстанавливать дурные х86 регистры
Да что ты? А `не дурные' 64битные регистры не надо значит сохранять/восстанавливать?
> В общем же случае пофик - что add+addc, что addq выполнятся мгновенно по сравнению с обращениями к памяти. Распараллеливание инструкицй тоже никто не отменял, так что в итоге прироста там - от силы несколько процентов.adc ждет результата add и следовательно распараллеливание идет лесом.
Так же пара add+adc может застопорить конвеер. Спасти может только смешивание этих инструкций с другим кодом, что не всегда возможно.Время обращения к памяти -- это проблема... Но не в данном случае.
Скорость чтения/записи одного 64битного числа в регистр больше, чем чтение 32бит в регистр (одновременная загрузка в кэш) и после выполнения add чтение из кэша следующих 32бит.
>> не надо лишний раз бесполезно сохранять\восстанавливать дурные х86 регистры
>Да что ты? А `не дурные' 64битные регистры не надо значит сохранять/восстанавливать?Речь не про ширину регистров, а про их количество.
>Выгода только на очень узком множестве задач,Это узкое множество задач - везде где переменные не влезают в 32 бита.А это ... ну, например, любая современная файловая система позволяет файлы крупнее 4Gb.А это автоматически означает работу с 64-битными числами.А как еще адресовать данные за пределами 2^32? :)
>где голая математика и минимум обращений к памяти.
Память в современных системах не является узким местом AFAIK.Как ни странно.
>В общем же случае пофик - что add+addc,
В х86 поскольку регистров не дофига только этим не отделаетесь.Придется скорее всего еще push-нуть регистры, потом pop-нуть.Ну и так далее.Сколько оно там займет времени и лишнего кода - тот еще вопрос.Посему когда заходит вопрос об интенсивных 64-битных вычислениях, х86 в 32-битном режиме заметно сливает.Что впорчем неудивительно - быстрее хардварного выполнения операций "в лоб" в равноправных регистрах трудно что-то придумать.
>что addq выполнятся мгновенно по сравнению с обращениями к памяти.
У современной многоканальной оперативки как правило нет никаких проблем накормить ядро инструкциями и данными до предела его возможностей.Ее bandwidth хватает с запасом а на остальное есть префетч и кеши, как раз для компенсации латентностей.В результате на современных системах с быстрой 2-3 канальной памятью и неслабыми кэшами имхо еще вопрос пофиг это или нет.Судя по тому что оптимизация архитектуры процессора дает большой эффект (как в случае кор2) - времена выполнения команд и т.п. все-таки не пофиг.
>Распараллеливание инструкицй тоже никто не отменял,
А еще у х64 регистров здорово больше.Равноправных при том.Как бы тоже вместо долгой и нудной перетасовки чисел туда-сюда в нескольких куцых 32-битных регистрах можно все сделать в нескольких 64-битный регистрах чисто аппаратно.При том на каждое 64-битное действие на 32-битном проце потребуется довольно много операций.Add + Adc это конечно круто а ничего что содержимое регистров при этом сменится?Совсем не факт что старое было нафиг не нужно.Да и результат куда-то придется девать потом если регистры еще для чего-то нужны.А в х64 регистров может хватить на все и без нудных push\pop пачками...
>так что в итоге прироста там - от силы несколько процентов.
От задачи зависит очень.
>Да что ты? А `не дурные' 64битные регистры не надо значит сохранять/восстанавливать?
А их больше.Поэтому нужда сохранить регистры в стэк возникает гораздо реже.Например вызов функции.В x86 push параметров в стэк вызывающим и pop на стороне функции, тут все понятно - куцесть регистров ведет к неизбежному срачу в стэк и потом разгребанию оного.Ну и локально в функции придется возможно не раз пихать регистры в стэк если надо что-то посчитать а промежуточные значения регистров были не пофигу.Неизбежно придется сделать эти бесполезные действия потому что регистров элементарно мало и на все параметры и временные переменные 1 фиг как правило не хватит.А в х64 можно параметры тупо в регистрах передать а если повезет то незаюзанных регистров еще на временные локальные переменные останется.По-моему (боюсь соврать, гуру поправьте) если параметров у функции мало - х64 компилеры в этом случае не юзают стэк обходясь сугубо регистрами передавая функциям параметры в них.
>А их больше. Поэтому нужда сохранить регистры в стэк возникает гораздо реже.Подумай еще раз.
Функция _всегда_ обязана сохранять в стек все используемые в ней регистры, потому что в вызвавшей её функции они тоже могут использоваться. Больше регистров, да еще и 64 битных - тормознее вызов функции. В остальном да - сложные функции используют стек меньше внутри себя - это те самые относительно редкие случаи где в общем получится более эффективный код.
>Функция _всегда_ обязана сохранять в стек все используемые в ней регистры,А не факт.Если заранее об этом договориться.И договариваются (это называется calling conventions): дескать вот в тех регистрах - исходные аргументы, а вон те вы не имеете права гробить и если они вам нужны, извольте сохранить их и потом вернуть как было, а вон те дескать - ваши и можете их засрать в свое удовольствие (а если они за каким-то вдруг нужны caller'у - пусть сам сохраняет!).
>потому что в вызвавшей её функции они тоже могут использоваться.
Подсказываю: гуглим: AMD64 calling conventions. Например вот: http://www.x86-64.org/documentation/abi-0.99.pdf
>Больше регистров, да еще и 64 битных - тормознее вызов функции.
В идеальном случае (обычная не очень сложная функция с небольшим числом параметров на вход которые указатели или числа, что чаще всего и бывает + не очень зубодробильные расчеты которые лезут в временные регистры отведенные для вызываемой функции) - насколько я понимаю тех push и pop которые делает х86 - нафиг не надо.Вызывающий не будет расчитыывать что временные регистры не засрут а вызываемая функция может юзать группу регистров под временные расчеты, которые как раз можно с чистой совестью загадить.
>В остальном да - сложные функции используют стек меньше внутри себя - это
>те самые относительно редкие случаи где в общем получится более эффективный
>код.Вы еще про calling conventions забыли :).Если что насколько я помню линухи юзают описанные в амдшных доках методы (т.е. по идее ссылка которая выше вполне применима).Ну а майкрософт как всегда попер своим путем =).Впрочем скажем честно - с дизассемблером я не корпел так что если наврал местами - I'm sorry.Общая идея надеюсь все-таки понятна.
не быстрее а также, видео кодирует быстрее около 10-15%.
С таким же успехом можно говорить зачем 2-4 ядра, для adobe оно не надо, но я люблю смотреть fullHD
>на 16 бит не хотите вернуться?
>все равно это случится, многие уже 64 бита юзают, серверы наверное скоро
>вообще перестанут быть 32 битными - 4ГБ уже не так уж
>и много, а кое где и мало. И десктопам туда же
>дорога.Не пользуйтесь ява-поделиями.
>разве что только ради нытья,Ага, конечно.Когда у вас будет больше пары гиг оперативы - тогда возвращайтесь, поговорим более конструктивно.Хотя некоторые красноглазые некрофилы наверняка умудрятся поюзать какую-нить хрень типа PAE лишь бы держаться за привычный им кусок х86 гуано :)
Запрет исполнения секций не содержащих код.
Мало ? ;)
легко можно обойти сие так называемое ограничение
А Вы еще на 32 ???
>А Вы еще на 32 ???тогда мы идем к вам ))))))))))))))
> как же вы забодали со своими 64 битами.
> что в этих системах такого крутого, из-за чего на них стоит переходить, отказавшись от 32?Посмотрим на это с другой стороны. Что хорошего в i386, кроме эксклюзивной поддержки её такими вещами, как Adobe Flash Player?
А собственно на 64 бита какой компании будем переходить? AMD это ещё не 64 бита, Intel - нет обратной совместимости.
>А собственно на 64 бита какой компании будем переходить? AMD это ещё
>не 64 бита, Intel - нет обратной совместимости.А мужики то незнают)))
>А собственно на 64 бита какой компании будем переходить? AMD это ещё
>не 64 бита, Intel - нет обратной совместимости.ого! анабиоз уже изобрели?
http://ru.wikipedia.org/wiki/Amd64
ищем фразы "AMD64" и "EM64T"...или Вы всё ещё титаниумы покупаете?
http://ru.wikipedia.org/wiki/Itanium
ищем фразу "Itanic"
Как же вы задолбали со своими древними тачками. У меня 8 гигабайт памяти.PS: О PAE знае, но не хочу.
>Как же вы задолбали со своими древними тачками. У меня 8 гигабайт
>памяти.
>
>PS: О PAE знае, но не хочу.Патрег в слаку не вкомпилировал поддержку более 4 Гб рам (надож так лажануться то. ну не видел он компьютеров с больше чем 4 Гб)? сочувствую. выбирай неламерский дист.
у меня тоже 8.
Что такое шлака? А, припоминаю, это то говно, в котором я в 98 году CDE собирал...
ВСЕ СУПЕР! ВСЕ БАГИ УБРАЛИ!! только нету ppc версии
Судя по http://blogs.adobe.com/penguin.swf/2008/08/library_expansion... Adobe Flash Player 10 в отличие от 9 больше от Gtk не зависит? Или я ошибаюсь, не там смотрю?
$ ldd libflashplayer.so |grep gtk
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6f7d000)
А нам все равно, Нам не нужно их *но!
Режим wmode transparent/opaque (Flash блок без создания нового окна, что позволяет разместить html/javascript блоки поверх flash или создать прозрачный ролик поверх текущего окна);
Уже представляю, какие будут хитрые баннеры, что пользователи будут уверенно тыкать на привычные линки, а попадать х.з. куда.
Это напоминает click hijacking, только более мирный вариант.
>Уже представляю, какие будут хитрые баннеры, что пользователи будут уверенно тыкать на
>привычные линки, а попадать х.з. куда.
>Это напоминает click hijacking, только более мирный вариант.ДА НАДО УЖЕ СЕЙЧАС НАЧАТЬ С ЭТИМ БОРОТЬСЯ!!!
Browser падает при открытии любого флэша (пробовал 3 разных сайта).
OS: x86_64
Firefox 3.0.3
Flashplayer 10.0.12.36
>Browser падает при открытии любого флэша (пробовал 3 разных сайта).
>OS: x86_64
>Firefox 3.0.3
>Flashplayer 10.0.12.36А браузер 64 битный? Я юзал одно время бету но она комп просто ложила, все работало нормально, браузер i386
Что за слово-паразит «анонсирован»? Не лучше ли написать «выпущен».
>Что за слово-паразит «анонсирован»? Не лучше ли написать «выпущен».Прежде чем писать - посмотри в словарях... значения этих слов разные!
Я понимаю, что значения разные поэтому и пишу. «Анонсирован» в данном случае — это калька с английского announсed ( http://lingvo.yandex.ru/en?text=announced&from=os&st_transla... ), и в данном контексте оно как раз и переводится как "выпускать" или "публиковать".
>Что за слово-паразит «анонсирован»? Не лучше ли написать «выпущен».Правильное слово "объявлен". Точнее, объявлено о выпуске/выходе.
У кого-нить на smotri.com оно работает?Ещё почему-то в ubuntu 8.04 он не смог поставится пока я не снёс пакет с 9ым флешем (flashplayer-nonfree)
Да, работает.
А для чего флэшплэир нужен? С ТыТрубы скрипт на перле смотрит, а что быдло банеров нет, так даже лучше, чего все так прутся от флэша?64 бит ОСь нужна, на 32 битной фиг увидиш 512ГБ рамы.
Свершилось. Хороший релиз, который не вылетает.
Нафиг он нужен.
Это какието стуки из другого мира.
Пока его не сделают портируемым это технология для домашних пользователей
Очередная дыра в броузере никому не помешает :)
Имею core 2, т.е. amd64. Прикачал, захотел поставить подперев nspluginwrapper. Оно мне отвечает, libss3.so типа нету. Понял, это оно имеет ввиду 32-битную вещь. Думал, разыскивать это so и что делать, если опять чего-то надо будет 32-битного. Решил, что как только gnash будет проигрывать видео с bbc.co.uk, пошлю flashplayer туда, куда унесся silverlight.
> Решил, что как только gnash будет проигрывать видео с bbc.co.uk, пошлю flashplayer туда, куда унесся silverlight.swfdec пробовали?
ага.
Главный флешь на макромедиа.ком не кажет :(
>swfdec пробовали?Вдохновился, попробовал -- дуля с маком. Выпил, образно выражаясь, стакан водки, выругался легким матом и поставил flashplayer взад.
А вот новый gnash порадовал!
Многое увидел впервые :)