Mozilla Hacks

TraceMonkey 的体验如何？

头像照片 作者：Christopher Blizzard

发布于 2009 年 6 月 11 日 分类于 35 天、Canvas、Firefox、JavaScript 和 TraceMonkey

我们 Firefox 3.5 的目标之一是帮助提升 Web。在这个版本的生命周期中，我们对开发者功能进行了大量投入。其中一项投入的功能就是 TraceMonkey——一种追踪解释器，它将常用的 JavaScript 代码转换为机器码，以便其能够以接近原生的速度运行。我们认为它既是最终用户功能，因为它使现有的 Web 应用程序运行得更快，也具有开发者功能，因为它能够实现新型的应用程序。

我们始终面临着挑战，即尝试提出一些方法来描述这意味着什么，而不仅仅是枯燥的基准测试。我们如何解释它的感受呢？

我们制作了一个视频来帮助描述它在数字上的含义，同时也展示了它的感受。如果您想尝试演示，我们建议您在 Firefox 3 和 Firefox 3.5 中都尝试一下。这确实是一种可以感受到的东西。

很遗憾，您的浏览器不支持原生视频。也许您可以尝试.ogv版本或.mp4版本，并期待最好的结果？

关于 Christopher Blizzard

一次一个版本，让 Web 变得更好。

更多 Christopher Blizzard 的文章…

