为什么apache big data 项目多是Java? - 未名空间MITBBS历史存档

为什么apache big data 项目多是Java?# Programming - 葵花宝典

t*a2018-02-19 08:02

1 楼

今天看了自己experian的 credit report ,突然发现自己的个人信息里混进了另一个人
的信息。我只有一个名字，但是(Also Known As) AKA 名字里显示另一个名字。而且
address里面除了有我自己的地址，还有两个不知道哪里的地址，都是休斯顿的。还有
好多个我并没有的信用卡，银行帐户信息。我直接郁闷了。更离奇的是，我好像觉得这
个人是我的以前同学，她本来和我一个学校的，一年前毕业了去了休斯顿，名字就是(
Also Known As) AKA里显示的名字。我真是无语了，这个公司怎么能犯这种低级错误。
我是要打电话去argue?他们处理要多长时间啊？难怪前几天我的credit report 出了问
题！

y*n2018-02-19 08:02

2 楼

最近真的是倒霉透了，工作老是出错，昨天被领导训得好惨，本来已经被领导看不顺眼了，现在坐个电梯又把他给得罪了，刚刚回来，坐在椅子上我都不知道怎么办好了。
事情是这样的，早上嘛，上班，我呢跟一大帮人顶着个睡眼惺松就进电梯了，快要关门的时候，进来了一个人，我也没有抬眼看，昨晚被领导训完后我加班到凌晨三点啊，还没有睡醒，等着电梯关门呢。谁知道电梯响了，超重了，每个人都看着最后进来的那个人，我还是没有看，不耐烦的扯了一句：最后进来的那个人啊，能不能不要浪费大家的时间啊，自觉点好不好啊？说着我抬头一看，倒吸了一口冷气啊，原来就是我们的领导，只见他这时正瞪眼看着我，完了完了，我脚都软了。
到最后领导还是在大家的注视下了电梯，我可以想象他心里对我多么的不满。怎么办，我还没有找到新的工作，现在被炒的话一家大小吃什么喝什么？也许领导没有那么小心眼？而且我说的是实话，超重的话肯定是最后一个人下的，只是我说的好像语气不太友好。领导都是见过大世面的人，不会记我们这些小人的仇的，说着说着我都没有底气了……

s*u2018-02-19 08:02

3 楼

发信人: tosky (飞鸟), 信区: Immigration
标题: 报一个07大潮绿的
发信站: BBS 未名空间站 (Sun Dec 11 14:57:04 2011, 美东)
NIW PD 7/27/07, 485 receipt date 8/16/07, RFE 07/09后就没下文。11/16/11做了
SR，然后月底收到email说让继续等，如果30天内还没动静，才可以再SR。然后就是12
月9日晚上online status 变成是have approved this 485 balabala。关于SR到底会不
会引来RFE，可能还是看个体officer的吧，我比较幸运，因为现在正在失业中呢，还真
害怕引来一个employment verification的RFE。
感谢本版的信息，并祝大家都快快顺利变绿!

s*n2018-02-19 08:02

4 楼

我个人感觉哈，把周芷若的出身改成船家女，才更符合她的个性，就是虽身为下贱，却
心比天高，所以后来才无比珍惜自己在峨嵋派的地位，想抓住张无忌这个潜力股，为此
她不惜冒各种风险，掩盖自己的毒辣，装小白兔。如果是周子旺的女儿，小时候父亲刚
死的时候还是小姐出身，肯定不会在汉水上善解人意的给小张无忌喂饭，就不会给小张
无忌留下美好的回忆了。而且如果自己父亲是周子旺，周芷若的人生中心就不该是江湖
斗争，而是抗元了。。
而张无忌选赵敏，因为他最喜欢赵敏。和赵敏为他付出多不多，没有关系，这是金庸的
爱情观。只是金庸又爱写女主无悔付出的桥段，这才让人混淆了。实际上，金庸剧的男
主，很少有因为她爱我所以我爱她的，通常都是我爱她，一番误会后发现原来她也这么
爱我，我们在一起果然合情合理。

