@hljjhb 这就有一个问题了。

第二节 第十二条 改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有，但行使著作权时不得侵犯原作品的著作权。[1]

这条法律条文把「翻译」与「注释」列在一起。而我之前说的，发弹幕，恰恰就是根据影视作品发表的注释。那么也就是说，弹幕网站全都是侵权的了。

[1]: http://www.gov.cn/flfg/2010-02/26/content_1544458.htm

@gnup 大清早的不想聊太多这种事情，累。

还是那句话，64位和32位比，不是比个浏览器比个魔兽就能解决问题的。
每个应用的情况都不一样。

比如32位程序因为有内存寻址模型影响，所以有2G的上限。
就算打开LAA大内存寻址，最大寻址空间也不能超过3G，因为3G以外的区域是内核保留的。
对于仅仅只有2G大小的内存空间来说，像山口山这样的程序就必须严格限制自己的内存消耗。
明明读取了一张图片或者一个材质，却因为顾及内存大小而不得不在稍后就清理掉以释放内存。

而对于64位的程序来说，内存空间可以用起来更轻松。
稍后还会用到的图片或者资源，就先在内存里放一下，反正就算整体内存占用超过2G也不会出问题。
这样虽然内存占用更大了，但是运行起来更流畅，延迟是更小。

山口山这种即时游戏，当然是运行效能越高越好。
浏览器里大量的图片、图层、javascript代码、flash广告，当然也是效能越高越好。
为了效能，多使用一些内存，就和ramdisk一样。要是这样就指责说占用内存过多，实在是冤枉了。
因此说64位的软件可以运行得更快，不只是纸上谈兵，是有实际依据的。

另外64位下可用的寄存器也更多。32位程序做64位计算的时候，必须要用到SSE指令集才能快速计算，否则就只能用32位计算来模拟，效率非常差。64位指令集加入了RAX等扩展寄存器，直接在寄存器上就可以做64位运算，节约了拷贝到SSE寄存器的时间，或是用32位计算来模拟的时间。

而且64位程序在编译的时候可以更好地利用编译器特性进行优化。例如现在很多Linux发行版里的32位程序都是基于i386编译，因为32位从20多年前的386就出现了。而64bit则可以直接对应现代处理器，例如P4或者速龙之后的版本，因此可以直接假定处理器会带有SSE指令集，也因此所有的可以并行的操作，都会去用SSE指令集来优化。例如memcpy，32位下为了兼容性可能只能逐字节复制，最多用MMX来优化(但是会和浮点数运算冲突)，而64位下可以直接做MEM->XMMREG->MEM的批量复制，速度快得多。

对比以下代码
32位，i386兼容：
MOV EAX, [p]
MOV [q], EAX
一次复制4字节

64位，使用SSE：
MOVNTDQA XMM0, [p]
MOVNTDQA [q], XMM0
一次复制16字节

后者的性能至少是前者的2倍或者更多。

所以在同一个基准线上，64位的程序会运行得更快。

@msg7086 +节日美酒

@won 小蛋+节日香料+冰镇牛奶

@gnup 顿时开始同情起你的逻辑能力了。

先是自己说单字节变双字节，双字节变四字节，以此类推，我举个单字节的char又说不会变，打自己脸也不能这样打啊，看着都没意思。

引用你#35楼 「即使是64bit处理器，目前情况下也是在32bit应用下性能更强。」

能不能麻烦你自己发的东西自己看仔细点？

要是你真的觉得度娘能比我靠谱，那我们还是不要聊下去了，位面不同没法谈。
至于骂人弱智嘛，我也不是不能理解。总有人觉得别人都是弱智就自己智商特别高，特别优越。

@leiz
@hljjhb
翻译书和做字幕还是不一样。书籍里的文字是本体，翻译是把整部作品复制了；而做字幕是针对台词部分进行翻译，要欣赏作品光有字幕不行还必须有原始作品才行。

