t********l
发帖数: 106 | 1 【 以下文字转载自 Programming 讨论区 】
发信人: tianyagirl (呢喃), 信区: Programming
标 题: Hadoop居然是用Java写的，不理解
发信站: BBS 未名空间站 (Tue Jul 8 16:11:10 2008)
有人说，当今的趋势Java主要是应用性开发，C++主要是系统级开发。Java虽然稳定跨
平台，但是速度慢。为什么hadoop这样很系统级的要用Java不用c++？ |
w***g
发帖数: 5958 | 2 我也觉得很不爽。搞系统的弄了那么多年kqueue,epoll，难道都白弄了？
事实上hadoop的overhead很大的，只有数据极大的情况下才划算。
【在 t********l 的大作中提到】
: 【 以下文字转载自 Programming 讨论区 】
: 发信人: tianyagirl (呢喃), 信区: Programming
: 标 题: Hadoop居然是用Java写的，不理解
: 发信站: BBS 未名空间站 (Tue Jul 8 16:11:10 2008)
: 有人说，当今的趋势Java主要是应用性开发，C++主要是系统级开发。Java虽然稳定跨
: 平台，但是速度慢。为什么hadoop这样很系统级的要用Java不用c++？
|
t******a
发帖数: 1200 | 3 1. Java 启动慢，但 JIT 后实际程序运行并不慢
2. 大部分 Internet sized distributed tasks 瓶颈都不在 task coordinator
上， 而是在 IO 上.
3. 什么是系统开发? *nix 下一堆东西是 shell script 写的. Web Dev 领域
Python, PHP, Ruby 等解释性语言才是主流，这些比 Java 更慢，照样没事。
因为大部分瓶颈根本不在这里. 就算你把系统级开发限制为 OS kernel dev
的话，那主要语言是 C 而不是 C++. C++ 现在最主要的应用领域恐怕是
Gaming Industry & Telecom Industry, 以前 UI Framework 是 C++ 的
强项，但现在用 C++ 做 UI 的人应该不多了.
【在 t********l 的大作中提到】
: 【 以下文字转载自 Programming 讨论区 】
: 发信人: tianyagirl (呢喃), 信区: Programming
: 标 题: Hadoop居然是用Java写的，不理解
: 发信站: BBS 未名空间站 (Tue Jul 8 16:11:10 2008)
: 有人说，当今的趋势Java主要是应用性开发，C++主要是系统级开发。Java虽然稳定跨
: 平台，但是速度慢。为什么hadoop这样很系统级的要用Java不用c++？
|
w***g
发帖数: 5958 | 4 JIT本身其实并不是问题。在某些情况下java甚至能比C快，因为JIT可以进行动态优化
。但是hadoop的问题不在这儿。Hadoop的大部分工作是网络传输，磁盘读写，文件扫描
，而且要求高吞吐量。用标准java库做这些开销是很大的（比如new xxxStream (new
xxxStream (new xxxStream)))。对比一下OS领域关于消除double buffering的那些论
文，可以看出用java明显就没有走对方向。
我同意script很好，在性能不是问题的前提下。但是现在的问题是性能已经被忽略的太
多了。像Hadoop这种大规模计算的问题，明显是需要高性能的。举个例子吧，如果用
HadoopStreaming+python在一个十台机器的cluster上运行一个任务，保守点估计用C实
现同样的功能性能提高10倍，那么用C写根本就不需要cluster。
Java这东西做做网站，用户界面还可以，但是Java的bloatware的本质决定了它不能胜
任高性能计算。
【在 t******a 的大作中提到】
: 1. Java 启动慢，但 JIT 后实际程序运行并不慢
: 2. 大部分 Internet sized distributed tasks 瓶颈都不在 task coordinator
: 上， 而是在 IO 上.
: 3. 什么是系统开发? *nix 下一堆东西是 shell script 写的. Web Dev 领域
: Python, PHP, Ruby 等解释性语言才是主流，这些比 Java 更慢，照样没事。
: 因为大部分瓶颈根本不在这里. 就算你把系统级开发限制为 OS kernel dev
: 的话，那主要语言是 C 而不是 C++. C++ 现在最主要的应用领域恐怕是
: Gaming Industry & Telecom Industry, 以前 UI Framework 是 C++ 的
: 强项，但现在用 C++ 做 UI 的人应该不多了.
|
t********l
发帖数: 106 | 5 telecom为什么用c++？
难道以后c++就要退出编程舞台了？底层用C，上面用java/c#，最外边用script？
【在 t******a 的大作中提到】
: 1. Java 启动慢，但 JIT 后实际程序运行并不慢
: 2. 大部分 Internet sized distributed tasks 瓶颈都不在 task coordinator
: 上， 而是在 IO 上.
: 3. 什么是系统开发? *nix 下一堆东西是 shell script 写的. Web Dev 领域
: Python, PHP, Ruby 等解释性语言才是主流，这些比 Java 更慢，照样没事。
: 因为大部分瓶颈根本不在这里. 就算你把系统级开发限制为 OS kernel dev
: 的话，那主要语言是 C 而不是 C++. C++ 现在最主要的应用领域恐怕是
: Gaming Industry & Telecom Industry, 以前 UI Framework 是 C++ 的
: 强项，但现在用 C++ 做 UI 的人应该不多了.
|
w***g
发帖数: 5958 | 6 java/c#和script是在同一个层次上的。现在比较多的有下面两种做法
1. 底层用C/C++，接口用C，外面用script。
2. 底层用java, 外面用java。
事实上搞java的那批人逗得很，什么都要用java实现。最好哪天操作系统也用java写了
他们才高兴。（事实上现在有java操作系统，可惜实在没法用。）你去网上找java的
project好了，类似"Jwheel is a java implementation of the Wheel"这样的东西不
计其数。
【在 t********l 的大作中提到】
: telecom为什么用c++？
: 难道以后c++就要退出编程舞台了？底层用C，上面用java/c#，最外边用script？
|
t******a
发帖数: 1200 | 7
1. 你知道什么是 double buffering 么? 你看过 Java Stream 的实现么? 你
Benchmark 过Java IO Library vs C library 么 ? 不要整天拿个你不懂的名词
跑火车。 Java 做 serialization时因为 type saftety 原因不支持类似
readFoo( &myfoo, sizeof(Foo)) 的方法，但单纯的 read, write 是不慢
的， 尤其是 disk/network io.
Premature optimization is the root of all evil. - Don Knuth
Rule 1: Don't optimize your code. Rule 2 : Still don't optimize your code
用 C 实现相同的功能速度不可能是 Java 的十倍。按照我们的经验，Java 比 C
一般情况下慢 20% - 100% 左右。如果有特别 computational bootleneck,
用 JNI 写一个 Native implementat
【在 w***g 的大作中提到】
: JIT本身其实并不是问题。在某些情况下java甚至能比C快，因为JIT可以进行动态优化
: 。但是hadoop的问题不在这儿。Hadoop的大部分工作是网络传输，磁盘读写，文件扫描
: ，而且要求高吞吐量。用标准java库做这些开销是很大的（比如new xxxStream (new
: xxxStream (new xxxStream)))。对比一下OS领域关于消除double buffering的那些论
: 文，可以看出用java明显就没有走对方向。
: 我同意script很好，在性能不是问题的前提下。但是现在的问题是性能已经被忽略的太
: 多了。像Hadoop这种大规模计算的问题，明显是需要高性能的。举个例子吧，如果用
: HadoopStreaming+python在一个十台机器的cluster上运行一个任务，保守点估计用C实
: 现同样的功能性能提高10倍，那么用C写根本就不需要cluster。
: Java这东西做做网站，用户界面还可以，但是Java的bloatware的本质决定了它不能胜
|
t******a
发帖数: 1200 | 8
lol, 没听说过 JPython, JRuby, Groovy ? .Net 上也有一堆 interpreted script
语言的实现。发现你对 Script language 的了解和 Java/C# 一样有限。
【在 w***g 的大作中提到】
: java/c#和script是在同一个层次上的。现在比较多的有下面两种做法
: 1. 底层用C/C++，接口用C，外面用script。
: 2. 底层用java, 外面用java。
: 事实上搞java的那批人逗得很，什么都要用java实现。最好哪天操作系统也用java写了
: 他们才高兴。（事实上现在有java操作系统，可惜实在没法用。）你去网上找java的
: project好了，类似"Jwheel is a java implementation of the Wheel"这样的东西不
: 计其数。
|
t******a
发帖数: 1200 | 9 Telecom 用 C++ 是历史原因，Telecom 对 C++/CORBA 的历史投资强度和当年
银行界对 COBOL 的投资相比有过之而无不及。
C++ 是个好东西，起码在应用层大多数情况比 C 更合适。可惜 C++ 的 learning
curve 太陡了，调试起来也相对麻烦些。多数项目100%用 C++ 来做并不合算。
不过 C++ 至今依然是 Gaming Industry 的不二之选。
你去一些 Internet job website 用 C++ 做关键词搜索一下就能感觉到当今
社会对 C++ 的需求量了
【在 t********l 的大作中提到】
: telecom为什么用c++？
: 难道以后c++就要退出编程舞台了？底层用C，上面用java/c#，最外边用script？
|
d**n
发帖数: 198 | 10 grid is not a parallel machine
it is more for data intensive than for computation intensive.
a classical example is: compute the average of 10billion lines, each line
contains a number plus a long string.
Using a single machine, scanning the data itself taks forever.
Hadoop is a framework. You can write teh mapper/reducer in C++
【在 w***g 的大作中提到】
: JIT本身其实并不是问题。在某些情况下java甚至能比C快，因为JIT可以进行动态优化
: 。但是hadoop的问题不在这儿。Hadoop的大部分工作是网络传输，磁盘读写，文件扫描
: ，而且要求高吞吐量。用标准java库做这些开销是很大的（比如new xxxStream (new
: xxxStream (new xxxStream)))。对比一下OS领域关于消除double buffering的那些论
: 文，可以看出用java明显就没有走对方向。
: 我同意script很好，在性能不是问题的前提下。但是现在的问题是性能已经被忽略的太
: 多了。像Hadoop这种大规模计算的问题，明显是需要高性能的。举个例子吧，如果用
: HadoopStreaming+python在一个十台机器的cluster上运行一个任务，保守点估计用C实
: 现同样的功能性能提高10倍，那么用C写根本就不需要cluster。
: Java这东西做做网站，用户界面还可以，但是Java的bloatware的本质决定了它不能胜
|
|
|
m*****r
发帖数: 130 | 11 java 慢也是分情况，其实很多时候程序是在等I/O bound的，还有是memory-bound的，
一旦分布式了，这个网络通讯代价就太大了，很多程序都是在等数据，内存的，硬盘的
，网络的。
另一方面cpu intensive的程序JVM其实动态优化做的很好，我做过矩阵相乘的
benchmark，弄成block相乘利用L2cache，c的程序必须编译-O3才能跟java1.5的相比。
【在 t********l 的大作中提到】
: telecom为什么用c++？
: 难道以后c++就要退出编程舞台了？底层用C，上面用java/c#，最外边用script？
|
D*******a
发帖数: 3688 | 12 c的可以用intel c++ compiler，针对cpu优化了比gcc快很多
【在 m*****r 的大作中提到】
: java 慢也是分情况，其实很多时候程序是在等I/O bound的，还有是memory-bound的，
: 一旦分布式了，这个网络通讯代价就太大了，很多程序都是在等数据，内存的，硬盘的
: ，网络的。
: 另一方面cpu intensive的程序JVM其实动态优化做的很好，我做过矩阵相乘的
: benchmark，弄成block相乘利用L2cache，c的程序必须编译-O3才能跟java1.5的相比。
|
c****r
发帖数: 185 | 13 The learning curve is due to the stupid design of the language itself.
If C++ could get rid of header files, macros, operator override, and
introduce packages, interfaces, lives would be much easier.
【在 t******a 的大作中提到】
: Telecom 用 C++ 是历史原因，Telecom 对 C++/CORBA 的历史投资强度和当年
: 银行界对 COBOL 的投资相比有过之而无不及。
: C++ 是个好东西，起码在应用层大多数情况比 C 更合适。可惜 C++ 的 learning
: curve 太陡了，调试起来也相对麻烦些。多数项目100%用 C++ 来做并不合算。
: 不过 C++ 至今依然是 Gaming Industry 的不二之选。
: 你去一些 Internet job website 用 C++ 做关键词搜索一下就能感觉到当今
: 社会对 C++ 的需求量了
|
d**n
发帖数: 198 | 14 many of C++ features make the code hard to debug.
【在 c****r 的大作中提到】
: The learning curve is due to the stupid design of the language itself.
: If C++ could get rid of header files, macros, operator override, and
: introduce packages, interfaces, lives would be much easier.
|
v******d
发帖数: 1322 | 15 their differeces are not only abt language, but also the implementation. |
w***g
发帖数: 5958 | 16 1. 我说的double buffering指的是文件系统的buffer，跟graphics那个不是一回事。
我指的是sendfile(2)解决的那个问题。另外，hadoop内部处理的是一些块数据，并不
和stream模型对应。Serialization（对应C的printf/scanf)在这里也没有出现，除了
读写配置文件以外。C的low level I/O其实都是一些系统调用，在user level已经没什
么优化余地了。
2. 我不知道系统软件做优化有什么错的。真如你所说，搞系统的人都要哭死。
3. 说C的速度有java的10倍确实有点夸张。如果代码是一行一行对应的话，现在java在
某些情况下确实能和c一样快。但是java的编程风格跟c很不一样的。你见过在java中用
循环展开优化代码的吗事实上java的一个好处就是抽象程度比较好，不用考虑这些细
节问题，但是在性能上的损失也是不可挽回的。Java和C根本就是适合不同的问题，没
法直接比的。我的观点是像hadoop这样的文件系统如果用C实现性能会提高很多。
关于我在原帖中提出的那个Hadoop Streaming + Pytho
【在 t******a 的大作中提到】
: Telecom 用 C++ 是历史原因，Telecom 对 C++/CORBA 的历史投资强度和当年
: 银行界对 COBOL 的投资相比有过之而无不及。
: C++ 是个好东西，起码在应用层大多数情况比 C 更合适。可惜 C++ 的 learning
: curve 太陡了，调试起来也相对麻烦些。多数项目100%用 C++ 来做并不合算。
: 不过 C++ 至今依然是 Gaming Industry 的不二之选。
: 你去一些 Internet job website 用 C++ 做关键词搜索一下就能感觉到当今
: 社会对 C++ 的需求量了
|
t******a
发帖数: 1200 | 17 1. 你难道想说的是 Ephemeral Mapping? 这和 Double Buffering 差得也太远了些。
拜托你举一个 System 领域里对 double buffering 这个名词有不同解释的文章?
再说搞 Ephemeral Mapping 的优化得在 OS API 下面一层搞，应用层不管用 C 还
是 Java都没法控制的。你说的应用层多次复制问题，在 Java Steam 里并不存在，
因为 Java 里类似实现都是 copy-on-write 的. 虽然 Java Library 的设计者
有时候很傻，但这么明显的疏忽是不会有的。
2. 优化当然有用，但先得找到程序的瓶颈。而且一般得是优化算法，而不是在
算法固定的时候替换语言和编译器。Java -> C -> Assembly 这样的优化在
工程界有少量的使用，在学术界想用来发论文是不行的。而且这种优化在大多
数情况下是得不偿失的，不然 *nix 的 device drivers 就都被优化成
Assembly language 了.
3. Java 和 C 的用途的确不同，但我这里的观点是对于 Hadoop
【在 w***g 的大作中提到】
: 1. 我说的double buffering指的是文件系统的buffer，跟graphics那个不是一回事。
: 我指的是sendfile(2)解决的那个问题。另外，hadoop内部处理的是一些块数据，并不
: 和stream模型对应。Serialization（对应C的printf/scanf)在这里也没有出现，除了
: 读写配置文件以外。C的low level I/O其实都是一些系统调用，在user level已经没什
: 么优化余地了。
: 2. 我不知道系统软件做优化有什么错的。真如你所说，搞系统的人都要哭死。
: 3. 说C的速度有java的10倍确实有点夸张。如果代码是一行一行对应的话，现在java在
: 某些情况下确实能和c一样快。但是java的编程风格跟c很不一样的。你见过在java中用
: 循环展开优化代码的吗事实上java的一个好处就是抽象程度比较好，不用考虑这些细
: 节问题，但是在性能上的损失也是不可挽回的。Java和C根本就是适合不同的问题，没
|
t******a
发帖数: 1200 | 18 比较 C++/Java/Script language performance 的文章太多了，没必要找一篇
过时的而且有结论争议的文章来支持自己的观点。用这样的态度搞学术研究可不行;)
给你一天时间自己找更新一些的文章，很容易的。如果找不到的话我可以贴
一些链接.
【在 w***g 的大作中提到】
: 1. 我说的double buffering指的是文件系统的buffer，跟graphics那个不是一回事。
: 我指的是sendfile(2)解决的那个问题。另外，hadoop内部处理的是一些块数据，并不
: 和stream模型对应。Serialization（对应C的printf/scanf)在这里也没有出现，除了
: 读写配置文件以外。C的low level I/O其实都是一些系统调用，在user level已经没什
: 么优化余地了。
: 2. 我不知道系统软件做优化有什么错的。真如你所说，搞系统的人都要哭死。
: 3. 说C的速度有java的10倍确实有点夸张。如果代码是一行一行对应的话，现在java在
: 某些情况下确实能和c一样快。但是java的编程风格跟c很不一样的。你见过在java中用
: 循环展开优化代码的吗事实上java的一个好处就是抽象程度比较好，不用考虑这些细
: 节问题，但是在性能上的损失也是不可挽回的。Java和C根本就是适合不同的问题，没
|
w***g
发帖数: 5958 | 19 不是ephemeral mapping。或许叫zero-copy更合适。
另外，Hadoop是一个cluster软件，并不是Internet scale的。Hadoop那种1 head+n
worker的架构不可能达到Internet scale。至于算法优化，一个算法如果需要用
mapreduce实现的，那么基本上可以确定是O(N)复杂度的，O(N^2)也是不可接受的。
MapReduce之所以火起来是因为它把一些trivial的问题scale大了。
【在 t******a 的大作中提到】
: 1. 你难道想说的是 Ephemeral Mapping? 这和 Double Buffering 差得也太远了些。
: 拜托你举一个 System 领域里对 double buffering 这个名词有不同解释的文章?
: 再说搞 Ephemeral Mapping 的优化得在 OS API 下面一层搞，应用层不管用 C 还
: 是 Java都没法控制的。你说的应用层多次复制问题，在 Java Steam 里并不存在，
: 因为 Java 里类似实现都是 copy-on-write 的. 虽然 Java Library 的设计者
: 有时候很傻，但这么明显的疏忽是不会有的。
: 2. 优化当然有用，但先得找到程序的瓶颈。而且一般得是优化算法，而不是在
: 算法固定的时候替换语言和编译器。Java -> C -> Assembly 这样的优化在
: 工程界有少量的使用，在学术界想用来发论文是不行的。而且这种优化在大多
: 数情况下是得不偿失的，不然 *nix 的 device drivers 就都被优化成
|
w***g
发帖数: 5958 | 20 比较这个确实挺无聊的，我干脆把帖子删了。
【在 t******a 的大作中提到】
: 比较 C++/Java/Script language performance 的文章太多了，没必要找一篇
: 过时的而且有结论争议的文章来支持自己的观点。用这样的态度搞学术研究可不行;)
: 给你一天时间自己找更新一些的文章，很容易的。如果找不到的话我可以贴
: 一些链接.
|
d**n
发帖数: 198 | 21 what is the most complex map/reduce code you have written? what is the data
size?
【在 w***g 的大作中提到】
: 不是ephemeral mapping。或许叫zero-copy更合适。
: 另外，Hadoop是一个cluster软件，并不是Internet scale的。Hadoop那种1 head+n
: worker的架构不可能达到Internet scale。至于算法优化，一个算法如果需要用
: mapreduce实现的，那么基本上可以确定是O(N)复杂度的，O(N^2)也是不可接受的。
: MapReduce之所以火起来是因为它把一些trivial的问题scale大了。
|
w***g
发帖数: 5958 | 22 真不好意思我还没写过mapreduce code。我一直在关注hadoop是因为我们想用它来处理
一大批图片文件。一共有十来个TB吧，每个100KB的样子。很不幸的是hadoop基本上不
支持小文件。我们测试过hadoop upload的性能，上传小文件要达到1MB/s都困难，传完
那么多图片基本上就天荒地老了。
事实上我们希望弄一个支持小文件的storage，这样以后更多的文件来了直接存进去，
然后mapreduce，但是hadoop现在的状态还是没法用。如果您老有什么建议不妨讲讲，
要能帮我们解决了这个问题那就最好不过了。
我们自己能想到的无非就是把一个目录tar起来再放到hadoop上。但是那样处理起来比
较麻烦。我正在盼着hadoop实现类似的功能(HBASE?), 呵呵。
data
【在 d**n 的大作中提到】
: what is the most complex map/reduce code you have written? what is the data
: size?
|