S*t2018-02-19 08:02

5 楼

请大拿来科普一下。

n*g2018-02-19 08:02

6 楼

当初为什么没有用c++写 hadoop Kafka spark?
小弟是转行钱老请科普

m*a2018-02-19 08:02

7 楼

same here. experian sucks.
their phone is not really helpful. use mail, attach all the documents.

c*z2018-02-19 08:02

8 楼

两个办法
要么自杀，要么把领导上了

H*e2018-02-19 08:02

9 楼

gongxi

b*g2018-02-19 08:02

10 楼

白莲花周芷若

w*22018-02-19 08:02

11 楼

基本可以通用。
不过早期的好像电压不是很够，近几代的都好通用。

【在 S********t 的大作中提到】

: 请大拿来科普一下。

s*y2018-02-19 08:02

12 楼

你要这样想
为什么不用0101写呢。这样程序执行效率是最高的
时代在发展你工资增长超的过摩尔定律吗
程序员开发的时间远远比程序运行的时间珍贵
这就是为什么开发语言越来越平民化尽管程序执行效率低但可以靠硬件来弥补
因为摩尔定律远远比你工资增长的快

t*a2018-02-19 08:02

13 楼

documents？需要给他们提供什么文件才好证明那个人不是我？

【在 m*****a 的大作中提到】

: same here. experian sucks.
: their phone is not really helpful. use mail, attach all the documents.

m*U2018-02-19 08:02

14 楼

恭喜！
总算有人报绿了！
我是11月14号做的SR,结果来了个NOID (notice of intent to deny)。我的律师说是个
完全错误的NOID。所以，SR可能完全看运气，case by case的。

b*g2018-02-19 08:02

15 楼

敏敏是我童年女神，敏敏是什么仙女下凡

h*k2018-02-19 08:02

16 楼

Java 适合大规模作业，性能也不错。

【在 n******g 的大作中提到】

: 当初为什么没有用c++写 hadoop Kafka spark?
: 小弟是转行钱老请科普

s*x2018-02-19 08:02

17 楼

周芷若本来就是船家女，什么时候变成周子旺的女儿了？金庸是不是吃饱了撑的，老糊
涂了，乱改原著。还好我还有原版的金庸全集。

【在 s*****n 的大作中提到】

: 我个人感觉哈，把周芷若的出身改成船家女，才更符合她的个性，就是虽身为下贱，却
: 心比天高，所以后来才无比珍惜自己在峨嵋派的地位，想抓住张无忌这个潜力股，为此
: 她不惜冒各种风险，掩盖自己的毒辣，装小白兔。如果是周子旺的女儿，小时候父亲刚
: 死的时候还是小姐出身，肯定不会在汉水上善解人意的给小张无忌喂饭，就不会给小张
: 无忌留下美好的回忆了。而且如果自己父亲是周子旺，周芷若的人生中心就不该是江湖
: 斗争，而是抗元了。。
: 而张无忌选赵敏，因为他最喜欢赵敏。和赵敏为他付出多不多，没有关系，这是金庸的
: 爱情观。只是金庸又爱写女主无悔付出的桥段，这才让人混淆了。实际上，金庸剧的男
: 主，很少有因为她爱我所以我爱她的，通常都是我爱她，一番误会后发现原来她也这么
: 爱我，我们在一起果然合情合理。

c*e2018-02-19 08:02

18 楼

半路出家的，总是会不明白很多事情。

【在 n******g 的大作中提到】

: 当初为什么没有用c++写 hadoop Kafka spark?
: 小弟是转行钱老请科普

y*u2018-02-19 08:02

19 楼

cluster deploy屏蔽底层细节，jvm都handle了
爱你

【在 c*********e 的大作中提到】

: 半路出家的，总是会不明白很多事情。

d*a2018-02-19 08:02

20 楼

Java可移植性极好，放哪都能运行。服务器的软硬件环境差异性大，
可移植性就很重要了。

【在 n******g 的大作中提到】

: 当初为什么没有用c++写 hadoop Kafka spark?
: 小弟是转行钱老请科普