61 条评论

  1. Mike Beltzner

    Vlad 更新了演示（清理了一些代码），供想要查看不同版本的人使用。在启用了 TraceMonkey 的浏览器上运行速度更快

    http://people.mozilla.com/~vladimir/mdemos/imgmanip/image.html

    2009 年 6 月 11 日 21:16

  2. Artur Pokusin

    哇。仅从演示来看，它看起来非常强大且方便。我希望它能够取得成功，并且 IE、Safari 和 Chrome 也能够开发出支持它的功能。

    2009 年 6 月 11 日 21:25

  3. Matt Wilkinson

    Blizzard，感谢您的演示！我喜欢告诉人们与 FF 3 相比，FF 3.5 的速度有多快。

    顺便说一下，我也密切关注您在博客上关于开放视频的宣传。像这里这样的开放视频，有什么简单的方法可以录制吗？

    -Matt

    2009 年 6 月 11 日 21:26

  4. Christopher Blizzard

    @Matt 该视频最初是在 Screenflow 中录制的，在 Screenflow 和 Final Cut Pro 的组合中进行了大量编辑，并导出为 Ogg Theora 和 mpeg4 格式。所以，使用的是相当标准的工具，只是导出方法略有不同。

    2009 年 6 月 11 日 21:38

  5. […] 原文地址：what does tracemonkey feel like? […]

    2009 年 6 月 11 日 22:07

  6. […] Safari 4，并对它在 Javascript 方面的速度感到震惊。请访问 https://hacks.mozilla.ac.cn/2009/06/tracemonkey-demo/，并在 Safari 4 中测试图像渲染演示，并将其与当前的 Firefox(3) 和视频演示进行比较 […]

    2009 年 6 月 11 日 22:40

  7. Drazick

    为什么 Chrome 在此测试中表现如此糟糕，但在任何其他日常任务中，它都轻松地胜过 Firefox 3.5 预览版？

    我认为 TraceMonkey 非常棒，但感觉它仍然落后于 V8 和 Nitro。

    谢谢。

    2009 年 6 月 11 日 23:40

  8. Wolfgang Rosenauer

    因此，从数字上看，我了解到 TraceMonkey 仍然没有完全支持 Linux 上的 x86-64 :-( 这非常令人难过。

    2009 年 6 月 12 日 00:19

  9. Erunno

    有趣的测试，我用 Safari 4 尝试了一下，令我非常惊讶的是，它的速度比 Firefox 3 慢。Safari 平均需要大约 900 毫秒才能绘制一帧，而 Firefox 3 大约需要 700 毫秒。我还没有机会用 3.5 尝试，因为我不喜欢使用 Beta 软件。

    对此数字有任何解释吗？在大多数综合测试中，Nitro 引擎实际上比 TraceMonkey 快得多。此测试实际上可能对营销非常有价值，因为它表明 TraceMonkey 在“现实世界”场景中更快。

    2009 年 6 月 12 日 00:24

  10. PA

    我在 3.0 和 3.5 之间感觉不到很大的区别。也许我遗漏了什么？Linux 版本是否相关？

    2009 年 6 月 12 日 00:49

  11. Sandy

    @Drazick：您不能用一个测试来衡量浏览器的性能。Firefox、Chrome、Safari 等在不同的方面都有各自的优势。习惯于这样一个事实，即“最快浏览器”这个问题并非非黑即白。

    2009 年 6 月 12 日 15:45

  12. Ka-Hing Cheung

    回复：Wolfgang Rosenauer

    看起来 trunk 有 AMD64 支持（从代码中查看）

    2009 年 6 月 12 日 17:32

  13. will_in_wi

    在使用最新的 3.5 nightly 版本的 x86_64 ubuntu linux 上调整对比度时，我的绘制时间为 1763 毫秒。这些 nightly 版本由 ubuntu-mozilla-daily ppa 团队编译和分发，因此它们是真正的 64 位版本。JIT 编译器不支持 64 位吗？或者 Linux？或者编译标志错误？

    2009 年 6 月 12 日 17:51

  14. Christopher Blizzard

    我们在 3.5 中没有 Linux 的 64 位支持。不过，听起来它会在某个时候到来。

    2009 年 6 月 12 日 18:43

  15. Mecki

    Nitro 的速度不仅体现在综合测试中。例如，我经常使用 stackoverflow.com。当您在此页面上键入问题或答案（使用类似 Wiki 的语法）时，JS 代码会将其实时转换为预览。在我的慢速系统上，使用 Fx 3.0.x 处理非常长的答案/问题变得非常麻烦。在启用了 TraceMonkey 的 3.5beta99 上执行相同的操作肯定快得多，但仍然有点迟缓。在 Safari 4 上执行相同的操作速度极快。这是一个真实的现场场景，没有任何综合测试，Nitro 在其中明显击败了 TraceMonkey，我无需对此进行基准测试，我可以看到它，并且可以感受到它。

    2009 年 6 月 13 日 17:35

  16. Erunno

    @Mecki

    确实，http://www.chromeexperiments.com/上也有一些要求苛刻的 JavaScript 演示，它们在 Nitro 和 V8 上运行流畅，但在 TraceMonkey 上却无法流畅运行。

    2009 年 6 月 14 日 01:05

  17. Mecki

    我认为 TraceMonkey 是一个必要的步骤，当然也是朝着正确方向迈出的一步——但是仍然存在很大的潜力。其他浏览器供应商表明，JS 的运行速度甚至可以比 TraceMonkey 目前运行的速度快得多。对于网页来说，TraceMonkey 在大多数情况下可能已经足够快了，但是除非我错了，否则 Mozilla 的目标是用 JS 替换 Firefox 中越来越多的原生代码（因为它是跨平台的，并且使移植变得更容易）。将来，只有某些渲染、网络和文件访问功能才是原生的，但几乎所有其他浏览器逻辑都不会是原生的。这是 Firefox 未来发展的一个好主意，但 TraceMonkey 目前仍然太慢，无法实现这一目标。

    2009 年 6 月 14 日 05:07

  18. Ryan Hayle

    在当今时代，您怎么能认真发布任何不支持 x86_64 的产品？这种架构已经存在了 10 年，除了上网本之外，他们已经好几年没有销售 32 位 CPU 了。绝大多数用户应该使用 64 位操作系统。不断忽略现代（甚至不是最先进的！）平台，而青睐过时的、10 多年前的平台，这真是令人沮丧。我希望这种情况能够改变，并且 Mozilla 开始认真对待 x86_64（包括发布 x86_64 二进制文件）。我理解这只是一个 Beta 版本，“您正在努力解决”，我并不是仅仅不耐烦。我的观点是，x86_64 应该成为您的首要任务，32 位应该放在次要位置，尤其是在 32 位用户数量每天都在减少的情况下。

    2009 年 6 月 17 日 09:43

  19. Christopher Blizzard

    @Ryan – 我理解您很生气。但是，发行版确实构建了 x86_64 二进制文件并进行了分发。我们只是还没有在 TraceMonkey 中支持它。

    此外，世界也不会在一夜之间发生改变。

    2009 年 6 月 17 日 11:00

  20. Matt Wilkinson

    @Ryan 为了扩展 Blizzard 的评论：重要的是要理解，Firefox 最大的平台（不幸的是）是 Windows。Windows 和 OS X 是大多数最终用户在其计算机上使用的操作系统，并且 Firefox 以及 TraceMonkey 在这些平台上都可以正常工作。Mozilla 正在为 OS X 开发 64 位版本的 Firefox.next，但 Firefox 无需为 64 位才能在 64 位操作系统上运行。

    例如，我使用的是 64 位 Windows 7 和 OS X Leopard，Firefox 以及 TraceMonkey 都可以正常工作。

    我可以告诉你，你是 64 位 Linux 的忠实粉丝，但这是一个很少有人使用的利基市场。您谈论的是一个功能强大的操作系统（Linux），但并不是很多最终用户都在使用它，更不用说 64 位 Linux 了。所以，您必须理解 Mozilla 在此处的优先事项。将所有资源都投入到 x86_64 Linux 上毫无意义。毫无意义。他们现在有更重要的事情要做，并且在我看来，他们做得非常出色。

    此外，64 位直到去年才在 Windows 上成为主流。Snow Leopard 将主要为 64 位，但它仍然会有一些正在以 32 位运行的操作系统元素。因此，整个世界都在运行 64 位的说法是错误的。

    -Matt

    2009 年 6 月 17 日 11:50

  21. Ka-Hing Cheung

    @Matt – 32 位 Firefox 上的 TraceMonkey 在 64 位 Linux 上也能正常工作，但这并不是 Ryan 抱怨的重点。问题在于，64 位 Firefox 上的 TraceMonkey 还没有工作（无论如何，在 3.5 中还没有），这在任何平台上都是一样的。

    不过，我认为它不像 Ryan 说的那样严重。

    2009 年 6 月 17 日 15:03

  22. Matt Wilkinson

    @Ka-Hing Cheung 对。无论如何，它不像 Ryan 说的那样严重。再说一次，仅仅因为 64 位 Firefox 和/或 64 位 Linux 的用户群非常小，所以它不能成为优先事项。

    反正我认为是这样的。

    2009 年 6 月 17 日 15:10

  23. Dannii

    也许用户群如此之小是因为它被忽视了？

    2009 年 6 月 19 日 20:37

  24. Ryan Hayle

    我意识到在上一篇文章中听起来有点过于激进，但我仍然认为这些观点是合理的。我知道世界不会在一夜之间发生改变，但已经过去了 10 年，众所周知，在“计算机年”中，这是一个永恒。

    我担心的是，人们会兴高采烈地下载并运行闪亮的新 Firefox 3.5——它主要宣称速度和性能有了大幅提升——在其华丽的新机器上，并感到非常失望。在我的 2.4GHz Core2 Duo T8300 上，Peacekeeper 基准测试的结果大约只有 1200，我假设这主要是由于没有 TraceMonkey 支持。Chromium nightly 的结果超过了 2900。

    困扰我的不是我自己使用的是速度较慢的浏览器，而是感觉开发者正在关注一个非常过时的平台。我意识到您想专注于 Windows/Mac——这是一个完全不同的论点，我并不是建议任何人将所有资源都投入到 Linux 上。但是，在 Linux 本身的开发工作中，我希望当前的重点是 64 位。有多少人实际上在 64 位 CPU 上使用 32 位 Linux？我很有可能对此一无所知，我只是无法理解为什么有人会这样做。我对专有操作系统双胞胎一无所知，也不知道为什么它们如此落后，并且现在才获得 64 位支持，但这与重点无关。

    我不想运行 32 位 Firefox，因为它必须存在于我的发行版之外，并且需要安装完全独立的 32 位插件。

    我并不是试图进行批评，整个开发社区都做了惊人的工作，我并没有贬低他们的任何工作。但是，我确实质疑是否对这个问题给予了足够的重视。我一点也不不耐烦，我知道开发高质量的软件需要时间。我只是不认为 Mozilla 发布一个在某些平台上仅部分运行的产品是正确的，仅仅因为它们被认为是“利基市场”。这使它与 Google、Skype 和其他不同时发布 Windows 和 Linux 软件版本的专有软件供应商处于同一阵营。作为开源软件的典范，我真的很讨厌看到这种情况发生！

    我确实对没有亲自努力让 TraceMonkey 在 64 位平台上运行，却还在抱怨这件事负全部责任。我正在尝试做出更有建设性的贡献，而不仅仅是抱怨！

    2009 年 6 月 29 日 12:33

  25. Dirk

    针对标题中的问题：“Tracemonkey 用起来感觉如何？”

    嗯，感觉就像……呃……什么都没有，因为它与当前系统不兼容，只兼容过时的 32 位机器。

    失败。

    2009 年 6 月 30 日 14:53

  26. greg

    所以……既然 TraceMonkey 在 Firefox 主干版本 64 位系统上运行良好，它会被合并回 Firefox 3.5 吗？我真心希望如此。

    2009 年 7 月 1 日 06:06

  27. Raymond Right

    像大多数其他开发者一样，Mozilla 的开发人员认识到，Windows 和 OS X 等闭源技术和平台才是真正的发展方向。开源对于像 Web 浏览器和 Web 服务器这样无用的东西来说还不错，但只有闭源操作系统才能带给你那种清新爽快的感觉。

    2009 年 7 月 1 日 13:17

  28. Gfterry

    Mozilla 的 Firefox 从 IE 那里抢走了很多市场份额，因为微软没有听取用户要求 IE 保持技术进步的请求。

    现在 Mozilla 正在步微软的后尘。

    当你可以花 40 美元购买 4GB 内存的时候，你认为 32 位还能在桌面领域称王多久？

    对希望忠于 Mozilla 和 Firefox 的 64 位用户采取完全轻蔑的态度是一种耻辱。如果我必须修改一个 32 位浏览器才能在 64 位系统上运行，我将使用 Google 的 Chrome，Mozilla 给了 Chrome 充足的时间来赶上 Firefox。

    2009 年 7 月 1 日 15:44

  29. Mecki

    @Ryan Hayle：我不明白你的意思。抱歉。根据 Ka-Hing Cheung 的说法，32 位 Firefox 在 64 位 Linux 上运行良好。那么你的问题到底是什么呢？你说“哇哇哇，64 位 Linux，哇哇哇 64 位 CPU”，是的，一切都很好。拥有 64 位 CPU，运行 64 位 Linux，然后给我一个充分的理由说明为什么你不能在上面使用 32 位 Firefox。引用你的帖子

    “我不想运行 32 位 Firefox，因为它必须存在于我的发行版之外，并且需要安装完全独立的 32 位插件。”

    我认为，这只是你个人偏好的问题。我，作为一个 Mac 用户，习惯了始终混合使用 32 位和 64 位。在 10.4 中，只有后台进程（如服务器进程、数据库进程等）可以是 64 位的，UI 进程不是，内核本身也仅限于 32 位。在 10.5 中，后台和 UI 进程可以是 64 位的，只有内核本身受限于 32 位。即将推出的 10.6 中，所有进程（包括内核）都可以是 64 位的。那是“可以是”，而不是“将是”或“必须是”。我每天都在并行运行 32 位和 64 位进程，有时在 64 位内核上，有时在 32 位内核上。

    如果 TraceMonkey 对你来说如此重要，请使用 32 位 Firefox 并享受快速的 JS 支持。如果 64 位对你来说如此至关重要，那么请使用 64 位 Firefox 并停止抱怨。因为与你的帖子暗示的不同，64 位 Linux 用户可以在他们的 64 位 CPU 上享受完整的 TraceMonkey 速度。他们只需使用 32 位 Firefox；这对成千上万的用户来说不是问题。整个事情更像是一个问题，即 Mozilla 开发不兼容你强加于自己的限制。

    我现在在运行 64 位 CPU 上的 64 位 OS-X 内核上使用 32 位 Firefox，它有 TraceMokey 并且运行得非常棒！

    2009 年 7 月 1 日 16:39

  30. Matt Wilkinson

    @Mecki 完全正确。

    2009 年 7 月 1 日 16:42

  31. Gfterry

    Mozilla 的 Firefox 从 IE 那里抢走了很多市场份额，因为微软没有听取用户要求 IE 保持技术进步的请求。

    现在 Mozilla 正在步微软的后尘。

    当你可以花 40 美元购买 4GB 内存的时候，你认为 32 位还能在桌面领域称王多久？

    32 位偏执狂们，这句话听起来是不是很熟悉：“没有人会需要超过 640k 的内存！”

    对希望忠于 Mozilla 和 Firefox 的 64 位用户采取完全轻蔑的态度是一种耻辱。如果我必须修改一个 32 位浏览器才能在 64 位系统上运行，我将使用 Google 的 Chrome，Mozilla 给了 Chrome 充足的时间来赶上 Firefox。

    2009 年 7 月 1 日 17:11

  32. 某人

    @Mecki 和 @Matt Wilkinson

    Firefox 开发人员是专业的，并且开发了一个非常流行且广泛使用的软件包。他们不应该发布 32 位版本并跳过 64 位版本的发布。它们应该是同时发布的。如果他们无法处理这个问题，那么我质疑他们未来的主导地位。

    这不是他们在过去几个月里第一次放手不管的事情！

    Firefox，振作起来，否则我们将把我们的支持转向更快的、能够消除臃肿的东西！

    S。

    2009 年 7 月 1 日 19:41

  33. David

    我认为 Ryan 仍然有道理。如果新浏览器的主要功能在 64 位版本中不可用，那么这是一个相当大的疏忽。64 位的主要优势是速度，但恰恰是在这个 64 位版本中被削弱了。我只是希望这个修复程序包含在下一个错误修复版本中，我们不必等到 FF4 才能看到 64 位 FF 正常运行。（你在哪里找到 64 位版本？我在 Mozilla 的网站上找不到任何关于它的参考）

    除此之外，我真正希望的是 Firefox 在 Linux 上的性能有所提高，至少与 FF3 在 Windows 上的性能一样快。我想我只能亲自尝试一下才能知道……

    2009 年 7 月 1 日 21:54

  34. Silf

    @Mecki 因为与你的帖子暗示的不同，64 位 Linux 用户可以在他们的 64 位 CPU 上享受完整的 TraceMonkey 速度。他们只需使用 32 位 Firefox；这对成千上万的用户来说不是问题。

    我不得不不同意你的观点。如果你有 64 位 Linux（很多人都有，因为它更快，并且所有东西都已经移植到 64 位了），那么你已经拥有所有 64 位插件了。因此，如果你想降级到 32 位，则必须替换所有插件，例如 totem、flash 等，这些插件在默认的 64 位安装中可用。nspluginwrapper 可以在 64 位浏览器中运行 32 位插件，但反过来不行。对于普通用户来说，这不是一个简单的更改（http://ubuntuforums.org/showthread.php?p=1174435）。我认为应该有人补充说明，此手册对于 FF 3.5 来说不再过时了 :)

    即使在 Mac 上，你也会遇到问题。自 Java 6 发布以来，三年过去了，Apple 仍然没有 32 位版本，只有 64 位版本（我们在 Firefox 内部需要 Java 6（由于添加了 NSS 支持）。

    我同意你的观点，这不是什么大问题，但我相信你可以理解为什么 Linux 用户会期待 64 位支持 :)

    我真的很希望 Linux 发行版使用主干版本中的 64 位 TraceMonkey 支持。

    @Mecki 整个事情更像是一个问题，即 Mozilla 开发不兼容你强加于自己的限制。
    你确定是我们限制了自己吗？我敢打赌 64 位 TraceMonkey 会让 32 位 TraceMonkey 难堪 ;) 如果你已经在使用 64 位 Mac，难道你不会更喜欢更快的 64 位 Firefox 吗？

    2009 年 7 月 2 日 01:32

  35. Silf

    @Mecki 因为与你的帖子暗示的不同，64 位 Linux 用户可以在他们的 64 位 CPU 上享受完整的 TraceMonkey 速度。他们只需使用 32 位 Firefox；这对成千上万的用户来说不是问题。

    我不得不不同意你的观点。如果你有 64 位 Linux（很多人都有，因为它更快，并且所有东西都已经移植到 64 位了），那么你已经拥有所有 64 位插件了。因此，如果你想降级到 32 位，则必须替换所有插件，例如 totem、flash 等，这些插件在默认的 64 位安装中可用。nspluginwrapper 可以在 64 位浏览器中运行 32 位插件，但反过来不行。对于普通用户来说，这不是一个简单的更改（http://ubuntuforums.org/showthread.php?p=1174435）。我认为应该有人补充说明，此手册对于 FF 3.5 来说不再过时了 :)

    即使在 Mac 上，你也会遇到问题。自 Java 6 发布以来，三年过去了，Apple 仍然没有 32 位版本，只有 64 位版本（我们在 Firefox 内部需要 Java 6，因为添加了 NSS 支持）。

    我同意你的观点，这不是什么大问题，但我相信你可以理解为什么 Linux 用户会期待 64 位支持 :)

    我真的很希望 Linux 发行版使用主干版本中的 64 位 TraceMonkey 支持。

    @Mecki 整个事情更像是一个问题，即 Mozilla 开发不兼容你强加于自己的限制。
    你确定是我们限制了自己吗？我敢打赌 64 位 TraceMonkey 会让 32 位 TraceMonkey 难堪 ;) 如果你已经在使用 64 位 Mac，难道你不会更喜欢更快的 64 位 Firefox 吗？

    我的上一篇帖子似乎丢失了。

    2009 年 7 月 2 日 01:49

  36. Robert

    “32 位 Firefox 在 64 位 Linux 上运行良好。”抱歉，但那不是真的。如果你不想使用 32 位版本的插件，你就被卡住了
    LoadPlugin：无法初始化共享库 /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so [/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so：错误的 ELF 类：ELFCLASS64]
    LoadPlugin：无法初始化共享库 /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so [/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/IcedTeaPlugin.so：错误的 ELF 类：ELFCLASS64]
    LoadPlugin：无法初始化共享库 /usr/lib/mozilla/plugins/libflashplayer.so [/usr/lib/mozilla/plugins/libflashplayer.so：错误的 ELF 类：ELFCLASS64]
    LoadPlugin：无法初始化共享库 /usr/lib/mozilla/plugins/kaffeineplugin.so [/usr/lib/mozilla/plugins/kaffeineplugin.so：错误的 ELF 类：ELFCLASS64]
    （以及其他）

    自从 Sun/OpenJDK 发布了 Java 插件的 64 位版本后，我已经放弃了所有包括 chroot 在内的做法。那是让我坚持使用 32 位的最后一件事情。我并不急于使用 Firefox 3.5 版本，所以我可以等待。

    2009 年 7 月 2 日 10:27

  37. Mecki

    @Silf 和 @Robert：所以你们有 64 位插件，这阻止了你们拥有 32 位插件？抱歉，但我读得越多，我就越觉得问题在于 Linux 在这方面是一个设计糟糕的操作系统。抱歉，我不想把这件事变成操作系统之间的争论……然而，世界上几乎每个 Mac OS X 用户每天都在使用 32 位和/或 64 位应用程序，甚至不知道哪个应用程序是 32 位的，哪个是 64 位的，因为它们在 OS X 中完美地集成在一起！为什么 Apple 可以创建一个基于 BSD 的系统，让 32 位和 64 位并行存在且对用户完全透明，而在 Linux 上，你必须进行各种修改才能获得相同的结果？为什么 Apple 可以将每个系统库、每个插件、系统的每个部分都作为 32 位和 64 位版本提供，而 Linux 却做不到？实际上，我认为 Linux 不是做不到，我认为 Linux 可以做到，只是你的发行版导致了这些问题。正如 Ryan 所说，他不想离开他发行版的路。为什么你的 Linux 发行版不能提供 32 位 Firefox *和* 64 位 Firefox，以及所有插件的 32 位和 64 位版本，这样你就可以在 64 位系统上自由选择使用哪个版本，并且任何一个版本都可以与所有插件一起工作，而你甚至不必浪费一秒钟的时间去思考这个进程是 32 位的还是 64 位的？

    @David：主要优势是速度？得了吧。我以为这里的用户在技术上足够先进，不会被这种营销术语所迷惑。64 位在哪里更快？只有当你进行大量的 64 位整数运算时，64 位才会更快，几乎没有应用程序会这样做（我估计 Fx 中 90% 的整数运算，即使在 64 位 Fx 中也是 32 位的），以及如果你使用某些非常模糊的算法，这些算法可以真正利用几个额外的 CPU 寄存器。大多数算法没有用处这一点，从 x86 代码（只有大约 6 个可用寄存器）在某个时候超过了 PPC 架构（16 个寄存器）的速度这一事实就可以清楚地看出，它们具有相同数量的核心和相同的 GHz 时钟频率。谁真的认为任何一段 C/C++ 代码仅仅因为你用 64 位 GCC 编译它就会运行得更快，很可能从未开发过比 Hello World 更大的 C 代码。实际上，在 64 位中，所有内存指针的大小都是 32 位的两倍，导致 CPU 的一级代码和数据缓存更快地填满，导致更多的缓存未命中和更多缓慢的内存访问，而不是相同代码编译为 32 位时的速度。使用 64 位的两个唯一有效理由是，要么是一个应用程序进行超过 50% 的 64 位整数运算，要么是需要超过 4GB 的虚拟地址空间（例如，SQL 数据库或 Apache 服务器属于此类）。这两者都不适用于一般的 Web 浏览器，也不适用于 Fx。

    2009 年 7 月 2 日 15:16

  38. Silf

    @Mecki 所以你们有 64 位插件，这阻止了你们拥有 32 位插件？抱歉，但我读得越多，我就越觉得问题在于 Linux 在这方面是一个设计糟糕的操作系统。
    你可以拥有它们，但如果你查看了我的链接，你会发现这并不简单。通用二进制文件在这方面很棒。Linux 大部分只需要一个版本的二进制文件，因为基本上所有东西都已经移植到 64 位了（是的，甚至包括 flash 和 java）。Apple 只是在这方面迈出了一半。两个月后，Snow Leopard 将会有越来越多的东西移植到 64 位（比如 Safari）。

    @Mecki 为什么 Apple 可以将每个系统库、每个插件、系统的每个部分都作为 32 位和 64 位版本提供，而 Linux 却做不到？
    所以你的意思是 Apple 可以将所有内容移植到 64 位端口，而 Mozilla 做不到？但即使 Apple 也做不到 ;) Java 6 仍然只提供 64 位版本。你能告诉我如何在 MacOSX 上使用 Java 6 运行 Firefox 或 Safari 吗？（不是在开玩笑，我真的很想知道）。

    @David：主要优势是速度？得了吧。我以为这里的用户在技术上足够先进，不会被这种营销术语所迷惑。
    据 Apple 称，Snow Leopard 中的 Safari 4 将是 64 位的，并且速度提高了约 50%。他们这么说。


    正如你所说，确实有一些算法可以从 64 位中获益。并且由于 JavaScript 本身是一种编程语言，浏览器本身也相当复杂，其中包含的算法也可以从中获益。
    例如，在 64 位下处理图像的速度更快。而且由于浏览器经常处理图像，因此在这里至少可以看出一个好处。
    http://www.favbrowser.com/firefox-32-bit-x86-vs-firefox-64-bit-x64/

    2009 年 7 月 2 日 18:07

  39. [...] 拒绝发布适用于 64 位系统的 Firefox 3.5。目前我所知唯一 [...]

    2009 年 7 月 3 日 12:36

  40. [...] @gabe 在 https://hacks.mozilla.ac.cn/2009/06/tracemonkey-demo/ 的评论中 [...]

    2009 年 7 月 4 日 23:05

  41. Cliff Wells

    这里的问题不仅仅是 32 位 Linux 与 64 位 Linux 之间的区别。它关乎对帮助 Mozilla 发展到今天这个地步的平台的一点忠诚（有多少 Linux 用户花费数小时说服他们的 Windows 和 OSX 用户朋友切换到 Firefox？）。Firefox 是 Linux 上的主要浏览器，也是 Windows 和 OSX 上的次要浏览器。有一种明显的感受，那就是或许 Linux 用户的忠诚度被视为理所当然，我认为抱怨的根源就在这里。与其说是功能 X 的问题，不如说是存在一种明确的认知（并且在这里似乎得到了证实），即与商业平台相比，Linux 从 FF 团队那里得到的关注要少得多。

    我个人在 64 位 Linux 发行版上安装 32 位软件没有任何问题。不幸的是，如果我切换到 32 位 FF，我还必须切换回糟糕的 32 位 Flash 播放器，并忍受 FF 不断崩溃的困扰。这不是一个明智的选择。

    我预计当 Chrome for Linux 正式发布时，Firefox 的 Linux 用户群的忠诚度将面临真正的考验。我也预计，Linux 用户之前为 FF 做的大量宣传将转向 Chrome。因此，我预测失去 Linux 用户最终将意味着失去 Windows 和 Mac 用户。

    Linux 用户如果不是狂热者，那还能是什么呢 ;-)

    2009 年 7 月 6 日 19:59

  42. Mecki

    @Cliff：Firefox 是 Linux 的主要浏览器？谁说的？我认为几乎每个 KDE 用户都不认同，毕竟 KDE 自带一个浏览器（Konqueror），而且它一点也不差（底层库与 Apple 用于 Safari 的库相同。KHTML 是 WebKit 的基础）。而且 32 位 Flash 插件似乎很糟糕，这很难说是 Mozilla 或 Linux 的错；问题更像是为什么 Adobe 可以编写一个像样的 64 位插件，但在他们的 32 位版本上却表现得如此糟糕。此外，Fx 现在已经存在多久了？大约 5 年？因此，你可以在 5 年里愉快地使用这个浏览器而没有 Tracemonkey，现在，仅仅因为你不得不额外等待几个月才能在 64 位 Linux 上获得 Tracemonkey，你的整个世界就崩溃了？你不会当真吧。

    我本人也是一名开发者，作为开发者，我总是先实现 32 位版本，然后将其移植到 64 位。绝不会反过来。20 年来都是如此。除非当然只有 64 位版本。为什么？很简单。将 32 位代码移植到 64 位代码比将 64 位代码移植到 32 位代码要容易得多。这是非常合乎逻辑的。从受限到不受限的移植总是比从不受限到受限的移植更容易。

    那么你们真正想要的是什么？是的，64 位 Linux 上的 TraceMonkey。这不是我的问题 :-P 我的意思是，你们真正希望 Mozilla 在开发中做什么。以下是你的选择

    1) Mozilla 只有在拥有 32 位和 64 位版本的情况下才会发布 TraceMonkey。-> 结果：要么 3.5 完全没有默认启用 Tracemonkey（并且它将在几个月/几年后的 3.6 或 4.0 中发布），要么 3.5 的发布将被延迟几个月，导致所有用户的 Fx 拥有缓慢的 JS，并可能导致 Fx 显著失去客户群，成为浏览器大战中的大输家。这是你想要的吗？

    2) Mozilla 先制作 64 位版本，发布并稍后添加 32 位版本。换句话说，超过 90%（可能超过 95%）的用户将没有 TraceMonkey 支持（大多数 Windows 用户仍然是 XP 而不是 XP64，Vista 在我居住的地方仍然比较罕见，Vista64 几乎是异乎寻常的；Mac 版本无论如何都只有 32 位，而 Linux 32 位基础仍然比 64 位基础多得多）。-> 结果：参见上文。由于大多数用户拥有缓慢的 JS 并必须等待 TraceMonkey，因此对于所有这些用户来说，这与 TraceMonkey 完全不属于发布版本相同。因此，Mozilla 必须担心失去浏览器大战，失去客户群，也可能在没有为任何人提供 TM 支持的情况下发布 3.5。再说一遍，这是你想要的吗？

    通过尽快发布 TM，从而尽快发布 3.5，Mozilla 使许多用户感到高兴（所有 32 位用户，而且数量远远超过 50%！远远超过……），Mozilla 再次在浏览器大战的上层阶级中争夺地位（在发布之前，世界都在嘲笑 Fx 缓慢的 JS 支持）。这比上述两种策略要好得多，这就是 Mozilla 采取这种策略的原因。

    而你们所有 64 位 Linux 用户只需要再等待几个月就能获得这个你所喜爱的浏览器的功能。如果我看到你们在这里对 Mozilla 的激烈争论，我诚恳地认为你们应该选择一个不同的浏览器，最好是一个只有 64 位的浏览器，并且终生快乐。因为试图强迫 Mozilla 走上一条对他们和 Fx 市场份额具有绝对破坏性的道路，仅仅是为了 *你* 自己能够感到高兴，这实在是太自私了，我认为 Mozilla 社区和 Fx 用户群可以在没有你的情况下繁荣发展。

    2009 年 7 月 7 日 02:08

  43. David

    @Mecki
    我认为你错过了重点。问题是 FF3.5 64 位版在发布时没有包含 Tracemonkey。如果我错了，那么请告诉我，以及所有其他对 64 位 FF 没有 Tracemonkey 感到烦恼的人。如果我错了，那就太好了，如果不是，那就别再捣乱了。

    至于 Konqueror 与 Firefox 的市场份额，请务必向我展示一些支持你论点的统计数据。根据 Net Application 的统计数据，Konqueror 甚至没有出现。这使得 Konqueror 在 Linux 上的市场份额小于或等于 1%（除非我的数学计算有误，这很可能是真的）。因此，要么 KDE 用户不多，要么大多数 KDE 用户没有使用 Konqueror。后者更有可能。

    2009 年 7 月 7 日 05:00

  44. Mecki

    @David：不，你错过了我的重点。我完全理解 64 位 Fx 中没有 TM。我的问题是，Mozilla 应该采取什么替代措施。因为 64 位 TM 未准备好而完全不发布 TM？因为 64 位 TM 未准备好而完全不发布 3.5？为什么你无法回答这个问题？你现在是 Mozilla 的老板。32 位 TM 已准备就绪，64 位 TM 未准备就绪，全世界都在急切地等待 TM，并嘲笑 Fx 缓慢的 JS 引擎。所以，作为 Mozilla 的老板，你会做出什么决定？这是一个简单的问题，不仅是我，我想关注此主题的几乎每个人都渴望听到你的回答。

    2009 年 7 月 7 日 08:21

  45. David

    @Mecki：呃，如何等到 64 位 Tracemonkey 准备就绪后再发布 64 位 FF3.5？在我看来，这是一个简单的解决方案。

    2009 年 7 月 7 日 15:48

  46. Mecki

    @David：好的。那么所有 Fx 64 用户都会来这里抱怨他们没有 Fx 3.5，我们也会遇到现在同样的情况。除了他们不仅抱怨没有 TM，还抱怨没有其他所有功能（新的 CSS 功能，HTML5 支持，视频和音频标签，这篇博文讨论的几乎所有内容对他们来说都不存在）。因此，我认为这个决定会导致比现在更多抗议和更多不满的用户。现在的情况是，他们 *确实* 拥有所有这些功能，只是没有 TM，但因此拥有其他所有功能。

    2009 年 7 月 8 日 02:40

    1. Cliff Wells

      哇，就像你不会阅读一样。

      无论如何，在这条帖子发布的两年里，Firefox 失去了 4% 的市场份额，而 Chrome 则获得了 14% 的市场份额。现在 *你* 是 Mozilla 的老板。你能解释一下你做错了什么吗？

      2011 年 3 月 22 日 15:44

  47. [...] 一篇名为“Tracemonkey 的感受如何？”的精彩帖子，由 Mozilla 的布道总监撰写。在他的帖子中，他指向了一个在线小型基准测试 [...]

    2009 年 7 月 11 日 09:14

  48. […] 原文地址：what does tracemonkey feel like? […]

    2009 年 7 月 12 日 22:26

  49. adriano

    关于 64 位的 Tracemonkey 有任何开发新闻吗？

    2009 年 7 月 15 日 02:06

  50. Christopher Blizzard

    64 位支持即将到来。几天前我们在开发会议上讨论过这个问题。

    2009 年 7 月 15 日 06:42

  51. morgan

    您好。64 位 Tracemonkey 可能会出现在某个点版本更新中，还是我们必须等到 Firefox 4？

    我确实注意到在 AMD64 版本中某些页面速度较慢 - 例如 Google 邮件/Slashdot 等。

    由于 Linux 现在有了 AMD64 Flash 插件（即使是 alpha 版本，它的工作效果也比 32 位版本好得多）以及 AMD64 版本的 Sun Java 插件，我认识的更多人安装了 AMD64 版本的 Linux。

    Firefox 3.5 的其他方面做得很好，期待看到未来版本带来的改进。

    2009 年 7 月 28 日 12:18

  52. default

    64 位支持会移植到 3.5.x 分支中吗？

    2009 年 7 月 30 日 06:40

  53. Paolo

    我刚刚注意到这个帖子，现在我意识到为什么我的 FF 3.5 看起来没有比 3.0 版本快。猜猜看，我使用的是 64 位 Linux，并且不想安装并行的 32 位库和插件发行版。Mozilla 在这个问题上让我失去了一些好感。

    顺便说一句，不是为了捣乱，而是为了获取信息，从头开始设计 Tracemonkey 以便可以将其编译为 32 位和 64 位应用程序的技术障碍是什么？

    2009 年 8 月 3 日 03:24

  54. foobar

    我也有同样的“缺乏加速”体验……
    当然是在 64 位 Linux 上。

    所以这里又一个呼吁 64 位 TraceMonkey 的声音 :)

    2009 年 8 月 4 日 09:16

  55. Ben

    @ Mecki
    你的论点是有效的，但我认为 David 想要表达的是，当 64 位 TraceMonkey 准备就绪时，他们会发布 64 位版本的 Firefox 3.5，而不是在 Firefox.next 发布时，而这正是目前的情况。这两种情况非常不同，因为我们完全不知道 Firefox.next 何时发布，或者它将是 3.6 还是 4.0。

    此外，你建议的开发者思维方式正是导致 64 位停滞不前并成为“利基”的原因。这是一个恶性循环，开发人员不制作 64 位程序，因为 64 位操作系统的市场渗透率不够高，然后看到没有很多 64 位程序的最终用户犹豫是否要安装 64 位操作系统。这是一种本质上错误的思维方式。Mozilla 至少应该挺身而出，为当前的 Firefox 版本提供追溯性的 64 位构建，以帮助我们摆脱这个循环。

    而且你不应该抨击那些抱怨的人。此外，你对抱怨数量感到如此恼火的事实也表明，64 位并非像你所说的那样是利基市场。

    2009 年 8 月 5 日 16:21

  56. Yuhong Bao

    “在 10.4 中，只有后台进程（如服务器进程、数据库进程等）可以是 64 位的”
    更准确地说，在 10.4 中，只有命令行进程可以是 64 位的。

    2009 年 8 月 17 日 17:14

  57. anonymous

    我在谷歌上搜索，想知道为什么我的 Firefox 3.5 的运行速度与 3.0 相同，尝试在 about:config 中启用 everything-jit，使用 nightly 构建，Ubuntu PPA 等，最终找到了这篇帖子。是的，这是 64 位 Linux。Firefox 3.5 似乎是我电脑上唯一不支持 64 位 CPU 的软件，即使是该死的 Flash 插件现在也有 64 位版本。感觉就像回到了 90 年代。

    验证码显示“哈哈”，但我认为实际上很悲伤。

    2009 年 8 月 31 日 09:51

  58. WindPower

    +1 支持 64 位上的 Tracemonkey。求求你们了？

    2009 年 8 月 31 日 21:08

  59. default

    Mozilla 主干中现在启用了 x86_64 的 Tracemonkey。我想知道我们是否会在 3.6 中看到它，那将非常酷。

    2009 年 10 月 8 日 01:44

  60. Paolo

    太棒了！我期待着在我的浏览器中使用它。
    谢谢你们！

    2009 年 10 月 8 日 04:49

本文的评论已关闭。