d*********0
发帖数: 50 | 1 我们每个程序都要run 四五个小时，
每个程序都要3G左右内存，
一样的工作量， 这速度，这内存的控制，岂是其他语言可以胜任的？ |
w***g
发帖数: 5958 | 2 握抓。意思是这样，但是3G内存太小儿科了。我这边很容易就上50G+内存。最近正在用
C++重写一批python脚本。本来的设计是C++做计算python做外围处理，结果python耗时
比C++还多，服务器快扛不住了。最终可能还是要用机群，但是重写一下单机估计还能
再扛个一年半年的。单机转到机群如果想达到2x的性能往往需要5x的机器甚至更多，而
且稳定性和维护开销要大打折扣。
以前还遇到过matlab读数据。机器有64G内存，矩阵是30G， 硬是读不进来，因为读的
过程中需要另外30G做缓存。
【在 d*********0 的大作中提到】
: 我们每个程序都要run 四五个小时，
: 每个程序都要3G左右内存，
: 一样的工作量， 这速度，这内存的控制，岂是其他语言可以胜任的？
|
Y**G
发帖数: 1089 | 3 为啥是“珍惜生命远离湾区”，俺马上就要去湾区投身革命了。 |
d*********0
发帖数: 50 | 4 一workstation 要run 32个这杨样exe,128G内存都不够用的。。。。。
【在 w***g 的大作中提到】
: 握抓。意思是这样，但是3G内存太小儿科了。我这边很容易就上50G+内存。最近正在用
: C++重写一批python脚本。本来的设计是C++做计算python做外围处理，结果python耗时
: 比C++还多，服务器快扛不住了。最终可能还是要用机群，但是重写一下单机估计还能
: 再扛个一年半年的。单机转到机群如果想达到2x的性能往往需要5x的机器甚至更多，而
: 且稳定性和维护开销要大打折扣。
: 以前还遇到过matlab读数据。机器有64G内存，矩阵是30G， 硬是读不进来，因为读的
: 过程中需要另外30G做缓存。
|
g*****g
发帖数: 34805 | 5 上32个机器跑就快了。内存随便用。
我们有个team一个视频要做成200个格式， 嫌慢，做个切割算法并行压，扔到几千个结
点上，跑 java。你那东西实在小儿科。
【在 d*********0 的大作中提到】
: 一workstation 要run 32个这杨样exe,128G内存都不够用的。。。。。
|
d****i
发帖数: 4809 | 6 上IBM小型机
【在 w***g 的大作中提到】
: 握抓。意思是这样，但是3G内存太小儿科了。我这边很容易就上50G+内存。最近正在用
: C++重写一批python脚本。本来的设计是C++做计算python做外围处理，结果python耗时
: 比C++还多，服务器快扛不住了。最终可能还是要用机群，但是重写一下单机估计还能
: 再扛个一年半年的。单机转到机群如果想达到2x的性能往往需要5x的机器甚至更多，而
: 且稳定性和维护开销要大打折扣。
: 以前还遇到过matlab读数据。机器有64G内存，矩阵是30G， 硬是读不进来，因为读的
: 过程中需要另外30G做缓存。
|
q*c
发帖数: 9453 | 7 ...当年在亚麻负责编码， 才 200 个机器(就这 VP 都嫌花钱多)， 而且只做 11
个格式， 你们竟然有 200 个！
难怪亚麻的 video 干不过 nflx...钱给我们的不多，格式数量都这么少， 哈哈。
【在 g*****g 的大作中提到】
: 上32个机器跑就快了。内存随便用。
: 我们有个team一个视频要做成200个格式， 嫌慢，做个切割算法并行压，扔到几千个结
: 点上，跑 java。你那东西实在小儿科。
|
q*c
发帖数: 9453 | 8 好汉敌不过人多， 乱拳打死老师傅。
这是技术和社会两个方面反复验证过的绝对真理， 娃哈哈。
【在 d****i 的大作中提到】
: 上IBM小型机
|
g*****g
发帖数: 34805 | 9 亚麻连android都不支持呀(除了kindle)，你想想光android就得多少种格式，我们还支
持一堆乱七八糟的机顶盒，现在4K又出来了。
【在 q*c 的大作中提到】
: ...当年在亚麻负责编码， 才 200 个机器(就这 VP 都嫌花钱多)， 而且只做 11
: 个格式， 你们竟然有 200 个！
: 难怪亚麻的 video 干不过 nflx...钱给我们的不多，格式数量都这么少， 哈哈。
|
g*****g
发帖数: 34805 | 10 C++是传统CPU bound应用的首选，但近年有很多松动。很大原因就是Hadoop和云计算的
出现。
C++的优势是运行快，大多数benchmark比Java快一倍。劣势是开发维护慢，往往慢一倍
都不只。稳定性差，一个core dump搞死整个应用。
云计算的出现，使得很小的公司也能使用很大的计算资源，Hadoop的出现使得机群并行
计算的门槛显著降低。由于整体计算成本的下降，这时候深挖单机潜力不再那么有吸引
力。因为运行时间本身也很重要。大量的公司晚上做计算，白天就要用这个结果，比如
dating网站算match。随着用户数的增加，一个基于cloud的集群计算可以无限扩展，而
基于单机的很快就不行了。在这种环境下，基于Java的应用，因为开发快，稳定，网络
通讯实现简单，基于JVM的并行处理类库多而突出。
在我看来，C++在应用层的空间是越来越小，越来越成为一个系统层的语言，跟C竞争。 |
|
|
q*c
发帖数: 9453 | 11 这帮烂人开发了 android app 结果不 release! 我偷偷搞了源码想自己编译一个， 结
果看看那环境设置的费劲...， 算了，，，
结果只好用 flash , hehe.
【在 g*****g 的大作中提到】
: 亚麻连android都不支持呀(除了kindle)，你想想光android就得多少种格式，我们还支
: 持一堆乱七八糟的机顶盒，现在4K又出来了。
|
d********f
发帖数: 43471 | 12 行了，搞java的就别乱吹了行么。java是不会core dump,就是nm的内存全占满了，还挂
在那。debug都不知道怎么开始debug.死活都不知道
【在 g*****g 的大作中提到】
: C++是传统CPU bound应用的首选，但近年有很多松动。很大原因就是Hadoop和云计算的
: 出现。
: C++的优势是运行快，大多数benchmark比Java快一倍。劣势是开发维护慢，往往慢一倍
: 都不只。稳定性差，一个core dump搞死整个应用。
: 云计算的出现，使得很小的公司也能使用很大的计算资源，Hadoop的出现使得机群并行
: 计算的门槛显著降低。由于整体计算成本的下降，这时候深挖单机潜力不再那么有吸引
: 力。因为运行时间本身也很重要。大量的公司晚上做计算，白天就要用这个结果，比如
: dating网站算match。随着用户数的增加，一个基于cloud的集群计算可以无限扩展，而
: 基于单机的很快就不行了。在这种环境下，基于Java的应用，因为开发快，稳定，网络
: 通讯实现简单，基于JVM的并行处理类库多而突出。
|
g*****g
发帖数: 34805 | 13 你一个workstation还要跑32个进程，那可不内存全占满了。分到32个机器上，
内存不就多的是。云计算的特点就是32个节点跑1小时和1个节点跑32小时成本差不太多
，是你要哪个？
至于java挂了你都不知道怎么debug，那真是人笨怪刀钝了。一个kill -3能看到所有线
程情况。JMX现成的built-in监控工具，跟gdb比，那就是老牛跟拖拉机的区别。
【在 d********f 的大作中提到】
: 行了，搞java的就别乱吹了行么。java是不会core dump,就是nm的内存全占满了，还挂
: 在那。debug都不知道怎么开始debug.死活都不知道
|
d****i
发帖数: 4809 | 14 goodbug评价C++还算比较客观的，毕竟是见多识广的架构师。但是同样在云后端，如果
牵涉到的不仅仅是biz logic，而是很多科学计算的话，C++有巨大优势，再加上OpenMP
, OpenMPI并行库等等如虎添翼，和Java的biz logic正好绝配。C++的定位其实应该是
在系统层和C配合，在应用层和Java配合。
【在 g*****g 的大作中提到】
: C++是传统CPU bound应用的首选，但近年有很多松动。很大原因就是Hadoop和云计算的
: 出现。
: C++的优势是运行快，大多数benchmark比Java快一倍。劣势是开发维护慢，往往慢一倍
: 都不只。稳定性差，一个core dump搞死整个应用。
: 云计算的出现，使得很小的公司也能使用很大的计算资源，Hadoop的出现使得机群并行
: 计算的门槛显著降低。由于整体计算成本的下降，这时候深挖单机潜力不再那么有吸引
: 力。因为运行时间本身也很重要。大量的公司晚上做计算，白天就要用这个结果，比如
: dating网站算match。随着用户数的增加，一个基于cloud的集群计算可以无限扩展，而
: 基于单机的很快就不行了。在这种环境下，基于Java的应用，因为开发快，稳定，网络
: 通讯实现简单，基于JVM的并行处理类库多而突出。
|
z****e
发帖数: 54598 | 15 你也就是插科打诨在行
一深入就露馅了
【在 d********f 的大作中提到】
: 行了，搞java的就别乱吹了行么。java是不会core dump,就是nm的内存全占满了，还挂
: 在那。debug都不知道怎么开始debug.死活都不知道
|
g*****g
发帖数: 34805 | 16 你说的我不反对，类库是第一生产力。有啥没啥大多是历史原因，要补课也没那么容易。
但无论如何，像楼主那样挖掘单机潜力，内存当宝贝，不会是未来的方向。
OpenMP
【在 d****i 的大作中提到】
: goodbug评价C++还算比较客观的，毕竟是见多识广的架构师。但是同样在云后端，如果
: 牵涉到的不仅仅是biz logic，而是很多科学计算的话，C++有巨大优势，再加上OpenMP
: , OpenMPI并行库等等如虎添翼，和Java的biz logic正好绝配。C++的定位其实应该是
: 在系统层和C配合，在应用层和Java配合。
|
n****1
发帖数: 1136 | 17 C++有点高不成低不就的感觉，想做OOP又不想用GC， 结果成了四不像，啥都不擅长。
现在C++的领地也就游戏这块了，因为游戏很适合OO且对内存大小敏感。其他被C/
python/java瓜分地差不多了， 需要OO的地方人会选Java/python，不需要的时候就选C
，我认识做科学计算的大多都是C/python组合。 要是微软不捧C++，丫早完蛋了。
C++的开源界地位远不如C， 因为底层的library和kernel api都是C接口的，而C++的
name mangle极大得阻碍了C++写的库被其他语言利用。 |
n****1
发帖数: 1136 | 18 在那么注重性能的领域， 根本就不该用OOP来做事。
C程序员风格都是单刀直入一针见血， C++还要捣鼓一大堆object, method dynamic
dispatch, 损耗的效率不见得比GC少。C++嘲笑java就是99步笑100步。 |
d****i
发帖数: 4809 | 19 这句话不对，应当是 C++在系统层的地位远不如C。开源界的话，lib的数量两个差不多。
>>C++的开源界地位远不如C |
z****e
发帖数: 54598 | 20 i really dont think so
u must be joking
【在 d****i 的大作中提到】
: 这句话不对，应当是 C++在系统层的地位远不如C。开源界的话，lib的数量两个差不多。
: >>C++的开源界地位远不如C
|
|
|
d****i
发帖数: 4809 | 21 joking啥？自己去看看github的数量不就行了。
【在 z****e 的大作中提到】
: i really dont think so
: u must be joking
|
z****e
发帖数: 54598 | 22 github is just a repository of source version control
of course u could get some free libs in there
but most of lib providers have their own website
and their own version control things
in a nutshell github is not a place for providing third party libs
just a place for keeping or publishing your code
it could be any type of code
【在 d****i 的大作中提到】
: joking啥？自己去看看github的数量不就行了。
|
z****e
发帖数: 54598 | 23 absolutely true
选C
【在 n****1 的大作中提到】
: C++有点高不成低不就的感觉，想做OOP又不想用GC， 结果成了四不像，啥都不擅长。
: 现在C++的领地也就游戏这块了，因为游戏很适合OO且对内存大小敏感。其他被C/
: python/java瓜分地差不多了， 需要OO的地方人会选Java/python，不需要的时候就选C
: ，我认识做科学计算的大多都是C/python组合。 要是微软不捧C++，丫早完蛋了。
: C++的开源界地位远不如C， 因为底层的library和kernel api都是C接口的，而C++的
: name mangle极大得阻碍了C++写的库被其他语言利用。
|
z****e
发帖数: 54598 | 24 right
【在 n****1 的大作中提到】
: 在那么注重性能的领域， 根本就不该用OOP来做事。
: C程序员风格都是单刀直入一针见血， C++还要捣鼓一大堆object, method dynamic
: dispatch, 损耗的效率不见得比GC少。C++嘲笑java就是99步笑100步。
|
j****x
发帖数: 943 | 25 在fortran和C眼里，C++ 屁也不是。除非是把C++当C使。 |
z****e
发帖数: 54598 | 26 re
【在 j****x 的大作中提到】
: 在fortran和C眼里，C++ 屁也不是。除非是把C++当C使。
|
b*******s
发帖数: 5216 | 27 单机的确不是方向，不过你有没有考虑过，如果亚麻也不注重底层优化，一台机器能做
的事情用32台来做，导致你们这样的用户这方面成本上一个数量级的情况？
易。
【在 g*****g 的大作中提到】
: 你说的我不反对，类库是第一生产力。有啥没啥大多是历史原因，要补课也没那么容易。
: 但无论如何，像楼主那样挖掘单机潜力，内存当宝贝，不会是未来的方向。
:
: OpenMP
|
T*******e
发帖数: 18 | 28 精彩！
鼓掌，收藏，转发。
【在 g*****g 的大作中提到】
: C++是传统CPU bound应用的首选，但近年有很多松动。很大原因就是Hadoop和云计算的
: 出现。
: C++的优势是运行快，大多数benchmark比Java快一倍。劣势是开发维护慢，往往慢一倍
: 都不只。稳定性差，一个core dump搞死整个应用。
: 云计算的出现，使得很小的公司也能使用很大的计算资源，Hadoop的出现使得机群并行
: 计算的门槛显著降低。由于整体计算成本的下降，这时候深挖单机潜力不再那么有吸引
: 力。因为运行时间本身也很重要。大量的公司晚上做计算，白天就要用这个结果，比如
: dating网站算match。随着用户数的增加，一个基于cloud的集群计算可以无限扩展，而
: 基于单机的很快就不行了。在这种环境下，基于Java的应用，因为开发快，稳定，网络
: 通讯实现简单，基于JVM的并行处理类库多而突出。
|
b*******s
发帖数: 5216 | 29 从c++11开始，不太鼓励oo过度了，基本靠模板，效率是不错的
现在c++社区是精分状态
【在 n****1 的大作中提到】
: 在那么注重性能的领域， 根本就不该用OOP来做事。
: C程序员风格都是单刀直入一针见血， C++还要捣鼓一大堆object, method dynamic
: dispatch, 损耗的效率不见得比GC少。C++嘲笑java就是99步笑100步。
|
z****e
发帖数: 54598 | 30 people's eyes are bright
【在 b*******s 的大作中提到】
: 从c++11开始，不太鼓励oo过度了，基本靠模板，效率是不错的
: 现在c++社区是精分状态
|
|
|
b*******s
发帖数: 5216 | 31 对啊，金融都用c++，基本没有c或者java的
【在 z****e 的大作中提到】
: people's eyes are bright
|
z****e
发帖数: 54598 | 32 that is why they need ur money to safe them from bankruptcy
aint u feel angry about this?
【在 b*******s 的大作中提到】
: 对啊，金融都用c++，基本没有c或者java的
|
b*******s
发帖数: 5216 | 33 没有啊，正在考虑转金融，前些日子收到个电话，一家以食物好出名的做高频的
事实上用java做高频，是没有任何可行性的，而c实际上是unix哲学的产物，还是有其
局限的
【在 z****e 的大作中提到】
: that is why they need ur money to safe them from bankruptcy
: aint u feel angry about this?
|
n****1
发帖数: 1136 | 34 高频交易对性能要求是高， 可为啥不用C呢？ 是不是被windows/visual studio绑死了
?
【在 b*******s 的大作中提到】
: 对啊，金融都用c++，基本没有c或者java的
|
z****e
发帖数: 54598 | 35 dont u agree web companies will pay u more?
【在 b*******s 的大作中提到】
: 没有啊，正在考虑转金融，前些日子收到个电话，一家以食物好出名的做高频的
: 事实上用java做高频，是没有任何可行性的，而c实际上是unix哲学的产物，还是有其
: 局限的
|
m********5
发帖数: 17667 | 36 你这个完全小意思, 也就科研单位计较
在我们公司, 能买机器解决的问题绝对就不是问题
与其花钱请人维护C++代码,我不如花钱买硬件
给你300G内存, 1000个核够不? 比你2年工资便宜吧!
【在 d*********0 的大作中提到】
: 我们每个程序都要run 四五个小时，
: 每个程序都要3G左右内存，
: 一样的工作量， 这速度，这内存的控制，岂是其他语言可以胜任的？
|
g*****g
发帖数: 34805 | 37 That's called system level programming. C++ doesn't compete with Java in
that area. Someone has to do system programming, true, but you don't need as
many people to do it. What I am saying is C++ is diminishing in application
development.
【在 b*******s 的大作中提到】
: 单机的确不是方向，不过你有没有考虑过，如果亚麻也不注重底层优化，一台机器能做
: 的事情用32台来做，导致你们这样的用户这方面成本上一个数量级的情况？
:
: 易。
|
m********5
发帖数: 17667 | 38 开发如果慢一倍, 硬件在这个期间又降价不少了, hoho
反正在优化上投入过多精力确实比较蠢
游戏除外,因为它需要在一个相对固定的硬件平台(console基本4年才一换,还要兼容老
机器)上达到最佳的效果
【在 g*****g 的大作中提到】
: C++是传统CPU bound应用的首选，但近年有很多松动。很大原因就是Hadoop和云计算的
: 出现。
: C++的优势是运行快，大多数benchmark比Java快一倍。劣势是开发维护慢，往往慢一倍
: 都不只。稳定性差，一个core dump搞死整个应用。
: 云计算的出现，使得很小的公司也能使用很大的计算资源，Hadoop的出现使得机群并行
: 计算的门槛显著降低。由于整体计算成本的下降，这时候深挖单机潜力不再那么有吸引
: 力。因为运行时间本身也很重要。大量的公司晚上做计算，白天就要用这个结果，比如
: dating网站算match。随着用户数的增加，一个基于cloud的集群计算可以无限扩展，而
: 基于单机的很快就不行了。在这种环境下，基于Java的应用，因为开发快，稳定，网络
: 通讯实现简单，基于JVM的并行处理类库多而突出。
|
n****1
发帖数: 1136 | 39 在我看来C++从语言角度超过Ｃ的地方：
1. 有namespace
2. 有template
template用好了挺神的, 但不容易debug, 所以c++确实适合trader做自己的个人项目，
能够扬长避短。
【在 b*******s 的大作中提到】
: 没有啊，正在考虑转金融，前些日子收到个电话，一家以食物好出名的做高频的
: 事实上用java做高频，是没有任何可行性的，而c实际上是unix哲学的产物，还是有其
: 局限的
|
b*******s
发帖数: 5216 | 40 高频的服务器据我所知基本是linux的，只有trader的控制台是windows的
有些也是用mono来跑的了
其实现在有meta programming了，c++效率可以做到和c差不多了
线程库，算法库都很强，包括比较流行的非阻塞同步等都有开源库可以参考
而且boost演化很快，是一个很好的资源，可以吸取其技术
另外在类型检查等方面，c++编译器要严格一点
c++最大的优点是两个，一个是性能很好，而且实现高性能比c还要方便
另一个是能实现大多数的paradigm，在设计方面具有很强的表现力
【在 n****1 的大作中提到】
: 高频交易对性能要求是高， 可为啥不用C呢？ 是不是被windows/visual studio绑死了
: ?
|
|
|
b*******s
发帖数: 5216 | 41 差不多吧，底薪互联网略高，但金融好年景奖金不少，而且可以有比较稳定的职业发展
因为金融的知识相对变化要慢一点
【在 z****e 的大作中提到】
: dont u agree web companies will pay u more?
|
n****1
发帖数: 1136 | 42 我其实很想知道从你的角度， GC对实时项目影响究竟有多大？
有很多C++程序员喜欢用ref count来管理内存， 可我觉得这个只不过是把运算分散开
来， 而实际开销差不多，甚至ref count更没效率。 你觉得呢？
我认为java实时性差更多来源于对portability的变态追求， 导致jvm不能利用操作系
统上最先进的api, 你觉得呢？
【在 b*******s 的大作中提到】
: 高频的服务器据我所知基本是linux的，只有trader的控制台是windows的
: 有些也是用mono来跑的了
: 其实现在有meta programming了，c++效率可以做到和c差不多了
: 线程库，算法库都很强，包括比较流行的非阻塞同步等都有开源库可以参考
: 而且boost演化很快，是一个很好的资源，可以吸取其技术
: 另外在类型检查等方面，c++编译器要严格一点
: c++最大的优点是两个，一个是性能很好，而且实现高性能比c还要方便
: 另一个是能实现大多数的paradigm，在设计方面具有很强的表现力
|
m********5
发帖数: 17667 | 43 C++11有很多良好特性,显著加快了生产速度
所以最近我们组用C++的比率又增加了
C在关键处当手术刀用不错,要做整个项目有点...
况且现在做性能优化的已经在很多地方直接用CUDA, OpenCL之类的东西了; 用C的大多
数在维护以前的DSP. 听说C++也能用在DSP上, 但是我还没见过真在产品中这么用的.以
前还有人用VHDL现在看来意义不是非常大
硬件的发展大大超出了程序优化速度, 以前的很多工作现在看起来根本没有意义, 所以
很久没再招过C++/C的组员
【在 n****1 的大作中提到】
: 在我看来C++从语言角度超过Ｃ的地方：
: 1. 有namespace
: 2. 有template
: template用好了挺神的, 但不容易debug, 所以c++确实适合trader做自己的个人项目，
: 能够扬长避短。
|
z****e
发帖数: 54598 | 44 u r absolutely right
ref count is a stupid way to manage the memory
since it could easily cause memory leak
and jvm itself is changing and take a look at javafx
which is using directx & opengl to accelerate its running speed
【在 n****1 的大作中提到】
: 我其实很想知道从你的角度， GC对实时项目影响究竟有多大？
: 有很多C++程序员喜欢用ref count来管理内存， 可我觉得这个只不过是把运算分散开
: 来， 而实际开销差不多，甚至ref count更没效率。 你觉得呢？
: 我认为java实时性差更多来源于对portability的变态追求， 导致jvm不能利用操作系
: 统上最先进的api, 你觉得呢？
|
b*******s
发帖数: 5216 | 45 应用层的我觉得gc很好，其实c++的设计哲学就是非基础性的东西不进入语言特性
gc是比较高层的东西了，放到c++这样的语言里不合适
其实由于这个哲学，也长期导致c++的库比较贫乏，大家分别造轮子
不过现在社区也意识到了这个问题，st是稳定库，保证可以跨平台编译
boost是新特性比较多的库，保证试验新特性，大家都觉得好就进stl
gc主要是隐藏内存管理细节，在jvm这样不存在平台碎片化的情况下可以做优化
c++程序员比较习惯的是轻量化管理，ref count式的现在有实现进了标准库
而内存自己管理，恰恰是提高性能的主要手段，比如针对cache的优化，
经过优化的c++程序，在处理计算和内存操作较多的任务时
绝对不会像大多泛泛的benchmark一样只比java快一倍，而是要有数量级的差别
ref count的典型实现是shared_ptr和weak_ptr，其实其只是控制了其生存周期
overhead是非常低的，你可以读读源代码，仅仅是少量的运算
java本身就比native code多一层，而且是很重的一层，先天上你jvm能做到的native都
能做到，而你在jvm上还有一层，所以java性能超过c++ native code原理上是不成立的
【在 n****1 的大作中提到】
: 我其实很想知道从你的角度， GC对实时项目影响究竟有多大？
: 有很多C++程序员喜欢用ref count来管理内存， 可我觉得这个只不过是把运算分散开
: 来， 而实际开销差不多，甚至ref count更没效率。 你觉得呢？
: 我认为java实时性差更多来源于对portability的变态追求， 导致jvm不能利用操作系
: 统上最先进的api, 你觉得呢？
|
z****e
发帖数: 54598 | 46 "比较稳定的职业发展"
i dont buy this statement
but if u believe this is the truth then go for it
good luck
【在 b*******s 的大作中提到】
: 差不多吧，底薪互联网略高，但金融好年景奖金不少，而且可以有比较稳定的职业发展
: 因为金融的知识相对变化要慢一点
|
n****1
发帖数: 1136 | 47 We are discuss C&C++ here, jvm is just the wrong answer for high freq
trading.
【在 z****e 的大作中提到】
: u r absolutely right
: ref count is a stupid way to manage the memory
: since it could easily cause memory leak
: and jvm itself is changing and take a look at javafx
: which is using directx & opengl to accelerate its running speed
|
z****e
发帖数: 54598 | 48 but u r comparing gc mechanism in both languages
【在 n****1 的大作中提到】
: We are discuss C&C++ here, jvm is just the wrong answer for high freq
: trading.
|
b*******s
发帖数: 5216 | 49 dsp一般就是c，我以前做过德仪的omap（？）就是dsp ＋ arm的那个
c++适合底层基础设施，能不能再次向上，要看新标准
现在新标准还是在不停发布，不过如果是00年代有这个频率就好了
【在 m********5 的大作中提到】
: C++11有很多良好特性,显著加快了生产速度
: 所以最近我们组用C++的比率又增加了
: C在关键处当手术刀用不错,要做整个项目有点...
: 况且现在做性能优化的已经在很多地方直接用CUDA, OpenCL之类的东西了; 用C的大多
: 数在维护以前的DSP. 听说C++也能用在DSP上, 但是我还没见过真在产品中这么用的.以
: 前还有人用VHDL现在看来意义不是非常大
: 硬件的发展大大超出了程序优化速度, 以前的很多工作现在看起来根本没有意义, 所以
: 很久没再招过C++/C的组员
|
m********5
发帖数: 17667 | 50 看项目,需要测试的
GC对我们有些部件影响很大, C++现在大部分smart pointer之类安全措施都基于ref
counter, 这个也可以centralize, 我觉得不论是生产还是运行的效率都不错, 没你说
得那么不堪.
而且C++也快有自己的GC了
你们很多人黑C++其实是基于以前很原始的C++, C++的特性更改不知道多少次了, 另外
boost里面新东西更多
我不是说C++万能, 但是C++真没你们说的那么不堪
性能优化,对大部分项目用C和汇编甚至VHDL至多能在一年内提升个10%, 但是硬件的提
升让你这个工作显得微不足道, 所以openCV也转向C++了
这是因为C++的很多库已经有人在底层做过优化了, 进一步优化意义不大. C++的问题是
项目管理困难, 东西做大了,要重写,那些什么模板,宏,得把项目审核的人看晕过去, 因
此我们自己只用C++做小部件.
至于为什么大部分做优化的人倾向于C, 我觉得是因为和别的语言接口,通常只能用到C
特性, 比如java, python, ruby的API通常都是C的.
【在 n****1 的大作中提到】
: 我其实很想知道从你的角度， GC对实时项目影响究竟有多大？
: 有很多C++程序员喜欢用ref count来管理内存， 可我觉得这个只不过是把运算分散开
: 来， 而实际开销差不多，甚至ref count更没效率。 你觉得呢？
: 我认为java实时性差更多来源于对portability的变态追求， 导致jvm不能利用操作系
: 统上最先进的api, 你觉得呢？
|
|
|
b*******s
发帖数: 5216 | 51 我不是说语言，而是说逐步做策略，甚至自己做
这个我有很多先例可以参考
【在 z****e 的大作中提到】
: "比较稳定的职业发展"
: i dont buy this statement
: but if u believe this is the truth then go for it
: good luck
|
z****e
发帖数: 54598 | 52 ok
【在 b*******s 的大作中提到】
: 我不是说语言，而是说逐步做策略，甚至自己做
: 这个我有很多先例可以参考
|
m********5
发帖数: 17667 | 53 看硬件发展和jvm的发展
据说有些jvm是可以实时性很高的, 至少广告这么说
当然我自己没用过
不过我们这里写jvm的java大牛对这些嗤之以鼻, 说都是小公司骗人的玩意儿,基本上不
可能
【在 n****1 的大作中提到】
: We are discuss C&C++ here, jvm is just the wrong answer for high freq
: trading.
|
b*******s
发帖数: 5216 | 54 c++现在正确性严重依赖单元测试，我们现在的要求是每个接口的函数至少都要有单元
测试
而非接口的至少要常用逻辑分支全覆盖
然后看正确性只要跑一下，几千个用例也就是不到1秒的事情
review时只要审核接口就好了
【在 m********5 的大作中提到】
: 看项目,需要测试的
: GC对我们有些部件影响很大, C++现在大部分smart pointer之类安全措施都基于ref
: counter, 这个也可以centralize, 我觉得不论是生产还是运行的效率都不错, 没你说
: 得那么不堪.
: 而且C++也快有自己的GC了
: 你们很多人黑C++其实是基于以前很原始的C++, C++的特性更改不知道多少次了, 另外
: boost里面新东西更多
: 我不是说C++万能, 但是C++真没你们说的那么不堪
: 性能优化,对大部分项目用C和汇编甚至VHDL至多能在一年内提升个10%, 但是硬件的提
: 升让你这个工作显得微不足道, 所以openCV也转向C++了
|
b*******s
发帖数: 5216 | 55 宏我们现在是禁止使用的，副作用大
【在 m********5 的大作中提到】
: 看项目,需要测试的
: GC对我们有些部件影响很大, C++现在大部分smart pointer之类安全措施都基于ref
: counter, 这个也可以centralize, 我觉得不论是生产还是运行的效率都不错, 没你说
: 得那么不堪.
: 而且C++也快有自己的GC了
: 你们很多人黑C++其实是基于以前很原始的C++, C++的特性更改不知道多少次了, 另外
: boost里面新东西更多
: 我不是说C++万能, 但是C++真没你们说的那么不堪
: 性能优化,对大部分项目用C和汇编甚至VHDL至多能在一年内提升个10%, 但是硬件的提
: 升让你这个工作显得微不足道, 所以openCV也转向C++了
|
n****1
发帖数: 1136 | 56 我是觉得C++应该尽量用stack allocation或者vector之类的容器， 实在要自己new内
存就找个gc类库，这样能减少内存碎片， 也比滥用ref count好。
OOP离不开heap, 所以java无论啥子都往heap里面放，必然是性能杀手。 C++如果能能
摆正态度，别老东追求高大全的话， 还是能有一番作为的。
【在 m********5 的大作中提到】
: 看项目,需要测试的
: GC对我们有些部件影响很大, C++现在大部分smart pointer之类安全措施都基于ref
: counter, 这个也可以centralize, 我觉得不论是生产还是运行的效率都不错, 没你说
: 得那么不堪.
: 而且C++也快有自己的GC了
: 你们很多人黑C++其实是基于以前很原始的C++, C++的特性更改不知道多少次了, 另外
: boost里面新东西更多
: 我不是说C++万能, 但是C++真没你们说的那么不堪
: 性能优化,对大部分项目用C和汇编甚至VHDL至多能在一年内提升个10%, 但是硬件的提
: 升让你这个工作显得微不足道, 所以openCV也转向C++了
|
b*******s
发帖数: 5216 | 57 现在基本都用容器了，c++的容器，iterator和algorithm的协作设计得非常好
使用简单，效率很高，这点java的generic在java6时至少还是一坨屎一样的东西
不过java程序一般不用算法，还好
【在 n****1 的大作中提到】
: 我是觉得C++应该尽量用stack allocation或者vector之类的容器， 实在要自己new内
: 存就找个gc类库，这样能减少内存碎片， 也比滥用ref count好。
: OOP离不开heap, 所以java无论啥子都往heap里面放，必然是性能杀手。 C++如果能能
: 摆正态度，别老东追求高大全的话， 还是能有一番作为的。
|
n****1
发帖数: 1136 | 58 我希望看到C++能够做一次减法， 而不是老做加法。 就像python 3这样壮士断腕， 虽
然会很痛苦， 但对长远有好处。
【在 b*******s 的大作中提到】
: 现在基本都用容器了，c++的容器，iterator和algorithm的协作设计得非常好
: 使用简单，效率很高，这点java的generic在java6时至少还是一坨屎一样的东西
: 不过java程序一般不用算法，还好
|
m********5
发帖数: 17667 | 59 对于小部件我们也是依赖单元测试, 项目一旦大起来, 如果只审核接口, code发展个2,
3年就基本不可维护了, 我们以前很多纯C++的项目都用别的语言重写了
【在 b*******s 的大作中提到】
: c++现在正确性严重依赖单元测试，我们现在的要求是每个接口的函数至少都要有单元
: 测试
: 而非接口的至少要常用逻辑分支全覆盖
: 然后看正确性只要跑一下，几千个用例也就是不到1秒的事情
: review时只要审核接口就好了
|
b*******s
发帖数: 5216 | 60 ref count不差，看实现者水平，从boost时的shared_ptr就是一个非常优美的设计
【在 n****1 的大作中提到】
: 我是觉得C++应该尽量用stack allocation或者vector之类的容器， 实在要自己new内
: 存就找个gc类库，这样能减少内存碎片， 也比滥用ref count好。
: OOP离不开heap, 所以java无论啥子都往heap里面放，必然是性能杀手。 C++如果能能
: 摆正态度，别老东追求高大全的话， 还是能有一番作为的。
|
|
|
b*******s
发帖数: 5216 | 61 c++不做减法，靠精神分裂来实现
现在所谓c++ coding style起码有三四种，各自取c++的一部分特性子集
【在 n****1 的大作中提到】
: 我希望看到C++能够做一次减法， 而不是老做加法。 就像python 3这样壮士断腕， 虽
: 然会很痛苦， 但对长远有好处。
|
b*******s
发帖数: 5216 | 62 我们现在非性能敏感的都是python
2,
【在 m********5 的大作中提到】
: 对于小部件我们也是依赖单元测试, 项目一旦大起来, 如果只审核接口, code发展个2,
: 3年就基本不可维护了, 我们以前很多纯C++的项目都用别的语言重写了
|
z****e
发帖数: 54598 | 63 ref count should be 禁止使用ed，副作用大
【在 n****1 的大作中提到】
: 我是觉得C++应该尽量用stack allocation或者vector之类的容器， 实在要自己new内
: 存就找个gc类库，这样能减少内存碎片， 也比滥用ref count好。
: OOP离不开heap, 所以java无论啥子都往heap里面放，必然是性能杀手。 C++如果能能
: 摆正态度，别老东追求高大全的话， 还是能有一番作为的。
|
m********5
发帖数: 17667 | 64 呵呵是的, 其实现在boost的很多东西, 很多老C++程序员已经根本看不懂了; boost的
很多内容在未来都会放到标准里面, 大家拭目以待
【在 b*******s 的大作中提到】
: 现在基本都用容器了，c++的容器，iterator和algorithm的协作设计得非常好
: 使用简单，效率很高，这点java的generic在java6时至少还是一坨屎一样的东西
: 不过java程序一般不用算法，还好
|
b*******s
发帖数: 5216 | 65 soa啊，另外我们现在基本还是秉承unix哲学，一个部件只实现一个功能，杜绝side
effects
2,
【在 m********5 的大作中提到】
: 对于小部件我们也是依赖单元测试, 项目一旦大起来, 如果只审核接口, code发展个2,
: 3年就基本不可维护了, 我们以前很多纯C++的项目都用别的语言重写了
|
L***s
发帖数: 1148 | 66 “壮士断腕”那是perl6吧，已经不叫perl了，lol。python3000当年饼画得很大，结果
现在只是小修小补的python3，说好的要去除GIL呢？2to3都五年了，绝大部分公司都不
肯动，因为“升级”的收益跟成本比起来可以忽略不计。
【在 n****1 的大作中提到】
: 我希望看到C++能够做一次减法， 而不是老做加法。 就像python 3这样壮士断腕， 虽
: 然会很痛苦， 但对长远有好处。
|
b*******s
发帖数: 5216 | 67 boost就是stl的社区试验库
【在 m********5 的大作中提到】
: 呵呵是的, 其实现在boost的很多东西, 很多老C++程序员已经根本看不懂了; boost的
: 很多内容在未来都会放到标准里面, 大家拭目以待
|
m********5
发帖数: 17667 | 68 python现在搞得跟屎,subversion的bug fix还能复辟呢
搞得我们现在已经不敢做任何版本升级了, 更别说什么2to3了
【在 L***s 的大作中提到】
: “壮士断腕”那是perl6吧，已经不叫perl了，lol。python3000当年饼画得很大，结果
: 现在只是小修小补的python3，说好的要去除GIL呢？2to3都五年了，绝大部分公司都不
: 肯动，因为“升级”的收益跟成本比起来可以忽略不计。
|
z****e
发帖数: 54598 | 69 actually this is not soa
there is not real service here
component is just a module
basic oo and encapsulation here
small modules
not service that big
【在 b*******s 的大作中提到】
: soa啊，另外我们现在基本还是秉承unix哲学，一个部件只实现一个功能，杜绝side
: effects
:
: 2,
|
b*******s
发帖数: 5216 | 70 另外c++的优化，不是针对api这个层次的
【在 n****1 的大作中提到】
: 我其实很想知道从你的角度， GC对实时项目影响究竟有多大？
: 有很多C++程序员喜欢用ref count来管理内存， 可我觉得这个只不过是把运算分散开
: 来， 而实际开销差不多，甚至ref count更没效率。 你觉得呢？
: 我认为java实时性差更多来源于对portability的变态追求， 导致jvm不能利用操作系
: 统上最先进的api, 你觉得呢？
|
|
|
b*******s
发帖数: 5216 | 71 我们产品是soa的，都是restful的
【在 z****e 的大作中提到】
: actually this is not soa
: there is not real service here
: component is just a module
: basic oo and encapsulation here
: small modules
: not service that big
|
w***g
发帖数: 5958 | 72 你的codec是java写的？java怕只是glue吧。你去看看源码，怕是汇编语言都还有吧。
【在 g*****g 的大作中提到】
: 上32个机器跑就快了。内存随便用。
: 我们有个team一个视频要做成200个格式， 嫌慢，做个切割算法并行压，扔到几千个结
: 点上，跑 java。你那东西实在小儿科。
|
L***s
发帖数: 1148 | 73 Python表示很无辜：发行这么严谨，每个小版本都有3-4轮Beta和两轮RC。Beta/RC时你
们不做小白鼠、不report bugs，出问题怎么能老赖我头上。
【在 m********5 的大作中提到】
: python现在搞得跟屎,subversion的bug fix还能复辟呢
: 搞得我们现在已经不敢做任何版本升级了, 更别说什么2to3了
|
z****e
发帖数: 54598 | 74 soa is for ur clients
more likely
u dont use web service to call other component in the system
do u?
【在 b*******s 的大作中提到】
: 我们产品是soa的，都是restful的
|
n****1
发帖数: 1136 | 75 GIL这个问题不只是python的问题, 现在所有脚步语言， 包括node.js/dart，都是单线
程运行的。
migration是需要时间的，以后语言新特性都不会在python2里出现， 包括native
async， 这样新用户就都会直接用3了。SOA也能使migration更简单， 新代码直接用
python3写就可以了。
【在 L***s 的大作中提到】
: “壮士断腕”那是perl6吧，已经不叫perl了，lol。python3000当年饼画得很大，结果
: 现在只是小修小补的python3，说好的要去除GIL呢？2to3都五年了，绝大部分公司都不
: 肯动，因为“升级”的收益跟成本比起来可以忽略不计。
|
b*******s
发帖数: 5216 | 76 我们的产品，只提供了很少的用户管理界面，和互联网企业还是不一样
基本是我们的应用产品调自己平台的service
【在 z****e 的大作中提到】
: soa is for ur clients
: more likely
: u dont use web service to call other component in the system
: do u?
|
g*********e
发帖数: 14401 | 77
我们每个程序要8g内存，run几分钟到几小时。
每个季度runtime上的目标是快2%
【在 d*********0 的大作中提到】
: 我们每个程序都要run 四五个小时，
: 每个程序都要3G左右内存，
: 一样的工作量， 这速度，这内存的控制，岂是其他语言可以胜任的？
|
g*********e
发帖数: 14401 | 78
软件是卖给客户的，客户可没有集群机。必须在台式机上完成这些计算
【在 g*****g 的大作中提到】
: 上32个机器跑就快了。内存随便用。
: 我们有个team一个视频要做成200个格式， 嫌慢，做个切割算法并行压，扔到几千个结
: 点上，跑 java。你那东西实在小儿科。
|
g*********e
发帖数: 14401 | 79
很多工作是sequential的，c relay on b rely on a.
没法云计算分布式，机器再多也没用。
【在 g*****g 的大作中提到】
: 你一个workstation还要跑32个进程，那可不内存全占满了。分到32个机器上，
: 内存不就多的是。云计算的特点就是32个节点跑1小时和1个节点跑32小时成本差不太多
: ，是你要哪个？
: 至于java挂了你都不知道怎么debug，那真是人笨怪刀钝了。一个kill -3能看到所有线
: 程情况。JMX现成的built-in监控工具，跟gdb比，那就是老牛跟拖拉机的区别。
|
m********5
发帖数: 17667 | 80 如果是我, 我根本不卖软件, 只卖服务
在云端跑, 客户按时间交钱
客户成本也降下来, 你们人力成本, 维护成本也降下来
【在 g*********e 的大作中提到】
:
: 很多工作是sequential的，c relay on b rely on a.
: 没法云计算分布式，机器再多也没用。
|
|
|
c****3
发帖数: 10787 | 81 C++曾经比较适合做Windows里的图形界面程序，现在被C#取代了。
在Linux下运行，同时跨平台带图形界面的客户端软件现在还在拿C++写，象用QT之类的
库。 |
g*****g
发帖数: 34805 | 82 看过了，java源码比C++多，C++文件大多外部来的。很多java文件肯定是做encoding的
，一堆的bit操作。我怀疑他们需要的地方重新用java实现。
【在 w***g 的大作中提到】
: 你的codec是java写的？java怕只是glue吧。你去看看源码，怕是汇编语言都还有吧。
|
m********5
发帖数: 17667 | 83 LoL 如果全部是sequential的job你也没法怎么优化
除非算法上有较大改进, 和用什么语言关系不大的
【在 g*********e 的大作中提到】
:
: 很多工作是sequential的，c relay on b rely on a.
: 没法云计算分布式，机器再多也没用。
|
g*****g
发帖数: 34805 | 84 Then maybe you should provide SaaS instead. It's a better model than one
time license fee.
【在 g*********e 的大作中提到】
:
: 很多工作是sequential的，c relay on b rely on a.
: 没法云计算分布式，机器再多也没用。
|
g*****g
发帖数: 34805 | 85 英雄所见略同呀，这是典型的SaaS服务。客户省心，多交钱，你们fix bug也快。
【在 m********5 的大作中提到】
: 如果是我, 我根本不卖软件, 只卖服务
: 在云端跑, 客户按时间交钱
: 客户成本也降下来, 你们人力成本, 维护成本也降下来
|
g*********e
发帖数: 14401 | 86
我这是对应鼓吹并行计算的人的贴，跟语言没关
当然，局部的并行还是可以的
除此之外就是算法的tune 调参数
【在 m********5 的大作中提到】
: LoL 如果全部是sequential的job你也没法怎么优化
: 除非算法上有较大改进, 和用什么语言关系不大的
|
h*******u
发帖数: 15326 | 87 Java spring 是我见过最2b的玩意儿
nasa的一个鸟毛重量级应用是这玩意儿做的，配置一个月都搞不定，哈哈 |
m********5
发帖数: 17667 | 88 人家的意思是其他语言比C++能更方便地实现并行管理
你突然冒出来一个并行不是万能的, 但是这个和C++/Java有什么关系?!
不能并行优化的程序你用C++在单机上也快不了多少
与其花心思优化,不如直接升级硬件, 或者花心思改变算法让它尽量并行起来
我们用C搞out-of-core优化, 那个感觉比较方便, 但我不是java专家, 不知道java是不
是也
能做这方面工作; 直觉上应该也可以的. 算法和硬件是提升性能的动力, 写程序的什么
小trick,感觉已经是老黄历
又不是游戏程序,必须在相对固定的硬件平台上运行
【在 g*********e 的大作中提到】
:
: 我这是对应鼓吹并行计算的人的贴，跟语言没关
: 当然，局部的并行还是可以的
: 除此之外就是算法的tune 调参数
|
q*c
发帖数: 9453 | 89 你这个抬杠过分了。 优化有边际效益递减，
一般最简单容易的优化能省大部分时间， 花较少的钱， 这些一般都作了。
后面的优化省的时间钱是越累越少， 花钱时间是越来越多。
所以单机， 简单的优化早做尽了， 剩下的都是费劲坑爹收益小的玩意。 你不能随便
就给人加 32 倍的效率。 这世界上的事情基本都是个程度问题， 你这样的夸张程度，
问题本身根本就变成伪问题了。
【在 b*******s 的大作中提到】
: 单机的确不是方向，不过你有没有考虑过，如果亚麻也不注重底层优化，一台机器能做
: 的事情用32台来做，导致你们这样的用户这方面成本上一个数量级的情况？
:
: 易。
|
b*******s
发帖数: 5216 | 90 前面好虫提到过一个他用32台机器代替别人一台的设计
【在 q*c 的大作中提到】
: 你这个抬杠过分了。 优化有边际效益递减，
: 一般最简单容易的优化能省大部分时间， 花较少的钱， 这些一般都作了。
: 后面的优化省的时间钱是越累越少， 花钱时间是越来越多。
: 所以单机， 简单的优化早做尽了， 剩下的都是费劲坑爹收益小的玩意。 你不能随便
: 就给人加 32 倍的效率。 这世界上的事情基本都是个程度问题， 你这样的夸张程度，
: 问题本身根本就变成伪问题了。
|
|
|
q*c
发帖数: 9453 | 91 那他那 32 台机器夹起来估计成本高不多。
机器配置超高， 价格呢也是超高， 而且不线性。 32 台破机器比 一台吊炸天的机器
可不贵。
而且32 机器 数度快。
【在 b*******s 的大作中提到】
: 前面好虫提到过一个他用32台机器代替别人一台的设计
|
b*******s
发帖数: 5216 | 92 的确算法才是最重要的，往往能带来数量级的优化
【在 m********5 的大作中提到】
: 人家的意思是其他语言比C++能更方便地实现并行管理
: 你突然冒出来一个并行不是万能的, 但是这个和C++/Java有什么关系?!
: 不能并行优化的程序你用C++在单机上也快不了多少
: 与其花心思优化,不如直接升级硬件, 或者花心思改变算法让它尽量并行起来
: 我们用C搞out-of-core优化, 那个感觉比较方便, 但我不是java专家, 不知道java是不
: 是也
: 能做这方面工作; 直觉上应该也可以的. 算法和硬件是提升性能的动力, 写程序的什么
: 小trick,感觉已经是老黄历
: 又不是游戏程序,必须在相对固定的硬件平台上运行
|
b*******s
发帖数: 5216 | 93 我的重点是，像亚麻这种提供基础设施的，还是性能敏感的
现在亚麻能把google appengine按在地上揍，最大的优势就是成本低
器
【在 q*c 的大作中提到】
: 那他那 32 台机器夹起来估计成本高不多。
: 机器配置超高， 价格呢也是超高， 而且不线性。 32 台破机器比 一台吊炸天的机器
: 可不贵。
: 而且32 机器 数度快。
|
g*****g
发帖数: 34805 | 94 你再看看OP，他是一个workstation跑32个process. 在那为一点内存叽叽歪歪，跟金子
似的。
这个换到32台机器上跑有啥不行的？不管CPU bound, memory bound，立马提速。而且
我不跑得的时候不就不花钱了吗。他在DC里跑，budget里花不起32台机器。我在cloud
里跑，不但32台，还要想着有没有办法继续细分。他一台机器跑4，5个小时，我32台10
分钟够了，如果能够继续细分跑320台没准1分钟够了。我举的那个encoding就是这个思
想。
【在 b*******s 的大作中提到】
: 前面好虫提到过一个他用32台机器代替别人一台的设计
|
b*******s
发帖数: 5216 | 95 看你从什么角度看了，亚麻之类还是要尽量实现高性能的
而且亚麻之类大批采购同型服务器的，一次优化也能应用到大量机器上
【在 g*****g 的大作中提到】
: 你再看看OP，他是一个workstation跑32个process. 在那为一点内存叽叽歪歪，跟金子
: 似的。
: 这个换到32台机器上跑有啥不行的？不管CPU bound, memory bound，立马提速。而且
: 我不跑得的时候不就不花钱了吗。他在DC里跑，budget里花不起32台机器。我在cloud
: 里跑，不但32台，还要想着有没有办法继续细分。他一台机器跑4，5个小时，我32台10
: 分钟够了，如果能够继续细分跑320台没准1分钟够了。我举的那个encoding就是这个思
: 想。
|
z****e
发帖数: 54598 | 96 no worry man
u will see the game runs on different platform in future
javafx is the solution
【在 m********5 的大作中提到】
: 人家的意思是其他语言比C++能更方便地实现并行管理
: 你突然冒出来一个并行不是万能的, 但是这个和C++/Java有什么关系?!
: 不能并行优化的程序你用C++在单机上也快不了多少
: 与其花心思优化,不如直接升级硬件, 或者花心思改变算法让它尽量并行起来
: 我们用C搞out-of-core优化, 那个感觉比较方便, 但我不是java专家, 不知道java是不
: 是也
: 能做这方面工作; 直觉上应该也可以的. 算法和硬件是提升性能的动力, 写程序的什么
: 小trick,感觉已经是老黄历
: 又不是游戏程序,必须在相对固定的硬件平台上运行
|
m********5
发帖数: 17667 | 97 我如果是他老板就把他解雇了, 省下来的钱买32台机器
LoL
不过我估计他是在科研单位,人力便宜,才会把人这么用
【在 g*****g 的大作中提到】
: 你再看看OP，他是一个workstation跑32个process. 在那为一点内存叽叽歪歪，跟金子
: 似的。
: 这个换到32台机器上跑有啥不行的？不管CPU bound, memory bound，立马提速。而且
: 我不跑得的时候不就不花钱了吗。他在DC里跑，budget里花不起32台机器。我在cloud
: 里跑，不但32台，还要想着有没有办法继续细分。他一台机器跑4，5个小时，我32台10
: 分钟够了，如果能够继续细分跑320台没准1分钟够了。我举的那个encoding就是这个思
: 想。
|
g*****g
发帖数: 34805 | 98 我这评价的就是OP的use case. 一个workstation跑32个相同的process。
多半是单线程的，这么搞来使用多核。这个上云是绝对没有压力。
【在 b*******s 的大作中提到】
: 看你从什么角度看了，亚麻之类还是要尽量实现高性能的
: 而且亚麻之类大批采购同型服务器的，一次优化也能应用到大量机器上
|
g*********e
发帖数: 14401 | 99
但也些工作没法并行，所以那些分布式的玩意儿都没法用。所以只能强调算法和微调。
一味的强调java搞分布式多牛，也没法解决这些问题。
单机做计算C++肯定比java块，这是它的优势。
不知道你说的买硬件有什么用，我们做commercial software的，tool拿给用户去用，
自然是越快越好。举个例子，winzip, 3d max这种软件拼的就是效率。你说得啥iaaS
model让一个非web公司搞根本不现实，放到第三方的云上也不安全。
这跟web公司卖数据content不同，它们是现成得organize好了数据库让人来query。
【在 m********5 的大作中提到】
: 人家的意思是其他语言比C++能更方便地实现并行管理
: 你突然冒出来一个并行不是万能的, 但是这个和C++/Java有什么关系?!
: 不能并行优化的程序你用C++在单机上也快不了多少
: 与其花心思优化,不如直接升级硬件, 或者花心思改变算法让它尽量并行起来
: 我们用C搞out-of-core优化, 那个感觉比较方便, 但我不是java专家, 不知道java是不
: 是也
: 能做这方面工作; 直觉上应该也可以的. 算法和硬件是提升性能的动力, 写程序的什么
: 小trick,感觉已经是老黄历
: 又不是游戏程序,必须在相对固定的硬件平台上运行
|
g*****g
发帖数: 34805 | 100 OP都说了跑32个process，还不能并行？打岔也不是这样的。
说到数据安全，Salesforce都能做，从工资到销售数据都在云上。你们有啥不能做的。
【在 g*********e 的大作中提到】
:
: 但也些工作没法并行，所以那些分布式的玩意儿都没法用。所以只能强调算法和微调。
: 一味的强调java搞分布式多牛，也没法解决这些问题。
: 单机做计算C++肯定比java块，这是它的优势。
: 不知道你说的买硬件有什么用，我们做commercial software的，tool拿给用户去用，
: 自然是越快越好。举个例子，winzip, 3d max这种软件拼的就是效率。你说得啥iaaS
: model让一个非web公司搞根本不现实，放到第三方的云上也不安全。
: 这跟web公司卖数据content不同，它们是现成得organize好了数据库让人来query。
|
|
|
z****e
发帖数: 54598 | 101 photoshop has already started moving to the cloud
since its latest cc version
try to fit in and get used to this trend man
【在 g*********e 的大作中提到】
:
: 但也些工作没法并行，所以那些分布式的玩意儿都没法用。所以只能强调算法和微调。
: 一味的强调java搞分布式多牛，也没法解决这些问题。
: 单机做计算C++肯定比java块，这是它的优势。
: 不知道你说的买硬件有什么用，我们做commercial software的，tool拿给用户去用，
: 自然是越快越好。举个例子，winzip, 3d max这种软件拼的就是效率。你说得啥iaaS
: model让一个非web公司搞根本不现实，放到第三方的云上也不安全。
: 这跟web公司卖数据content不同，它们是现成得organize好了数据库让人来query。
|
g*********e
发帖数: 14401 | 102
OP的意思是每个process要跑4-5个小时，3g内存，怎么并行？你把它放到10个机器上就
能一小时完成？又不是视频解码可以分割。
另外国防部的芯片design可不敢放到salesforce上。
【在 g*****g 的大作中提到】
: OP都说了跑32个process，还不能并行？打岔也不是这样的。
: 说到数据安全，Salesforce都能做，从工资到销售数据都在云上。你们有啥不能做的。
|
m********5
发帖数: 17667 | 103 但这就是目前的方向
单机的日子走到头了
开发维护成本高,使用效率不够
我觉得程序员要向前看, 一味的强调目前老领域还剩哪些可以做,我觉得太固步自封了
云计算中心, 在今后完全是可以接受的模式
对于敏感数据,安全专家会告诉你放在第三方云上并不比放在维护较差的私有服务器上
危险, 可能还更安全.
对于一个公司,使用云的成本绝对比自己维持一个IT团队更便宜, 其实早就是如此, 大
部分公司IT都是外包的
100年前,你很难想象PG&E这样的公司存在, 坚持自己打井 :D
【在 g*********e 的大作中提到】
:
: OP的意思是每个process要跑4-5个小时，3g内存，怎么并行？你把它放到10个机器上就
: 能一小时完成？又不是视频解码可以分割。
: 另外国防部的芯片design可不敢放到salesforce上。
|
n****1
发帖数: 1136 | 104 他如果单机上有32个核， 那多机自然没有用。否则肯定能成倍提高速度。
【在 g*********e 的大作中提到】
:
: OP的意思是每个process要跑4-5个小时，3g内存，怎么并行？你把它放到10个机器上就
: 能一小时完成？又不是视频解码可以分割。
: 另外国防部的芯片design可不敢放到salesforce上。
|
z****e
发帖数: 54598 | 105 cloud would be the solution but
we still need some it guys to work in business companies
since different business company has different requirements
which are completely different from each other
even in the same industry like two banks
they use totally different mechanism
they cant be the same, thus
people need it guys to generate customized codes
【在 m********5 的大作中提到】
: 但这就是目前的方向
: 单机的日子走到头了
: 开发维护成本高,使用效率不够
: 我觉得程序员要向前看, 一味的强调目前老领域还剩哪些可以做,我觉得太固步自封了
: 云计算中心, 在今后完全是可以接受的模式
: 对于敏感数据,安全专家会告诉你放在第三方云上并不比放在维护较差的私有服务器上
: 危险, 可能还更安全.
: 对于一个公司,使用云的成本绝对比自己维持一个IT团队更便宜, 其实早就是如此, 大
: 部分公司IT都是外包的
: 100年前,你很难想象PG&E这样的公司存在, 坚持自己打井 :D
|
m********5
发帖数: 17667 | 106 autoCAD已经云了
3DMax即将云了
其实说3DMax即将云了不对, 大部分公司的render都是放到第三方的render farm做, 不
可能在自己公司做 LoL
所以也可以说3Dmax造就云起来了, 3D render可能是云得最早的一个应用, 大家还没
cloud概念的时候, 人家就已经在做了, 因为3D 相对来说还是计算密集的东西, 成品以
前直接硬盘寄回来就行.
Photoshop这种raster format 编辑器, 应该是数据密集的应用, 感觉放在云上有点那
啥, 但看它的发展吧, 我是比较好奇
illustrator之类vector format的, 我觉得完全可以云起来
【在 z****e 的大作中提到】
: photoshop has already started moving to the cloud
: since its latest cc version
: try to fit in and get used to this trend man
|
g*********e
发帖数: 14401 | 107
这我同意，是大势所趋
单机的东西越来越小众了
【在 m********5 的大作中提到】
: 但这就是目前的方向
: 单机的日子走到头了
: 开发维护成本高,使用效率不够
: 我觉得程序员要向前看, 一味的强调目前老领域还剩哪些可以做,我觉得太固步自封了
: 云计算中心, 在今后完全是可以接受的模式
: 对于敏感数据,安全专家会告诉你放在第三方云上并不比放在维护较差的私有服务器上
: 危险, 可能还更安全.
: 对于一个公司,使用云的成本绝对比自己维持一个IT团队更便宜, 其实早就是如此, 大
: 部分公司IT都是外包的
: 100年前,你很难想象PG&E这样的公司存在, 坚持自己打井 :D
|
g*****g
发帖数: 34805 | 108 能跑32个进程，为啥不能跑64个，他单机32核多半。我云上弄1000个也没压力。加速30
倍咋不行。
甭管多少倍，他拿这个例子来说明 c++好实在 naive.
【在 n****1 的大作中提到】
: 他如果单机上有32个核， 那多机自然没有用。否则肯定能成倍提高速度。
|
m********5
发帖数: 17667 | 109 算法限制啊
有些模型,对同一个size问题, 最多就只能32个同时算 :)
再小就没法uncople, 或者uncople的代价过大, 比如数据交换过多等等
30
【在 g*****g 的大作中提到】
: 能跑32个进程，为啥不能跑64个，他单机32核多半。我云上弄1000个也没压力。加速30
: 倍咋不行。
: 甭管多少倍，他拿这个例子来说明 c++好实在 naive.
|
q*c
发帖数: 9453 | 110 那你就完全错了，亚麻赢了狗狗和软软，和机器成本啊等一毛钱关系没有。这些硬件的
差别太小了。
亚麻各种技术一塌糊涂，但是人家商业眼光牛逼啊，具体到 干死狗狗的 app engine,
我觉得亚麻不追求真实的云计算，亚麻开始打天下占市场的时候其实根本就不是云计
算。 亚麻那个东西叫 ～ 虚拟机出租。当然跟着其他的配套服务。这东西技术含量低
的很，出了问题就靠工程师的冲脸流。狗狗来的是高大上。，app engine...
但是亚麻就是赢了，为啥？因为客户需要的不是啥牛逼云计算 engine 技术.客户需要
的是把自己单机上跑的东西移植过去，不用重写，不被绑定死在一家 framewoek 上。
所以亚麻就赢了。这可不是什么成本问题。要说拼钱，狗狗软软秒杀亚麻，拼成本低是
没戏的。
【在 b*******s 的大作中提到】
: 我的重点是，像亚麻这种提供基础设施的，还是性能敏感的
: 现在亚麻能把google appengine按在地上揍，最大的优势就是成本低
:
: 器
|
|
|
x****u
发帖数: 44466 | 111 的确，app engine这种东西太冷艳了。收费还要把人家活活被绑死。
,
【在 q*c 的大作中提到】
: 那你就完全错了，亚麻赢了狗狗和软软，和机器成本啊等一毛钱关系没有。这些硬件的
: 差别太小了。
: 亚麻各种技术一塌糊涂，但是人家商业眼光牛逼啊，具体到 干死狗狗的 app engine,
: 我觉得亚麻不追求真实的云计算，亚麻开始打天下占市场的时候其实根本就不是云计
: 算。 亚麻那个东西叫 ～ 虚拟机出租。当然跟着其他的配套服务。这东西技术含量低
: 的很，出了问题就靠工程师的冲脸流。狗狗来的是高大上。，app engine...
: 但是亚麻就是赢了，为啥？因为客户需要的不是啥牛逼云计算 engine 技术.客户需要
: 的是把自己单机上跑的东西移植过去，不用重写，不被绑定死在一家 framewoek 上。
: 所以亚麻就赢了。这可不是什么成本问题。要说拼钱，狗狗软软秒杀亚麻，拼成本低是
: 没戏的。
|
g*****g
发帖数: 34805 | 112 你说的也不全对，一旦上了aws，谁不得用点s3, sqs啥的，两下三下就绑死了。
底下那些全套部署的东西更是平台相关。
狗狗那PaaS想法是好的，问题是只支持阉割的JVM我去。我想在上面跑个应用，用
HtmlUnit抓点东西，狗狗那IDE说用了不支持的类不肯编译。你说要自己的代码还能绕
路，这年头是个应用几十上百dependency，直接就是不能用。
,
【在 q*c 的大作中提到】
: 那你就完全错了，亚麻赢了狗狗和软软，和机器成本啊等一毛钱关系没有。这些硬件的
: 差别太小了。
: 亚麻各种技术一塌糊涂，但是人家商业眼光牛逼啊，具体到 干死狗狗的 app engine,
: 我觉得亚麻不追求真实的云计算，亚麻开始打天下占市场的时候其实根本就不是云计
: 算。 亚麻那个东西叫 ～ 虚拟机出租。当然跟着其他的配套服务。这东西技术含量低
: 的很，出了问题就靠工程师的冲脸流。狗狗来的是高大上。，app engine...
: 但是亚麻就是赢了，为啥？因为客户需要的不是啥牛逼云计算 engine 技术.客户需要
: 的是把自己单机上跑的东西移植过去，不用重写，不被绑定死在一家 framewoek 上。
: 所以亚麻就赢了。这可不是什么成本问题。要说拼钱，狗狗软软秒杀亚麻，拼成本低是
: 没戏的。
|
q*c
发帖数: 9453 | 113 我特指的是 ec2. 这个东西当时是核心。主要是软件无缝移植，编译都不要。app
engine 啥的太折腾了。
当然用了 ec2 你自然要用其他的东西。。。
【在 g*****g 的大作中提到】
: 你说的也不全对，一旦上了aws，谁不得用点s3, sqs啥的，两下三下就绑死了。
: 底下那些全套部署的东西更是平台相关。
: 狗狗那PaaS想法是好的，问题是只支持阉割的JVM我去。我想在上面跑个应用，用
: HtmlUnit抓点东西，狗狗那IDE说用了不支持的类不肯编译。你说要自己的代码还能绕
: 路，这年头是个应用几十上百dependency，直接就是不能用。
:
: ,
|
z****e
发帖数: 54598 | 114 折腾也就罢了
关键是还很小气，给你那么点东西还斤斤计较
【在 x****u 的大作中提到】
: 的确，app engine这种东西太冷艳了。收费还要把人家活活被绑死。
:
: ,
|
N******K
发帖数: 10202 | 115 1G是我程序的内存的基本计量单位
【在 d*********0 的大作中提到】
: 我们每个程序都要run 四五个小时，
: 每个程序都要3G左右内存，
: 一样的工作量， 这速度，这内存的控制，岂是其他语言可以胜任的？
|
a*******8
发帖数: 156 | 116 我是菜鸟 为啥本版都没人讨论.net c# 大家能讨论下吗？是这语言没前途吗？ |
N******K
发帖数: 10202 | 117 国内的云有好用的吗？ 另外如果腾讯搞云 有人敢用否？
【在 m********5 的大作中提到】
: 但这就是目前的方向
: 单机的日子走到头了
: 开发维护成本高,使用效率不够
: 我觉得程序员要向前看, 一味的强调目前老领域还剩哪些可以做,我觉得太固步自封了
: 云计算中心, 在今后完全是可以接受的模式
: 对于敏感数据,安全专家会告诉你放在第三方云上并不比放在维护较差的私有服务器上
: 危险, 可能还更安全.
: 对于一个公司,使用云的成本绝对比自己维持一个IT团队更便宜, 其实早就是如此, 大
: 部分公司IT都是外包的
: 100年前,你很难想象PG&E这样的公司存在, 坚持自己打井 :D
|
b*******s
发帖数: 5216 | 118 亚麻进中国了
【在 N******K 的大作中提到】
: 国内的云有好用的吗？ 另外如果腾讯搞云 有人敢用否？
|
N******K
发帖数: 10202 | 119 nsa监控的东西 不会有人用
【在 b*******s 的大作中提到】
: 亚麻进中国了
|
