Adobe发布64位Flash Player “Square”

Adobe今天公布了64位版本的Flash Player，可工作于Windows、Mac和Linux，并提供对IE9的支持。
新版被命名为 "Flash Player Square"，为刚刚发布的IE9量身定制，提供了更强大的硬件加速能力，只要支持Flash 10.1的环境下均可以兼容运行，不过并不支持Windows XP，您现在就可以下载该版本体验：

http://labs.adobe.com/technologies/flashplayer10/

Adobe Labs: Flash Player "Square" Preview Release

Version Preview 2
Date Sep 27, 2010

http://labs.adobe.com/downloads/flashplayer10.html

来个X86和x64跑分比赛？

再下去就装LINUX了....发挥X86的余热把....

racca：

这孩子, 撞到头了....
1. 位数跟大小没多少关系. x87早就有80-bit浮点数字了, 也有个20年了.
2. 32-bit无法利用64-bit的寄存器, 数目减半, 大小再减半. 你所谓的4-byte是不用白不用的东西, 反正不能拆开来给两个32-bit用. 到底哪个更浪费显然一目了然.
3. 32-bit下连访问4GB的文件都要做memory-mapping
4. WinServer也只能用2GB空间而已, 无论物理内存多大, 对于任意程序都是2GB(可选3GB)
5. 游戏代码大小根本无足轻重, 重要的是所有的文件都必须映射到内存里才能用, 32-bit下作大文件内存映射效率异常低下. 这才是速度慢的根源.
6. 多了的8个寄存器和现在处理器$的大小足以抵消pointer带来的损失并带来免费的性能提升, 少数领域比方AES里多出的寄存器至关重要.
7. 大内存用户用64bit Windows是理所当然的, 不仅仅是内核限制, 驱动在32bit强制破解后也会不稳定. 就是因为超过3GB的部分在驱动里映射很麻烦. 性能也比较低下. Server版只要有吞吐量就行了, 驱动就那屈指可数的几个. 好解决. 桌面就没那么简单了.
8. 如上, 用了x64版, 在加上WOW64模拟本就是缓兵之计, 你还真当神器了?回到原帖

我撞到头了?!

我只问一个问题, 给你同样多的逻辑门, 你是做所有晶体管都能发挥作用的 32b 还是要浪费一半的 64b ? 不用白不用? 想到总线没有? 你白用的4b 在消耗着数据总线带宽知道么. 总线传输可不认得 MOVSX MOVZX 指令. 寄存器个数, 只要 INTEL想, 它完全有能力在 32b 的基础上扩充, 另外我讲的32b 和 64b 完全由硬件出发, 别把 microsoft 的 bug 套到 intel 头上.
寄存器对AES重要? 寄存器对谁不重要?! 为什么 INTEL 不跨越16个直接来256个寄存器? INTEL x86 x64 本质上是 CISC 指令构架, 并不如 RISC 那么容易并行化, 所以寄存器数量很难引发效能提升, 另一方面 16个寄存器也不是没代价. 你看到AES计算性能上的提升,为啥看不到任务切换时的损耗? AES总不会比任务切换来的常见吧 ?
x64 于 x86 不同于 8086 到 80386. 32b 对个人应用的是最适合的.  在这个位数上能够得到最大的效能比. 而对于大型应用, x86 体系就是渣. x86 包括现在的 x64 指令构架还没 7,80 年代的 6800/68000 先进.

现在还有吐糟64位的.....
LS真够耐心的....

arch7819：为啥都喜欢用x64, 其实我个人觉得x86 比 x64要好点.
你想啊我们用的数字能超过2^31-1的地方不多, 32b 是4byte, 64b 是 8byte, 对于99.9%的运算, 64b 白白浪费了4个字节参与运算. 这部分的运算资源如果给32b 使用, 无疑损失0.1%而在 99.9% 得到补偿.

