b***y
发帖数: 2799 | 1 ☆─────────────────────────────────────☆
repast (xebec) 于 (Fri Aug 29 02:30:34 2008) 提到:
刚刚 google 了一下，给你们看看这个：
http://shootout.alioth.debian.org/
我自己还没看，先贴一个。我态度是语言快慢是个小问题，写程序的快慢是大问题。
☆─────────────────────────────────────☆
repast (xebec) 于 (Fri Aug 29 02:36:22 2008) 提到:
Python:
http://shootout.alioth.debian.org/gp4/python.php
☆─────────────────────────────────────☆
repast (xebec) 于 (Fri Aug 29 02:42:09 2008) 提到:
受不了了，谁说 JRuby 很快来着？
http://shootout.alioth.debian.org/gp4/benchmark. |
b******n
发帖数: 592 | 2 有一段讲到为了性能开发成本翻倍的问题，其实客户不管你开发成本多高。如果是单一
客户的项目（这个可能是这里很多人做得），开发成本比较重要。如果开发的产品是上
千个客户用的，你的开发成本的翻倍，可以让上千客户省下一般的硬件成本的话，还是
很有吸引力的。所以并不是说自己省了机器的钱却化在程序员身上了这么简单。
【在 b***y 的大作中提到】
: ☆─────────────────────────────────────☆
: repast (xebec) 于 (Fri Aug 29 02:30:34 2008) 提到:
: 刚刚 google 了一下，给你们看看这个：
: http://shootout.alioth.debian.org/
: 我自己还没看，先贴一个。我态度是语言快慢是个小问题，写程序的快慢是大问题。
: ☆─────────────────────────────────────☆
: repast (xebec) 于 (Fri Aug 29 02:36:22 2008) 提到:
: Python:
: http://shootout.alioth.debian.org/gp4/python.php
: ☆─────────────────────────────────────☆
|
m*****e
发帖数: 4193 | 3 Exactly why I said some people are too focused on their own industry. They
don't have the sense of economics, not just technology.
【在 b******n 的大作中提到】
: 有一段讲到为了性能开发成本翻倍的问题，其实客户不管你开发成本多高。如果是单一
: 客户的项目（这个可能是这里很多人做得），开发成本比较重要。如果开发的产品是上
: 千个客户用的，你的开发成本的翻倍，可以让上千客户省下一般的硬件成本的话，还是
: 很有吸引力的。所以并不是说自己省了机器的钱却化在程序员身上了这么简单。
|
g*****g
发帖数: 34805 | 4 这本身说的就是缺乏常识，在服务器端跑的东西，有多少装上千份的？
在科学计算的领域之外，大约也就DB，app server, content management
server, ERP这类少数比较标准化的东西算得上。服务器端的东西本来就是
针对一群人的，而一群人的需要会与另一群人不同。即便是上面说的这些
标准化的东西，也只有瓶颈的一小块东西会用C/C++的语言去实现，比如
DB的内核。
几乎任何行业都使用应用服务器，并且大部分行业都是CRUD基础加一些
各行业相关的商业逻辑。应用体系结构可以不同，但本质都是
request/response。最重要的无非就是security, transaction, scalability，
reliablity这些概念，这些远远比单机的performance重要的多。
C++因为语言本身的原因，在scalability和reliability上有很大缺陷。
所以新的服务器应用很少再用C++来写。系统崩溃一次造成的损失，可能
比硬件的价格还贵。而一旦业务增长，用户数上升，面临的就是被迫重写
应用使其scalable，这要比硬件价格贵多了。
大多数行业
【在 b******n 的大作中提到】
: 有一段讲到为了性能开发成本翻倍的问题，其实客户不管你开发成本多高。如果是单一
: 客户的项目（这个可能是这里很多人做得），开发成本比较重要。如果开发的产品是上
: 千个客户用的，你的开发成本的翻倍，可以让上千客户省下一般的硬件成本的话，还是
: 很有吸引力的。所以并不是说自己省了机器的钱却化在程序员身上了这么简单。
|
h*******e
发帖数: 225 | 5 不知道你老是说C++有scalability问题是什么意思，是说coding上不容易写大系统，
还是说做出来的系统不scalable.
【在 g*****g 的大作中提到】
: 这本身说的就是缺乏常识，在服务器端跑的东西，有多少装上千份的？
: 在科学计算的领域之外，大约也就DB，app server, content management
: server, ERP这类少数比较标准化的东西算得上。服务器端的东西本来就是
: 针对一群人的，而一群人的需要会与另一群人不同。即便是上面说的这些
: 标准化的东西，也只有瓶颈的一小块东西会用C/C++的语言去实现，比如
: DB的内核。
: 几乎任何行业都使用应用服务器，并且大部分行业都是CRUD基础加一些
: 各行业相关的商业逻辑。应用体系结构可以不同，但本质都是
: request/response。最重要的无非就是security, transaction, scalability，
: reliablity这些概念，这些远远比单机的performance重要的多。
|
b******n
发帖数: 592 | 6 我没有看你的文章，就第一句话做回复，我之前公司做搜索，何止上千份。语音识别，
客户信息处理，何止上千份。我也只做过标准的。现在做语音识别系统，虽然是公司内
部用，但是性能还是非常重要的。语音识别问题是搜索的一种，速度一直是非常重要的
，即使到现在。速度越快代表搜索错误可以降低。如果只是frontend的东西，你基本上
不用考虑性能。但是即使作数据库写query的，差别还是很大的，牛的人写的东西速度
快，挣得钱自然多。我们的系统现在有两个data center，任何东西都要优化。性能当
然是基于其他条件的，而不是说追求了性能放弃其它。所以我的观点是性能还是重要的
，但是不是说其它就不重要。我觉得现在IT为什么项目流产这么多，也是因为太单一的
要求，只注意到片面的需求。性能其实越好，reliability就越好，都是相辅相成的。
当然这一切都是根据项目的需要，之前公司做很多demo，都是frontend，所以开发时间
要短，都是用开发时间短的工具。大部分IT公司也是这样的，用别人的内核开发。
【在 g*****g 的大作中提到】
: 这本身说的就是缺乏常识，在服务器端跑的东西，有多少装上千份的？
: 在科学计算的领域之外，大约也就DB，app server, content management
: server, ERP这类少数比较标准化的东西算得上。服务器端的东西本来就是
: 针对一群人的，而一群人的需要会与另一群人不同。即便是上面说的这些
: 标准化的东西，也只有瓶颈的一小块东西会用C/C++的语言去实现，比如
: DB的内核。
: 几乎任何行业都使用应用服务器，并且大部分行业都是CRUD基础加一些
: 各行业相关的商业逻辑。应用体系结构可以不同，但本质都是
: request/response。最重要的无非就是security, transaction, scalability，
: reliablity这些概念，这些远远比单机的performance重要的多。
|
g*****g
发帖数: 34805 | 7 没有标准的serialization和application container的spec，
再加上portability本身就不好。很难做到一个单机跑的应用
扔到一个集群上不需要修改应用。
【在 h*******e 的大作中提到】
: 不知道你老是说C++有scalability问题是什么意思，是说coding上不容易写大系统，
: 还是说做出来的系统不scalable.
|
g*****g
发帖数: 34805 | 8 没有人说性能不重要，我说的是单机性能相对不重要，如果一个集群可以很容易
提高性能，为了单机性能加倍而加倍开发维护费用，绝大多数情况下得不偿失。
任何行业不需要代码级别的定制，直接拿来就可以用的应用是很少的，大部分需要
二次开发，需要优化的只是内核的一小部分。
【在 b******n 的大作中提到】
: 我没有看你的文章，就第一句话做回复，我之前公司做搜索，何止上千份。语音识别，
: 客户信息处理，何止上千份。我也只做过标准的。现在做语音识别系统，虽然是公司内
: 部用，但是性能还是非常重要的。语音识别问题是搜索的一种，速度一直是非常重要的
: ，即使到现在。速度越快代表搜索错误可以降低。如果只是frontend的东西，你基本上
: 不用考虑性能。但是即使作数据库写query的，差别还是很大的，牛的人写的东西速度
: 快，挣得钱自然多。我们的系统现在有两个data center，任何东西都要优化。性能当
: 然是基于其他条件的，而不是说追求了性能放弃其它。所以我的观点是性能还是重要的
: ，但是不是说其它就不重要。我觉得现在IT为什么项目流产这么多，也是因为太单一的
: 要求，只注意到片面的需求。性能其实越好，reliability就越好，都是相辅相成的。
: 当然这一切都是根据项目的需要，之前公司做很多demo，都是frontend，所以开发时间
|
z***e
发帖数: 5393 | 9 呃，我觉得哈，支持Java/Python等等的，大多是fan google多过fan MSFT吧？
但是他们虽然口口声声说单机performance不重要，但是Chrome出来之后，他们最赞的
就是省了多少内存，Jscript执行得多快......
【在 b******n 的大作中提到】
: 有一段讲到为了性能开发成本翻倍的问题，其实客户不管你开发成本多高。如果是单一
: 客户的项目（这个可能是这里很多人做得），开发成本比较重要。如果开发的产品是上
: 千个客户用的，你的开发成本的翻倍，可以让上千客户省下一般的硬件成本的话，还是
: 很有吸引力的。所以并不是说自己省了机器的钱却化在程序员身上了这么简单。
|
g*****g
发帖数: 34805 | 10 客户端软件跟服务器端软件根本不是一个概念，客户端有集群概念吗？
【在 z***e 的大作中提到】
: 呃，我觉得哈，支持Java/Python等等的，大多是fan google多过fan MSFT吧？
: 但是他们虽然口口声声说单机performance不重要，但是Chrome出来之后，他们最赞的
: 就是省了多少内存，Jscript执行得多快......
|
|
|
w***g
发帖数: 5958 | 11 我学生一个，没什么业界经验，下面的观点请大家指正：不少问题可以在单机上解决就
要尽可能在单机上解决。因为一旦涉及到集群容错性就成了问题。机器一多免不了经常
有一两个当掉。然后就增加了程序的复杂性和运行时间。
另外，可以线性scale的算法其实占所有算法的比例其实并不高。即使理论上可以线性s
cale的情况(比如N个数求和)，机器加倍性能加倍的神话也就是在小规模情况下才近似有
效。
【在 g*****g 的大作中提到】
: 没有人说性能不重要，我说的是单机性能相对不重要，如果一个集群可以很容易
: 提高性能，为了单机性能加倍而加倍开发维护费用，绝大多数情况下得不偿失。
: 任何行业不需要代码级别的定制，直接拿来就可以用的应用是很少的，大部分需要
: 二次开发，需要优化的只是内核的一小部分。
|
g*****g
发帖数: 34805 | 12 稍微一个严肃点的企业应用，必然load balanced，集群当掉一个节点
无非慢一点，单机解决当了怎么办？集群的容错性比单机好太多了。
不明白你说什么算法，企业应用通常就是接受很多的request，大部分
来自不同IP的request没有相关性，分发到不同的节点上处理即可，算法
上很容易scale。绝大多数的应用都属于这种情况。
性s
似有
【在 w***g 的大作中提到】
: 我学生一个，没什么业界经验，下面的观点请大家指正：不少问题可以在单机上解决就
: 要尽可能在单机上解决。因为一旦涉及到集群容错性就成了问题。机器一多免不了经常
: 有一两个当掉。然后就增加了程序的复杂性和运行时间。
: 另外，可以线性scale的算法其实占所有算法的比例其实并不高。即使理论上可以线性s
: cale的情况(比如N个数求和)，机器加倍性能加倍的神话也就是在小规模情况下才近似有
: 效。
|
c****e
发帖数: 1453 | 13 Of course Algorithm is the No1. factor. But how far can you stretch those
classic algorithms? Lots of them can't even be parallized. So the algorithm
is there and the difference is optimization, where language and compiler are
the key points. For example, On a x86(AMD64) machine, icc generates much
faster code than g++ if your code uses stl containers heavily.
When you try to pick a package to build a binary decision tree, no one gonna
pick java although there exist some of them. When you are wr |
d******n
发帖数: 42 | 14 I write scientific computing programs (FEM) and I care about speed and
memory usage. So I chose C++.
I am not aware of any FEM program written in Java. |
g*****n
发帖数: 420 | 15 不论Java的伸缩性多好，我见到的几乎所有的音频视频解码编码都是用C写的，很多部
分用针对CPU多媒体指令优化的汇编写的。我从来没见过有人用Java写这类程序，特别
是摩尔定律已经失效了的今天。 |
l*****g
发帖数: 547 | 16 why don't you use fortran then? FEM people all like that.
【在 d******n 的大作中提到】
: I write scientific computing programs (FEM) and I care about speed and
: memory usage. So I chose C++.
: I am not aware of any FEM program written in Java.
|
g*****g
发帖数: 34805 | 17 According to this article, Java's performance isn't that bad.
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V28-49FR4BN-1&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_version=1&_urlVersion=0&_userid=10&md5=f6d9065954369e569f7cdbbff19ccd55
It will take time. Java wasn't used in embeded system in day 1 either.
【在 d******n 的大作中提到】
: I write scientific computing programs (FEM) and I care about speed and
: memory usage. So I chose C++.
: I am not aware of any FEM program written in Java.
|
r*********r
发帖数: 3195 | 18 有没有人觉得c#写的程序好像比java要快一点？
当然这和语言本身没有关系，
主要取决于编译器和虚拟机的实现。
我把一个java的程序(单线程，很少IO)改成c#, 快了一倍。
运行环境是intel mac,分别用 sun jdk 和 mono.
估计用微软的还能更快一点。 |
x******c
发帖数: 13 | 19
Actually this probably mainly due to the language. Java, as an old language,
has many design flaws which makes it harder to optimize than C#
【在 r*********r 的大作中提到】
: 有没有人觉得c#写的程序好像比java要快一点？
: 当然这和语言本身没有关系，
: 主要取决于编译器和虚拟机的实现。
: 我把一个java的程序(单线程，很少IO)改成c#, 快了一倍。
: 运行环境是intel mac,分别用 sun jdk 和 mono.
: 估计用微软的还能更快一点。
|
g*****g
发帖数: 34805 | 20 You guys draw conclusion too fast.
According to this url
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=csharp
Java is faster than C# mono in all but 1 benchmark tests although use more
memory
language,
【在 x******c 的大作中提到】
:
: Actually this probably mainly due to the language. Java, as an old language,
: has many design flaws which makes it harder to optimize than C#
|
|
|
h***z
发帖数: 233 | 21 Does your program use a lot of library calls? Java VM is pretty good in
performance but Java libraries are mostly written in pure Java (for cross
platform compatibility reasons) which puts it at a disadvantage in terms of
performance when comparing against other high level languages that make
extensive use of libraries written in C/C++. Also, the design philosophy
behind Java libraries is to make things as general as possible. This also
extracts a performance penalty since making things more
【在 r*********r 的大作中提到】
: 有没有人觉得c#写的程序好像比java要快一点？
: 当然这和语言本身没有关系，
: 主要取决于编译器和虚拟机的实现。
: 我把一个java的程序(单线程，很少IO)改成c#, 快了一倍。
: 运行环境是intel mac,分别用 sun jdk 和 mono.
: 估计用微软的还能更快一点。
|
x******c
发帖数: 13 | 22 Maybe, but I highly doubt the value of such benchmarks. Such simple, toy-
like benchmarking is meaningless. For real-world applications, you would
have lots of classes/virtual functions/templates etc, and c/c++/java/c#
programmers would write very different code because they have different
programming pattern, and that is the true deciding factor in speed. To be
fair, it's inherently hard to compare speed of different languages.
【在 g*****g 的大作中提到】
: You guys draw conclusion too fast.
: According to this url
: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=csharp
: Java is faster than C# mono in all but 1 benchmark tests although use more
: memory
:
: language,
|
g*****g
发帖数: 34805 | 23 Such benchmark is usually accurate in the order of magnitude,
when you have the same underlying algorithm in real world application.
【在 x******c 的大作中提到】
: Maybe, but I highly doubt the value of such benchmarks. Such simple, toy-
: like benchmarking is meaningless. For real-world applications, you would
: have lots of classes/virtual functions/templates etc, and c/c++/java/c#
: programmers would write very different code because they have different
: programming pattern, and that is the true deciding factor in speed. To be
: fair, it's inherently hard to compare speed of different languages.
|
r*********r
发帖数: 3195 | 24 that's my guess too. i've read some of sun jdk library's code, not a big
fan of it,
indeed too many layers, from java down to the native c code.
of
means
【在 h***z 的大作中提到】
: Does your program use a lot of library calls? Java VM is pretty good in
: performance but Java libraries are mostly written in pure Java (for cross
: platform compatibility reasons) which puts it at a disadvantage in terms of
: performance when comparing against other high level languages that make
: extensive use of libraries written in C/C++. Also, the design philosophy
: behind Java libraries is to make things as general as possible. This also
: extracts a performance penalty since making things more
|
x******c
发帖数: 13 | 25 Since most results are within the same order of magnitude, this kind of
accuracy still means the benchmarks are useless :)
【在 g*****g 的大作中提到】
: Such benchmark is usually accurate in the order of magnitude,
: when you have the same underlying algorithm in real world application.
|
b******n
发帖数: 592 | 26 chrome uses more memory than other browser.
【在 z***e 的大作中提到】
: 呃，我觉得哈，支持Java/Python等等的，大多是fan google多过fan MSFT吧？
: 但是他们虽然口口声声说单机performance不重要，但是Chrome出来之后，他们最赞的
: 就是省了多少内存，Jscript执行得多快......
|
r****t
发帖数: 10904 | 27 I haven't tried chrome at all. Not sure when I will try it, but I was told
it renders much slower than firefox.
【在 z***e 的大作中提到】
: 呃，我觉得哈，支持Java/Python等等的，大多是fan google多过fan MSFT吧？
: 但是他们虽然口口声声说单机performance不重要，但是Chrome出来之后，他们最赞的
: 就是省了多少内存，Jscript执行得多快......
|
h***z
发帖数: 233 | 28 JavaScript is supposed to run much faster on Chrome than Firefox 3.0. But
Firefox 3.1 alpha is said to be even faster.
【在 r****t 的大作中提到】
: I haven't tried chrome at all. Not sure when I will try it, but I was told
: it renders much slower than firefox.
|
r****t
发帖数: 10904 | 29 it's said that starting from firefox 3.1, Javascript will be run in separate
thread so the UI is more responsive ( I am surprised that it doesn't at
this moment.)
【在 h***z 的大作中提到】
: JavaScript is supposed to run much faster on Chrome than Firefox 3.0. But
: Firefox 3.1 alpha is said to be even faster.
|
