q********y
发帖数: 162 | 1 尤其是在那种成千上万个cluster上跑的。如果是，为什么不把Java程序编译成native
binary，直接以native process 在 server端跑。这样不是快很多吗？问题可能比较傻
，请见谅！ |
t***a
发帖数: 416 | 2 都是在jvm上运行
早先的java版本是把byte code给jvm解释执行
现在是用JIT(just in time compiler) 边load边编译成native code直接给processor
执行
所以java class load是很慢的，但是执行起来的速度还是很快的
native
【在 q********y 的大作中提到】
: 尤其是在那种成千上万个cluster上跑的。如果是，为什么不把Java程序编译成native
: binary，直接以native process 在 server端跑。这样不是快很多吗？问题可能比较傻
: ，请见谅！
|
q********y
发帖数: 162 | 3 谢谢你的回答。
如果Java程序不是那种在cloud上跑的应用，而是本身就是提供infrastructure的，如
那些个
Hadoop,Cassandra什么的，为什么不把他们一次性编译成native code？
processor
【在 t***a 的大作中提到】
: 都是在jvm上运行
: 早先的java版本是把byte code给jvm解释执行
: 现在是用JIT(just in time compiler) 边load边编译成native code直接给processor
: 执行
: 所以java class load是很慢的，但是执行起来的速度还是很快的
:
: native
|
z****e
发帖数: 54598 | 4 你可以一次性编译成native code啊
这个可以借助第三方工具实现
但是多数时候没有必要
因为这样就跟os绑定了
可能会发生一些特定os上才发生的bugs
当然绝大多数时候也不会发生
我觉得你完全可以这么做，没有太大问题
另外一个就是java诞生之初就对客户做了一个承诺
那就是compile once, run everywhere
如果编译成native code的话，就违背了这个承诺
所以大多数时候不提倡这么操作
但是你完全可以这么做，也可以做到，不是很难的事
【在 q********y 的大作中提到】
: 谢谢你的回答。
: 如果Java程序不是那种在cloud上跑的应用，而是本身就是提供infrastructure的，如
: 那些个
: Hadoop,Cassandra什么的，为什么不把他们一次性编译成native code？
:
: processor
|
t***a
发帖数: 416 | 5 用jit这种dynamic的编译方法，有如下好处
1，根据不同cpu，heap大小可以生成不同的native code
2, 可以根据用户如何使用code来优化编译，而不是只通过分析code本身
3，class的load和unload尽在掌握，随时可以重新编译
以前玩gentoo的时候，动不动就重新编译一天，这种事在java世界就不会有了。。。。
【在 q********y 的大作中提到】
: 谢谢你的回答。
: 如果Java程序不是那种在cloud上跑的应用，而是本身就是提供infrastructure的，如
: 那些个
: Hadoop,Cassandra什么的，为什么不把他们一次性编译成native code？
:
: processor
|
t***a
发帖数: 416 | 6 java不是这么玩的。。。。虽然总有人想这么干
【在 z****e 的大作中提到】
: 你可以一次性编译成native code啊
: 这个可以借助第三方工具实现
: 但是多数时候没有必要
: 因为这样就跟os绑定了
: 可能会发生一些特定os上才发生的bugs
: 当然绝大多数时候也不会发生
: 我觉得你完全可以这么做，没有太大问题
: 另外一个就是java诞生之初就对客户做了一个承诺
: 那就是compile once, run everywhere
: 如果编译成native code的话，就违背了这个承诺
|
q********y
发帖数: 162 | 7 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也
就是事实上跟os绑定了。而且作为公司来说，也不在意这种os绑定,又不是终端消费者
，变来变去的。
对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊？
对客户的承诺 “compile once, run everywhere”主要是针对front end 和
Application
developper 的吧？ 作为backend infrastructure，就像你常说的，各个大公司都是定
制的，
什么“os绑定”，“compile once, run everywhere”应该没人在意吧？
【在 z****e 的大作中提到】
: 你可以一次性编译成native code啊
: 这个可以借助第三方工具实现
: 但是多数时候没有必要
: 因为这样就跟os绑定了
: 可能会发生一些特定os上才发生的bugs
: 当然绝大多数时候也不会发生
: 我觉得你完全可以这么做，没有太大问题
: 另外一个就是java诞生之初就对客户做了一个承诺
: 那就是compile once, run everywhere
: 如果编译成native code的话，就违背了这个承诺
|
q********y
发帖数: 162 | 8 谢谢你告诉我这些东西。
我怕再问下去就nagging了。
【在 t***a 的大作中提到】
: 用jit这种dynamic的编译方法，有如下好处
: 1，根据不同cpu，heap大小可以生成不同的native code
: 2, 可以根据用户如何使用code来优化编译，而不是只通过分析code本身
: 3，class的load和unload尽在掌握，随时可以重新编译
: 以前玩gentoo的时候，动不动就重新编译一天，这种事在java世界就不会有了。。。。
|
z****e
发帖数: 54598 | 9 任何java的产品，都能在windows和unix上跑
所以说，cassandra和hadoop都可以在win/unix server上用
但是这种要处理io，所以有些时候会出现一些特定的问题
在不同的os上，但是理论上是完全可以用的
hadoop的file system也就是hdfs还不够成熟，版本现在好像还在0.x
所以正式版还没有出来，所以完全有可能遇到各种问题
这就是现实世界，现在开源的big data还不很成熟
还需要时间
【在 q********y 的大作中提到】
: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也
: 就是事实上跟os绑定了。而且作为公司来说，也不在意这种os绑定,又不是终端消费者
: ，变来变去的。
: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊？
: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和
: Application
: developper 的吧？ 作为backend infrastructure，就像你常说的，各个大公司都是定
: 制的，
: 什么“os绑定”，“compile once, run everywhere”应该没人在意吧？
|
z****e
发帖数: 54598 | 10 一般大公司不会定制jvm下的东西
因为大公司下面一堆乱七八糟的操作系统
大部分公司都有linux/windows/unix的os
很多，开发机器现在还有macosx，所以不同平台上的兼容性是一个很大的问题
比如我们开发一般都是macosx，测试用的是windows
但是实际部署时候，生产环境用的是linux
如果不用java，那就要每次都跑生产环境上去编译
这样搞会挂，所以jvm是很重要的一个工具，没有jvm的话
很多问题搞不定啊，pc上的os跟server上的os一般来说不一样
compile once run everywhere其实对server side来说才是最重要的
mobile和pc上其实现在jdk8.0以后的版本就初步有打算搞native compiling了
javafx就有这个选择
【在 q********y 的大作中提到】
: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也
: 就是事实上跟os绑定了。而且作为公司来说，也不在意这种os绑定,又不是终端消费者
: ，变来变去的。
: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊？
: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和
: Application
: developper 的吧？ 作为backend infrastructure，就像你常说的，各个大公司都是定
: 制的，
: 什么“os绑定”，“compile once, run everywhere”应该没人在意吧？
|
|
|
t***a
发帖数: 416 | 11 jit这东西还是没c++快。。。更别说c了
可怎么办呢，就算一次性编译成native code减少的可能只是class load的时间， 这事
水太深了，c++编译器都搞了这么多年了，这条路也不好走啊
【在 q********y 的大作中提到】
: 谢谢你告诉我这些东西。
: 我怕再问下去就nagging了。
|
z****e
发帖数: 54598 | 12 各大公司一般不定制os，从jvm以下的部分
都是直接买或者直接用现成的产品
要么开源要么商用，现在做os的越来越少了
就是jvm也越来越少有公司在做了
定制的部分在jvm以上，其实企业端的定制部分会再往上一点
jvm以上的app server都是产品，然后app server这个容器内
的东西，才是真正定制的，其它都是类似的产品
品牌不一样而已，ibm的叫websphere，oracle的叫weblogic
red hat的叫jboss etc.
web公司现在如果用java的big data产品的话
从jvm以上开始定制，比如amazon和linkedin
都用jvm，但是写的java code，那就不是一回事了大相迳庭了
如果不用java的话，从os以上开始定制
或者python或者ruby或者php或者tomcat etc.
象google这种公司，则是干脆从底层自己搞
但是没有多少公司能像google这么折腾的，google有钱有能人能做事
其它公司找不到能写os的
【在 q********y 的大作中提到】
: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也
: 就是事实上跟os绑定了。而且作为公司来说，也不在意这种os绑定,又不是终端消费者
: ，变来变去的。
: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊？
: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和
: Application
: developper 的吧？ 作为backend infrastructure，就像你常说的，各个大公司都是定
: 制的，
: 什么“os绑定”，“compile once, run everywhere”应该没人在意吧？
|
g*****g
发帖数: 34805 | 13 最重要的原因，大多数server应用的瓶颈并不在CPU上，你就算直接上C，throughput也
不会更好。
server应用最常见的瓶颈在DB IO上。而且JIT最多也就比C慢一倍。
【在 q********y 的大作中提到】
: 但是像Java 的 bigdata 一大类应用如Hadoop实际也都是在linux cluster上跑吧。也
: 就是事实上跟os绑定了。而且作为公司来说，也不在意这种os绑定,又不是终端消费者
: ，变来变去的。
: 对提供infrastructure服务的一大票如Cassandra等为什么没有必要啊？
: 对客户的承诺 “compile once, run everywhere”主要是针对front end 和
: Application
: developper 的吧？ 作为backend infrastructure，就像你常说的，各个大公司都是定
: 制的，
: 什么“os绑定”，“compile once, run everywhere”应该没人在意吧？
|
c****e
发帖数: 1453 | 14 pre-JIT is not recommended in general. The client requests will warm up your
server code very fast. |
z****e
发帖数: 54598 | 15 在mobile和tablet上就没那么快了
可能以后会有那么快，这个要靠小菊花和猴屁股们的努力了
所以现阶段，client side的native compiling还是用比较大市场的
your
【在 c****e 的大作中提到】
: pre-JIT is not recommended in general. The client requests will warm up your
: server code very fast.
|
t***a
发帖数: 416 | 16 server side那是没啥问题，至于客户端嘛，我这么多年做的都是不要求performance的
。。。启动慢点就慢点，我记得java 1.4的时候，有客户抱怨，我们就让他启动的时候
去倒杯咖啡。。。。
your
【在 c****e 的大作中提到】
: pre-JIT is not recommended in general. The client requests will warm up your
: server code very fast.
|
g*****g
发帖数: 34805 | 17 Android上的应用，一点不慢。这个东西是要靠优化的，windows是M$的，Sun/Oracle想
在Windows上优化，有难度。到Android上，底下的OS为了上面的VM该怎么改就怎么改，
就可以做到。
【在 z****e 的大作中提到】
: 在mobile和tablet上就没那么快了
: 可能以后会有那么快，这个要靠小菊花和猴屁股们的努力了
: 所以现阶段，client side的native compiling还是用比较大市场的
:
: your
|
t*****n
发帖数: 4908 | 18 android的慢是出了名的。类似的硬件，ios流畅的很。android 3/4搞了个硬件加速，
就到处吹嘘。要是足够的快的，还搞什么加速？
android就是移动os史一个笑话。每天用同样的硬件，要什么虚拟机？ |
z****e
发帖数: 54598 | 19 貌似google对android做了一定程度的优化
但是下面的oem产商改了不少，水平达不到
所以速度就跟不上了
【在 g*****g 的大作中提到】
: Android上的应用，一点不慢。这个东西是要靠优化的，windows是M$的，Sun/Oracle想
: 在Windows上优化，有难度。到Android上，底下的OS为了上面的VM该怎么改就怎么改，
: 就可以做到。
|
g*****g
发帖数: 34805 | 20 LOL，移动史上的笑话秒了所有其他系统的总和。包括PC。
【在 t*****n 的大作中提到】
: android的慢是出了名的。类似的硬件，ios流畅的很。android 3/4搞了个硬件加速，
: 就到处吹嘘。要是足够的快的，还搞什么加速？
: android就是移动os史一个笑话。每天用同样的硬件，要什么虚拟机？
|
z****e
发帖数: 54598 | 21 这就是你跟google的差距
google赌的是将来，拼的是明天
十年前或者二十年前你同样可以说java在pc上很慢
今天那就是另外一个故事了
【在 t*****n 的大作中提到】
: android的慢是出了名的。类似的硬件，ios流畅的很。android 3/4搞了个硬件加速，
: 就到处吹嘘。要是足够的快的，还搞什么加速？
: android就是移动os史一个笑话。每天用同样的硬件，要什么虚拟机？
|
g*****g
发帖数: 34805 | 22 市场不是以小码农个人意志为转移的。要吗随波逐流，要吗被扒掉底裤。
【在 z****e 的大作中提到】
: 这就是你跟google的差距
: google赌的是将来，拼的是明天
: 十年前或者二十年前你同样可以说java在pc上很慢
: 今天那就是另外一个故事了
|