x*u2018-02-19 08:02

21 楼

其实现在到处都是docker，也不需要什么可移植性了
但java还是给编译器提供了很多一次静态编译做不到的优化方式，C++无论如何也没法
在内存利用上接近java，除非内置个新vm

【在 d***a 的大作中提到】

: Java可移植性极好，放哪都能运行。服务器的软硬件环境差异性大，
: 可移植性就很重要了。

h*l2018-02-19 08:02

22 楼

为什么说C++在内存利用上不如Java?

【在 x****u 的大作中提到】

: 其实现在到处都是docker，也不需要什么可移植性了
: 但java还是给编译器提供了很多一次静态编译做不到的优化方式，C++无论如何也没法
: 在内存利用上接近java，除非内置个新vm

y*j2018-02-19 08:02

23 楼

应该说比较Java的GC，cpp如果不注意的话，有很大机会浪费内存空间，有意或者无意
中，比如memory fragmentation, 人为的因素，等等。

: 为什么说C 在内存利用上不如Java?

【在 h**l 的大作中提到】

: 为什么说C++在内存利用上不如Java?

m*p2018-02-19 08:02

24 楼

感觉应该再补充一条：
性能可移植还是代码可移植。Java/Python都是代码可移植，基本不用改动源代码，不
用重新编译就可以运行。
但是性能是否也可以移植需要看具体平台。我目前看到的是x86内部性能基本可以移植
（intel/amd），power/arm/sparc不好说，很可能性能下降非常大，程序仅仅是勉强可
用。

【在 d***a 的大作中提到】

: Java可移植性极好，放哪都能运行。服务器的软硬件环境差异性大，
: 可移植性就很重要了。

d*a2018-02-19 08:02

25 楼

跨架构的性能表现不是担心吧，只要外理器性能足够，内存够大。以前MIPS, Sparc,
Power，Alpha的处理器，性能要强过Intel/AMD的。
另外Java的特长是跨架构移植。楼上有人提到的VM和docker, 那些做不到跨架构移植，
只能解决软件系统不同的问题。不过现在x86一桶江湖，跨架构就不那么重要了，除非
ARM服务器能真正起来。

【在 m*****p 的大作中提到】

: 感觉应该再补充一条：
: 性能可移植还是代码可移植。Java/Python都是代码可移植，基本不用改动源代码，不
: 用重新编译就可以运行。
: 但是性能是否也可以移植需要看具体平台。我目前看到的是x86内部性能基本可以移植
: （intel/amd），power/arm/sparc不好说，很可能性能下降非常大，程序仅仅是勉强可
: 用。

m*p2018-02-19 08:02

26 楼

"只要外理器性能足够，内存够大"：这是把处理器想简单了，其实复杂得很，不能光看
主频和容量。我们现在发现多核心（单CPU核心>32，含超线程）架构有一些瓶颈在
interconnect，当然这些都是软件工程师不关心的。
即使处理器强大，compiler弱也不行，intel cc比gcc强多了，堪称跑分利器，而icc只
支持x86。即使compiler赶上了，system library弱也不行，很多compression/
encryption/computation包都只为x86优化，非x86很多都是现compile的，没有汇编优
化，性能差一个数量级很正常。所有以上都做到了，软件性能很可能也不行，因为x86
有很多特性developers take for granted。譬如x86的icache是coherent的，跟dcache
一样，self modifying code(JIT必备)在icache不coherent的CPU上必须flush icache
，核越多越慢，然后性能就悲剧了，即使CPU跑3GHz，内存1TB也没用。
这是为什么Oracle把整个SPARC部门都砍掉，IBM半死不活，ARM服务器做5年后啥部署都
没有的真正原因。

【在 d***a 的大作中提到】

: 跨架构的性能表现不是担心吧，只要外理器性能足够，内存够大。以前MIPS, Sparc,
: Power，Alpha的处理器，性能要强过Intel/AMD的。
: 另外Java的特长是跨架构移植。楼上有人提到的VM和docker, 那些做不到跨架构移植，
: 只能解决软件系统不同的问题。不过现在x86一桶江湖，跨架构就不那么重要了，除非
: ARM服务器能真正起来。