对于视频字幕来说，首先我们假定所有的资源来源都是合法途径。
那么首先如果我们要制作字幕，那么必定有一份合法的视频拷贝。这显然没有法律问题。
制作字幕属于私人使用，这在美国法律框架内是允许的，中国不清楚。
本质上这里的制作字幕的性质就和你同声传译给你年迈的父辈祖辈让他们理解视频内容是一样的。
然后上传字幕给别人。
#要说有侵权嫌疑，那也是在这一步。
但是你们要想，如果其他用户来下载字幕，他能够完整地欣赏这部作品吗？
如果你跑去电影院看电影，人家说我们有个放映厅，不放电影只放字幕，免费，你会坐下来看吗？
那势必你要有视频拷贝才行啊。
那根据我们的假设，你是购买了正版合法的视频拷贝后下载的字幕。
这样也就不造成侵权问题了，因为并没有影响到原始发行商的权力。

至于使用盗版视频配合字幕来观看的行为，显然是下载盗版视频侵权，而不是字幕侵权。

而且这做字幕就和发弹幕一样。
前者是对对白的翻译，后者是对视频内容的评论。
他们都是由少数人发送，不特定多数人接收，并在原始视频的基础上起到锦上添花的效果。
他们都是对原始作品的再创作再演绎。
如果做字幕侵权了，那显然发弹幕也就侵权了。

所以我觉得上面说的「制作字幕是侵权行为」，应当是「制作字幕版本的视频是侵权行为」才对。

Eggnog 冬幕节蛋奶酒，玩过一段时间山口山的人一定知道是什么东西。

@linkiosk 没怎么过我，因为自从自然人禁止注册cn域名的条例下来以后我就不用cn域名了。

@gnup

#18楼 QUOTE { 内存占用单字节变双字节，双字节变四字节，以此类推，内存占用必然增多。 }

#21楼 REPLY { 单字节变双字节是什么鬼？只有指针会从32位变成64位，数据又不会变。 }

#35楼 QUOTE { 简单来说、64位和32位、他们处理整数数据单元的大小 一个是64位（8字节） 一个是32位。64位系统占用的内存地址也是64位、因而比32位要耗内存。 }

我就引用上面的对话，你自己看你说的是什么，我说的是什么。
你觉得32位下占用1KB的char[1024]到了64位下会占用2KB么……

另外64位系统下32位程序性能比64位好我也是醉了。32位应用程序白白比64位程序少用了一堆寄存器，竟然还能运行得更快，有此黑科技请务必告诉我这是怎么做到的。

度娘百科还是不要引用的比较好，否则会引起很多笑话的。

@larkifly 如果你从来不写一些敏感的事情，比如美剧啊github啊sf.net啊之类的，当然是无所谓了。

@gnup 32位系统已经不用起码5年了，没条件测试，还是不和你争了，我们就当单字节会变成双字节好了，大家happy就行。

@gnup 首先吧，山口山本来就没有可比性。
山口山内部各种插件系统，lua虚拟机什么的各种，3D渲染什么的各种，而且内部的内存管理也是黑箱。
万一人家只是因为64位所以就多吃掉点内存来提升运行性能呢？
而且现在战网启动山口山默认就是64位了，你觉得暴雨是吃饱了撑的在同等条件下要多吃你点内存玩么。
常用软件不至于会产生那么大的内存占用差别。

@wy315700 这个long的大小是跟着系统/编译器走的。int一般是32位，long long一般是64位，而long可以任取32或者64。一般的程序不应该直接用long，否则会出现32位/64位运行结果不一致的问题。
就PHP这个内置long的问题已经造成32位和64位运行环境下整数溢出上限不一致了。

@gnup 单字节变双字节是什么鬼？只有指针会从32位变成64位，数据又不会变。
而且64位系统是寻址空间变大了，怎么会是扩大基本单元？你以为是4K硬盘搞基格式化啊……

cn域名必须死。

主要原因是oom killer 会在内存耗尽*之*前*就开始杀进程。比如你有1G内存，但是实际上在用到512M以后Linux就会开始随机杀进程了。

@Showfom 是有这个想法。要不菊苣出个建立apt库的教程？

@jiangzhizhou
@mind3x
感谢提供案例参考。以前升级百分之百的死亡率把我搞怕了

@icodesign 嗯？为什么这么说…linode本来就很快的啊

Linode连油土鳖可以跑上千兆…