还有32b 地址一个段最大4gb, 个人pc有多少软件需要访问4gb的空间? 而且这只是一个段, 系统寄存器 CS 代码段不可能用到4G(代码4g是不可能的,10g的游戏有100M的代码就算了不起了). DS ES FS GS 可以保证同时访问 4*4GB 的空间而不需额外的操作. SS堆栈段要是能用到4G那绝对是无穷递归.

32位的3.25g限制实际上是microsoft的bug.
server版本 就没这问题 (从P4起硬件限制是64G, 原因在于 GDT LDT的表项地址位是 36bit)回到原帖

这孩子, 撞到头了....
1. 位数跟大小没多少关系. x87早就有80-bit浮点数字了, 也有个20年了.
2. 32-bit无法利用64-bit的寄存器, 数目减半, 大小再减半. 你所谓的4-byte是不用白不用的东西, 反正不能拆开来给两个32-bit用. 到底哪个更浪费显然一目了然.
3. 32-bit下连访问4GB的文件都要做memory-mapping
4. WinServer也只能用2GB空间而已, 无论物理内存多大, 对于任意程序都是2GB(可选3GB)
5. 游戏代码大小根本无足轻重, 重要的是所有的文件都必须映射到内存里才能用, 32-bit下作大文件内存映射效率异常低下. 这才是速度慢的根源.
6. 多了的8个寄存器和现在处理器$的大小足以抵消pointer带来的损失并带来免费的性能提升, 少数领域比方AES里多出的寄存器至关重要.
7. 大内存用户用64bit Windows是理所当然的, 不仅仅是内核限制, 驱动在32bit强制破解后也会不稳定. 就是因为超过3GB的部分在驱动里映射很麻烦. 性能也比较低下. Server版只要有吞吐量就行了, 驱动就那屈指可数的几个. 好解决. 桌面就没那么简单了.
8. 如上, 用了x64版, 在加上WOW64模拟本就是缓兵之计, 你还真当神器了?

4.0b前几个版本的时候，minefied里面是有64bit windows版的，不过，最近好像又取消了

ftp://ftp.mozilla.org/pub/firefox/night ... taller.exe

这是什么?

为啥都喜欢用x64, 其实我个人觉得x86 比 x64要好点.
你想啊我们用的数字能超过2^31-1的地方不多, 32b 是4byte, 64b 是 8byte, 对于99.9%的运算, 64b 白白浪费了4个字节参与运算. 这部分的运算资源如果给32b 使用, 无疑损失0.1%而在 99.9% 得到补偿.

还有32b 地址一个段最大4gb, 个人pc有多少软件需要访问4gb的空间? 而且这只是一个段, 系统寄存器 CS 代码段不可能用到4G(代码4g是不可能的,10g的游戏有100M的代码就算了不起了). DS ES FS GS 可以保证同时访问 4*4GB 的空间而不需额外的操作. SS堆栈段要是能用到4G那绝对是无穷递归.

32位的3.25g限制实际上是microsoft的bug.
server版本 就没这问题 (从P4起硬件限制是64G, 原因在于 GDT LDT的表项地址位是 36bit)

SASCSI：

64的一直有........只不过不是正式版.不过还行,挺稳的,我3.5还是3.6那会就一直用的64版了回到原帖

4.0b前几个版本的时候，minefied里面是有64bit windows版的，不过，最近好像又取消了

SASCSI：试了几个youku视频,反应良好.

http://news.youku.com/rbxlcczzgyc

这个地址的小视频.打开后,似乎不能调整setting.......不能换setting的标签,比较怪异回到原帖

在IE9中切换不能，在FF4B7中能正常切换，就开头切第一个标签时稍微卡了一点，这个现象在32位的FLASH中也存在，我觉得是硬件加速的问题

什么？你还在用老掉牙的32位浏览器？

notnet：总算来了。不过，64bit的fx好像有没有下文了。回到原帖

64的一直有........只不过不是正式版.不过还行,挺稳的,我3.5还是3.6那会就一直用的64版了

试了一下，64bit的IE和Fx都能用flash了

X64的FF估计也会出Beta了。