y*u2018-02-19 08:02

27 楼

> 这是为什么Oracle把整个SPARC部门都砍掉
是的，我几个在sparc的兄弟最近都在刷题呢，说不定哪天就都没了

x86
dcache
icache

【在 m*****p 的大作中提到】

: "只要外理器性能足够，内存够大"：这是把处理器想简单了，其实复杂得很，不能光看
: 主频和容量。我们现在发现多核心（单CPU核心>32，含超线程）架构有一些瓶颈在
: interconnect，当然这些都是软件工程师不关心的。
: 即使处理器强大，compiler弱也不行，intel cc比gcc强多了，堪称跑分利器，而icc只
: 支持x86。即使compiler赶上了，system library弱也不行，很多compression/
: encryption/computation包都只为x86优化，非x86很多都是现compile的，没有汇编优
: 化，性能差一个数量级很正常。所有以上都做到了，软件性能很可能也不行，因为x86
: 有很多特性developers take for granted。譬如x86的icache是coherent的，跟dcache
: 一样，self modifying code(JIT必备)在icache不coherent的CPU上必须flush icache
: ，核越多越慢，然后性能就悲剧了，即使CPU跑3GHz，内存1TB也没用。

d*a2018-02-19 08:02

28 楼

处理器的性能，并不是指主频。流水线的设计和配置，cache设计，内存子系统设计，
多核interconnect和cache coherence设计，都会在处理器性能上反映出来。一般要
用benchmark来测量处理器性能，不是说主频高的性能就好。
从Java的历史来看，当时开发Java的时候（1991年)，MIPS, Sparc, Alpha, Power是远
强于x86的。当时那些都是工作站和服务器上用的高端处理器，x86是PC上用的相对低
端的处理器。Shared-memory multiprocessor和cache coherence是在那些处理器上先
开发出来，然后才移植到x86上。Sparc当时可以做到512个处理器的cache coherence。
当时的处理器都是单核，做shared-memory和cache coherence要比现在难得多。从技术
上说，icache做cache coherence，其实是很简单的事情。
编译器方面，当时是MIPS做的最好，我记得。现在Intel的编译器确实很强，但实际上
Intel的x86的编译优化，比RISC处理器上的优化要难得多，这是因为Intel的指令集做
的非常不好，不利于编译优化。换句话说，在RISC处理器上能不能用Intel的编译器，
并不重要。
当然你说的同样有道理。多核处理器的性能优化，现在很重要。

x86
dcache
icache

【在 m*****p 的大作中提到】

: "只要外理器性能足够，内存够大"：这是把处理器想简单了，其实复杂得很，不能光看
: 主频和容量。我们现在发现多核心（单CPU核心>32，含超线程）架构有一些瓶颈在
: interconnect，当然这些都是软件工程师不关心的。
: 即使处理器强大，compiler弱也不行，intel cc比gcc强多了，堪称跑分利器，而icc只
: 支持x86。即使compiler赶上了，system library弱也不行，很多compression/
: encryption/computation包都只为x86优化，非x86很多都是现compile的，没有汇编优
: 化，性能差一个数量级很正常。所有以上都做到了，软件性能很可能也不行，因为x86
: 有很多特性developers take for granted。譬如x86的icache是coherent的，跟dcache
: 一样，self modifying code(JIT必备)在icache不coherent的CPU上必须flush icache
: ，核越多越慢，然后性能就悲剧了，即使CPU跑3GHz，内存1TB也没用。

d*a2018-02-19 08:02

29 楼

其实我觉得，以你的背景，真心不用走刷题这条路。外专业转CS，刷题是必须的。你已
经有足够多的经验，就算是想做软工，花不多的时间刷一些题就行了，你做系统的经验
仍然会很有用。
在FLAG里，做系统软件和性能优化的位置是有一些的，也可以直接找。那些位置实际上
是属于核心部门，就是进去不太容易。如果是fresh PhD，他们会看有没有顶会文章，
但有经验的人就不一样了。

x86
dcache
icache

【在 m*****p 的大作中提到】

: "只要外理器性能足够，内存够大"：这是把处理器想简单了，其实复杂得很，不能光看
: 主频和容量。我们现在发现多核心（单CPU核心>32，含超线程）架构有一些瓶颈在
: interconnect，当然这些都是软件工程师不关心的。
: 即使处理器强大，compiler弱也不行，intel cc比gcc强多了，堪称跑分利器，而icc只
: 支持x86。即使compiler赶上了，system library弱也不行，很多compression/
: encryption/computation包都只为x86优化，非x86很多都是现compile的，没有汇编优
: 化，性能差一个数量级很正常。所有以上都做到了，软件性能很可能也不行，因为x86
: 有很多特性developers take for granted。譬如x86的icache是coherent的，跟dcache
: 一样，self modifying code(JIT必备)在icache不coherent的CPU上必须flush icache
: ，核越多越慢，然后性能就悲剧了，即使CPU跑3GHz，内存1TB也没用。

m*p2018-02-19 08:02

30 楼

同意icache coherence现在很好做，但是就有一种处理器没有做（说你呢ARMv8。。。
），可能因为省电，也可能因为手机目前不需要那么多核心，icache flush不是那么慢
，或者手机上不会运行大型java和php程序，所以目前的ARM都没有支持。PC服务器市场
现在有20多年吧，隐藏的坑其实有很多。SPARC/POWER那些其实应该算小鸡，不是PC服
务器。但市场都模糊了，现在的scalable xeon也把小鸡市场占领了一些。

【在 d***a 的大作中提到】

: 处理器的性能，并不是指主频。流水线的设计和配置，cache设计，内存子系统设计，
: 多核interconnect和cache coherence设计，都会在处理器性能上反映出来。一般要
: 用benchmark来测量处理器性能，不是说主频高的性能就好。
: 从Java的历史来看，当时开发Java的时候（1991年)，MIPS, Sparc, Alpha, Power是远
: 强于x86的。当时那些都是工作站和服务器上用的高端处理器，x86是PC上用的相对低
: 端的处理器。Shared-memory multiprocessor和cache coherence是在那些处理器上先
: 开发出来，然后才移植到x86上。Sparc当时可以做到512个处理器的cache coherence。
: 当时的处理器都是单核，做shared-memory和cache coherence要比现在难得多。从技术
: 上说，icache做cache coherence，其实是很简单的事情。
: 编译器方面，当时是MIPS做的最好，我记得。现在Intel的编译器确实很强，但实际上

d*a2018-02-19 08:02

31 楼

呵呵，ARM是为embedded system设计的，这习惯还没有改过来。不过这不是ARMv8指令
集的事，是微架构上的问题，改改很容易。
Intel Xeon现在是大型服务器上的巨无霸。技术上，我个人看好用ARMv8的服务器，但
不知道市场接受程度如何。得大妈者得天下，IT界大多数时候是市场说了算，不是技术
...这是没办法的事。

【在 m*****p 的大作中提到】

: 同意icache coherence现在很好做，但是就有一种处理器没有做（说你呢ARMv8。。。
: ），可能因为省电，也可能因为手机目前不需要那么多核心，icache flush不是那么慢
: ，或者手机上不会运行大型java和php程序，所以目前的ARM都没有支持。PC服务器市场
: 现在有20多年吧，隐藏的坑其实有很多。SPARC/POWER那些其实应该算小鸡，不是PC服
: 务器。但市场都模糊了，现在的scalable xeon也把小鸡市场占领了一些。

h*l2018-02-19 08:02

32 楼

C++ 写的不会拿出来给你开源的，谷歌自己的代码从来不用apache那些demo

【在 n******g 的大作中提到】

: 当初为什么没有用c++写 hadoop Kafka spark?
: 小弟是转行钱老请科普

h*c2018-02-19 08:02

33 楼

反正是抄谷歌，用java抄的快啊

y*j2018-02-19 08:02

34 楼

光靠Intel compiler性能提高是很有限的，必须要要对程序tuning and profiling, 还
要对程序本身有深刻的了解，才能有效地提高性能。
记得曾经乔布斯和苹果的粉丝们对powerpc 赞不绝口，但是后来还是换成了Intel芯片。

: "只要外理器性能足够，内存够大"：这是把处理器想简单了，其实复杂得很，不
能光看

: 主频和容量。我们现在发现多核心（单CPU核心

【在 m*****p 的大作中提到】

: 同意icache coherence现在很好做，但是就有一种处理器没有做（说你呢ARMv8。。。
: ），可能因为省电，也可能因为手机目前不需要那么多核心，icache flush不是那么慢
: ，或者手机上不会运行大型java和php程序，所以目前的ARM都没有支持。PC服务器市场
: 现在有20多年吧，隐藏的坑其实有很多。SPARC/POWER那些其实应该算小鸡，不是PC服
: 务器。但市场都模糊了，现在的scalable xeon也把小鸡市场占领了一些。

x*u2018-02-19 08:02

35 楼

C++没法做到引用安全释放，除非山寨个GC的vm
现在的主流写法是放弃治疗，直接多进程，把房子炸掉里面的垃圾就没了

【在 h**l 的大作中提到】

: 为什么说C++在内存利用上不如Java?

x*u2018-02-19 08:02

36 楼

icc就是害死安藤的罪魁祸首
因为编译器技术不仅仅是C语言一次build时用，各种场合都要用。搞个专利技术拖后腿
处理器还高度依赖这个，不是作死么

x86
dcache
icache

【在 m*****p 的大作中提到】

: "只要外理器性能足够，内存够大"：这是把处理器想简单了，其实复杂得很，不能光看
: 主频和容量。我们现在发现多核心（单CPU核心>32，含超线程）架构有一些瓶颈在
: interconnect，当然这些都是软件工程师不关心的。
: 即使处理器强大，compiler弱也不行，intel cc比gcc强多了，堪称跑分利器，而icc只
: 支持x86。即使compiler赶上了，system library弱也不行，很多compression/
: encryption/computation包都只为x86优化，非x86很多都是现compile的，没有汇编优
: 化，性能差一个数量级很正常。所有以上都做到了，软件性能很可能也不行，因为x86
: 有很多特性developers take for granted。譬如x86的icache是coherent的，跟dcache
: 一样，self modifying code(JIT必备)在icache不coherent的CPU上必须flush icache
: ，核越多越慢，然后性能就悲剧了，即使CPU跑3GHz，内存1TB也没用。

b*s2018-02-19 08:02

37 楼

"单核，做shared-memory和cache coherence要比现在难得多"
seriously?

【在 d***a 的大作中提到】

: 处理器的性能，并不是指主频。流水线的设计和配置，cache设计，内存子系统设计，
: 多核interconnect和cache coherence设计，都会在处理器性能上反映出来。一般要
: 用benchmark来测量处理器性能，不是说主频高的性能就好。
: 从Java的历史来看，当时开发Java的时候（1991年)，MIPS, Sparc, Alpha, Power是远
: 强于x86的。当时那些都是工作站和服务器上用的高端处理器，x86是PC上用的相对低
: 端的处理器。Shared-memory multiprocessor和cache coherence是在那些处理器上先
: 开发出来，然后才移植到x86上。Sparc当时可以做到512个处理器的cache coherence。
: 当时的处理器都是单核，做shared-memory和cache coherence要比现在难得多。从技术
: 上说，icache做cache coherence，其实是很简单的事情。
: 编译器方面，当时是MIPS做的最好，我记得。现在Intel的编译器确实很强，但实际上

d*a2018-02-19 08:02

38 楼

单核时代，要做到512个CPU的shared-memory并行，就得在512个处理器芯片之间做
shared-memory和cache coherence。多核时代，如果用32核处理器，只要在16个处理器
芯片之间做就是512个CPU并行了。

【在 b*******s 的大作中提到】

: "单核，做shared-memory和cache coherence要比现在难得多"
: seriously?