d****n
发帖数: 12461 | 1 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？ |
g*****g
发帖数: 34805 | 2 不适合做要求很高的事实系统。非要上就得用 azul 之类的 JVM.
【在 d****n 的大作中提到】
: 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
: 集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？
|
b*******s
发帖数: 5216 | 3 软实时是可能的，但性能不会太好
【在 d****n 的大作中提到】
: 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
: 集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？
|
b*******s
发帖数: 5216 | 4 不过是有相当数量的legacy的金融系统是java写的
【在 d****n 的大作中提到】
: 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
: 集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？
|
w**z
发帖数: 8232 | 5 还像在哪见过,把heap搞大，调Gc参数让gc 不发生，然后定时rolling restart。不过
总的来说，gc 搞实时有点费劲。
【在 d****n 的大作中提到】
: 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
: 集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？
|
z*******3
发帖数: 13709 | 6 你多开几个nodes，哪有几个node都同时gc的道理
在发送请求之前先verify一下
短时间内无响应直接换下一个node
总有能响应的，这样就能绕开了gc停顿了
前提是你网络的latency不会太高，其实很多烂网络一个ping都几十ms
去纠结内存gc的停顿纯粹吃太饱了
游戏行当就有用java做server的
没事
【在 d****n 的大作中提到】
: 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
: 集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？
|
d****n
发帖数: 12461 | 7 我们这个需求有些不太一样，数据分布，结果却要同时返回。
【在 z*******3 的大作中提到】
: 你多开几个nodes，哪有几个node都同时gc的道理
: 在发送请求之前先verify一下
: 短时间内无响应直接换下一个node
: 总有能响应的，这样就能绕开了gc停顿了
: 前提是你网络的latency不会太高，其实很多烂网络一个ping都几十ms
: 去纠结内存gc的停顿纯粹吃太饱了
: 游戏行当就有用java做server的
: 没事
|
z*******3
发帖数: 13709 | 8 没有replica？
同一个数据集中存放，不分布？
这样的话，一旦有一个node挂了，岂不是完蛋？
具体说说什么需求？
股票交易平台不需要保证real time
客户端发送一个request，处理都需要一定时间，这里面还涉及到transaction的操作
也慢，而且也没有必要，几十ms的停顿绝大多数人压根感受不到
包括买股票的，买股票很多broker都是今天你下单，明天才告诉你买了多少
bmo买美股就是这样，很多交易所也不允许你当天买了当天就卖
而且从挂出交易价格，到真正成交也有明显的延迟，也不是说你现在下单买了
马上就有人卖给你，经常会出现没有人卖的情况，或者买卖双方价格有差距
这些都无法马上成交，这种延迟远远超过机器的延迟
而且本身网络的各种latency就很明显，都明显超过内存的操作，超过几十倍都不只
gc这种只要不太大，一般停顿时间都感受不到，比起网络的延迟来说
忽略不计都没啥问题
用专业点话说就是，股票交易平台这种，保证total ordering就好了
其他不管，real time在server side其实并不是主流需求，倒是在手机这种小部件上
比较主流，因为游戏的刷屏如果太慢，人眼可以感受得到
一般一秒30真以上，1000/30大概也就是30ms以内必需完成一个更新
所以这个精确到ms还是make sense的，平台real time纯粹都是扯蛋，都是忽悠
server side的实时需求我还没遇到过
【在 d****n 的大作中提到】
: 我们这个需求有些不太一样，数据分布，结果却要同时返回。
|
F****n
发帖数: 3271 | 9 股票交易是对实时要求最高的应用之一，
high frequency trading 几毫秒就是几千万上亿的进出
即使不是 high frequency 的 bid 系统，delay也会坏事
这种东西Java最多做做界面
【在 z*******3 的大作中提到】
: 没有replica？
: 同一个数据集中存放，不分布？
: 这样的话，一旦有一个node挂了，岂不是完蛋？
: 具体说说什么需求？
: 股票交易平台不需要保证real time
: 客户端发送一个request，处理都需要一定时间，这里面还涉及到transaction的操作
: 也慢，而且也没有必要，几十ms的停顿绝大多数人压根感受不到
: 包括买股票的，买股票很多broker都是今天你下单，明天才告诉你买了多少
: bmo买美股就是这样，很多交易所也不允许你当天买了当天就卖
: 而且从挂出交易价格，到真正成交也有明显的延迟，也不是说你现在下单买了
|
z*******3
发帖数: 13709 | 10 delay就delay，不丢数据就行了，大不了放个cache
保证ordering不要错就没啥问题，delay几个ms后面补回来
前一段不是有人说嘛，nasdaq的系统是java写的，我绝对信
股票交易都被神话了，一堆红马甲在那边拿着纸票互相喊，去哪里来的实时
一个马甲跑过去都几秒，你要跟我说导弹拦截，这个要求real time
这个我信，但是股票交易平台，只要保证不丢包，ordering没错
其实慢一点还真不是什么大事，而且用户根本感受不到
网络的latency绝对比内存的操作要慢一个数量级，比硬盘的操作都慢一个数量级
【在 F****n 的大作中提到】
: 股票交易是对实时要求最高的应用之一，
: high frequency trading 几毫秒就是几千万上亿的进出
: 即使不是 high frequency 的 bid 系统，delay也会坏事
: 这种东西Java最多做做界面
|
|
|
z*******3
发帖数: 13709 | 11 “high frequency trading 几毫秒就是几千万上亿的进出”
这种都是throughput
而且个股之间的dependencies非常少
你买你的，我买我的，transaction可以把微粒度调到最低
而且我曾经遇到过，我送的单，当我中途撤销的时候，交易了一半掉
也就是这个其实压根就没有用户控制的transaction，电脑控制的
交易成功多少就是多少，中途撤单并不能保证你全额退款，可能压根就不退
或者只退一半，因为另外一半交易成功了，这个用行话就是
不sequentially equivalent，那这种transaction做起来就太容易了
跟一般商业银行的交易比起来，这个transaction还真不是个事
加上本身就是通过网络传输的数据，所以可以通过内网来scale out
保证内网的速度别太低就行，内存操作那点gc时间，完全没有必要在乎
实在不行买点内存，我不gc行么？股票交易也有高潮和低潮
一般开盘时候最高潮，一个小时两个小时之后，交易高峰就会回落
这个时候gc也可以，都有很多办法，没有必要跟gc那点停顿去死磕
死磕gc停顿还不如想办法把网速提高一点，内存的io和操作比起网络，那是要快太多了
【在 F****n 的大作中提到】
: 股票交易是对实时要求最高的应用之一，
: high frequency trading 几毫秒就是几千万上亿的进出
: 即使不是 high frequency 的 bid 系统，delay也会坏事
: 这种东西Java最多做做界面
|
z*******3
发帖数: 13709 | 12 股票交易要真那么牛逼要求
估计现在都在用主机
问题在于，你什么时候听说过主机用在股票交易平台上？
hpc都少，就是分布式那一套，java系统占大部分
nasdaq用java写的我一点都不怀疑 |
z*******3
发帖数: 13709 | 13 随手google来的
Ex employee • 2 years ago
Actually, the NASDAQ Genium INET system uses a trading engine developed in
Java. It runs on RedHat. |
z*******3
发帖数: 13709 | |
d****i
发帖数: 4809 | 15 不是这个领域，但是根据金融界的朋友，实时系统基本都是C++, 甚至还有直接用硬件
FPGA解决的方法。
【在 d****n 的大作中提到】
: 例如股票交易系统。今天碰到个牛说java有gc，那个几十几百ms就会造成问题，单纯用
: 集群也没法解决，因为每台机器都有。不知道业界比较成熟的方案是什么样的？
|
d****n
发帖数: 12461 | 16 只有若干个副本吧，n>=3,但是远少于所有服务器的数量。
【在 z*******3 的大作中提到】
: 没有replica？
: 同一个数据集中存放，不分布？
: 这样的话，一旦有一个node挂了，岂不是完蛋？
: 具体说说什么需求？
: 股票交易平台不需要保证real time
: 客户端发送一个request，处理都需要一定时间，这里面还涉及到transaction的操作
: 也慢，而且也没有必要，几十ms的停顿绝大多数人压根感受不到
: 包括买股票的，买股票很多broker都是今天你下单，明天才告诉你买了多少
: bmo买美股就是这样，很多交易所也不允许你当天买了当天就卖
: 而且从挂出交易价格，到真正成交也有明显的延迟，也不是说你现在下单买了
|
g*****g
发帖数: 34805 | 17 nasdaq可能有很大一部分用java写的，但不意味着核心matching的部分也是用java写的。
我认为用C/C++来写实时部分很合理。
【在 z*******3 的大作中提到】
: delay就delay，不丢数据就行了，大不了放个cache
: 保证ordering不要错就没啥问题，delay几个ms后面补回来
: 前一段不是有人说嘛，nasdaq的系统是java写的，我绝对信
: 股票交易都被神话了，一堆红马甲在那边拿着纸票互相喊，去哪里来的实时
: 一个马甲跑过去都几秒，你要跟我说导弹拦截，这个要求real time
: 这个我信，但是股票交易平台，只要保证不丢包，ordering没错
: 其实慢一点还真不是什么大事，而且用户根本感受不到
: 网络的latency绝对比内存的操作要慢一个数量级，比硬盘的操作都慢一个数量级
|
d****n
发帖数: 12461 | 18 大N也自己写C/C++吗？我以为现在高大上都是java+js+hadoop/c*+kafka/storm了。
的。
【在 g*****g 的大作中提到】
: nasdaq可能有很大一部分用java写的，但不意味着核心matching的部分也是用java写的。
: 我认为用C/C++来写实时部分很合理。
|
g*****g
发帖数: 34805 | 19 我不写C++很多年了，但什么样的需要用什么样的语言。实时系统Java不如C/C++合适。
【在 d****n 的大作中提到】
: 大N也自己写C/C++吗？我以为现在高大上都是java+js+hadoop/c*+kafka/storm了。
:
: 的。
|
z*******3
发帖数: 13709 | 20 问题在于我觉得股票交易本身并不需要实时处理
的。
【在 g*****g 的大作中提到】
: nasdaq可能有很大一部分用java写的，但不意味着核心matching的部分也是用java写的。
: 我认为用C/C++来写实时部分很合理。
|
|
|
z*******3
发帖数: 13709 | 21 不写吧，要看什么平台
他们如果做手机上的播放器
这个可能还真需要c/c++
这个是实时的领域
大系统本身系统传输，内部通信都非常耗时
gc比起来，那是非常快了
网络系统公网就很慢，其次内网也不快
股票交易这种涉及到人的行为的就更慢
还有transaction的处理，也是狂拖时间的一个环节
这几个都比gc要慢很多
【在 d****n 的大作中提到】
: 大N也自己写C/C++吗？我以为现在高大上都是java+js+hadoop/c*+kafka/storm了。
:
: 的。
|
z*******3
发帖数: 13709 | 22 server side实时都是主机在做
因为主机避开了网络io，节省的时间是大大的
而且也避开了db的transaction，自己写transaction
分布式都要用到网络，肯定做不到real time处理
各种算法也都有明显的延迟，不同nodes之间的沟通都需要通过网络
网络非常非常慢，再快都快不到哪里去，比起内存操作来说
所以分布式不可能做到实时，一般实时都是单机
股票交易我没听说有哪个交易所采购过主机
民航倒是很多
db之所以现在不适合搞分布式也跟db本身强要求acid有关
一个consistency和networking就是明显的冲突
再快也做不到real time |
z*******3
发帖数: 13709 | 23 一般来说
cpu操作速度>>内存操作>>硬盘操作>>网络操作
>>大概都是100倍左右的对比，基本上是这个数量级
也就是说，网络一次io，内存可以执行10000次内存操作这种数量级
只要你的java代码写得不是那么烂，10000也该够一次gc了
而且gc本身还可以被中断，释放一部分内存之后转入运行状态
所以如果不是非常大gc的话，一般不是问题
当然话不说死，要是有人写出memory leak的话，那怎样都是问题
分布式最大的问题不是latency，而是丢包
数据因为各种莫名其妙的原因丢失，所以很多时候为了保证不丢数据
在每一次协议执行的时候，都会persistence一下，也就是对硬盘做操作
那这种就更慢了，而股票交易最重要的是别丢数据
否则麻烦大了，丢钱对谁来说都是大事
所以这种操作基本上可以肯定存在
所以说到底就是所谓股票交易用real time本身就是一个伪命题
纯粹是胡扯的可能性很大 |
f*****e
发帖数: 2992 | 24 What about real time bidding?
的。
【在 g*****g 的大作中提到】
: nasdaq可能有很大一部分用java写的，但不意味着核心matching的部分也是用java写的。
: 我认为用C/C++来写实时部分很合理。
|
f*****e
发帖数: 2992 | 25 我们公司用的就是你说的那些！
【在 d****n 的大作中提到】
: 大N也自己写C/C++吗？我以为现在高大上都是java+js+hadoop/c*+kafka/storm了。
:
: 的。
|
z****e
发帖数: 54598 | 26 again
total ordering足够了
bidding并不需要在处理时候real time
你只要保证进来的单顺序别搞错就行了
这个我搞分布式的，这种东西你们要是谁不懂理论跟我来扯蛋
差距是有一点，光举例没用
【在 f*****e 的大作中提到】
: What about real time bidding?
:
: 的。
|
z****e
发帖数: 54598 | 27 拍卖，bidding这种东西就是典型的ordering的应用
就是你表出现两个同时，因为缺少global clock
你必需想出一种方式来确认其ordering，否则是灾难
期间latency没有人在乎，因为不至于出现错误
顶多慢那么几十ms，那这个不重要
其实股票交易市场，比如a股，集合竞价就是bidding
这个其实是异步处理的，大家一堆人同时发单
但是呢，你要等5分钟才能看到结果
5分钟阿，你可以做n*10^10次gc了 |
z****e
发帖数: 54598 | 28 当然对于客户端的要求可能就是需要real time
因为你单没送出去，别人送出去了，那结果就不一样
server side没听说谁搞成real time的
都是忽悠，装得很牛逼的样子 |
S**********C
发帖数: 161 | 29 老赵又来了，不懂你就直接说不懂，不要扮成专家误导别人，如果客户发个IOC(
Immediate Or Cancel) Order 过来，你说你等会，我过5分钟才告诉你结果，你这是咸
丰年代的交易系统啊?
【在 z****e 的大作中提到】
: 拍卖，bidding这种东西就是典型的ordering的应用
: 就是你表出现两个同时，因为缺少global clock
: 你必需想出一种方式来确认其ordering，否则是灾难
: 期间latency没有人在乎，因为不至于出现错误
: 顶多慢那么几十ms，那这个不重要
: 其实股票交易市场，比如a股，集合竞价就是bidding
: 这个其实是异步处理的，大家一堆人同时发单
: 但是呢，你要等5分钟才能看到结果
: 5分钟阿，你可以做n*10^10次gc了
|
z****e
发帖数: 54598 | 30 干
a股的集合竞价时候中途撤单不就是15分钟才告诉你结果？
again
total ordering是什么，你先去理解之后再来跟我扯蛋
否则理论上你跟我差距太大
【在 S**********C 的大作中提到】
: 老赵又来了，不懂你就直接说不懂，不要扮成专家误导别人，如果客户发个IOC(
: Immediate Or Cancel) Order 过来，你说你等会，我过5分钟才告诉你结果，你这是咸
: 丰年代的交易系统啊?
|
|
|
z****e
发帖数: 54598 | 31 集合竞价只是a股一个特例
我说的不需要等几分钟，一样适用
gc只要tune得好，最长停顿不太可能太离谱
以前天朝几千万客户的四台jvm，一般gc停顿控制在200ms以内
大多数也就是50－70ms之间，上100ms都很少，没啥问题
这里面还有大量transaction交易
【在 S**********C 的大作中提到】
: 老赵又来了，不懂你就直接说不懂，不要扮成专家误导别人，如果客户发个IOC(
: Immediate Or Cancel) Order 过来，你说你等会，我过5分钟才告诉你结果，你这是咸
: 丰年代的交易系统啊?
|
S**********C
发帖数: 161 | 32 还什么total ordering，什么理论差距，你承认一下自己不懂会死吗？一个交易系统由
哪些components 构成，
比如routing, market data,etc,etc,哪些部分是latency sensitive，你肯定clueless
,你就洗洗睡吧，不要把在programing 那套无知者无畏的态度带过来。
【在 z****e 的大作中提到】
: 干
: a股的集合竞价时候中途撤单不就是15分钟才告诉你结果？
: again
: total ordering是什么，你先去理解之后再来跟我扯蛋
: 否则理论上你跟我差距太大
|
z****e
发帖数: 54598 | 33 干，到底是谁不懂？
我例子说的是集合竞价，你显然看不懂什么是集合竞价
http://baike.baidu.com/view/24186.htm
自己看，是不是需要5分钟以上才能响应撤单的需求
什么是total ordering都不知道，你还在纠结哪里是latency sensitive
跟你说了，股票交易并非什么latency sensitive的东西
因为股票交易本身并不需要real time反应，都是米犹瞎吹
否则你告诉我网络的latency你怎么解决？这个比gc的停顿不知道要慢多少倍
还routing，你告诉我怎么routing会比内存操作更快，哪个网络io能比内存快？
还market data，你忽悠什么呢？
我的例子你看不懂，我说的理论你也看不懂
对分布式你知道什么？不是我说你，你在我面前就是一个婴儿
clueless
【在 S**********C 的大作中提到】
: 还什么total ordering，什么理论差距，你承认一下自己不懂会死吗？一个交易系统由
: 哪些components 构成，
: 比如routing, market data,etc,etc,哪些部分是latency sensitive，你肯定clueless
: ,你就洗洗睡吧，不要把在programing 那套无知者无畏的态度带过来。
|
z****e
发帖数: 54598 | 34 来这里跟我扯蛋理论
http://www.mitbbs.com/article_t0/CS/31215505.html
我最近处于扯不出蛋的状态
求牛人educate
但是如果没有这个水平，那还是拉倒吧
clueless
【在 S**********C 的大作中提到】
: 还什么total ordering，什么理论差距，你承认一下自己不懂会死吗？一个交易系统由
: 哪些components 构成，
: 比如routing, market data,etc,etc,哪些部分是latency sensitive，你肯定clueless
: ,你就洗洗睡吧，不要把在programing 那套无知者无畏的态度带过来。
|
a**********n
发帖数: 115 | 35 好像股票交易确实对实时要求很高。。
记得一篇文章说过， 一些公司， 就是为了这个， 把自己的server 放在交易所边上。
挣点网络上的时间。 |
S**********C
发帖数: 161 | 36 还来劲了，你歇着吧，真是浪费时间，撤了。
【在 z****e 的大作中提到】
: 来这里跟我扯蛋理论
: http://www.mitbbs.com/article_t0/CS/31215505.html
: 我最近处于扯不出蛋的状态
: 求牛人educate
: 但是如果没有这个水平，那还是拉倒吧
:
: clueless
|
z*******3
发帖数: 13709 | 37 区分客户端和server side
自己的server，那个不是用来撮合交易的
那个只是送单的，说白了跟手机没啥区别
server side很多概念跟客户端不一样
不是阿猫阿狗弄台破机器，买台破server，自己一阵乱写就能代表主流的
【在 a**********n 的大作中提到】
: 好像股票交易确实对实时要求很高。。
: 记得一篇文章说过， 一些公司， 就是为了这个， 把自己的server 放在交易所边上。
: 挣点网络上的时间。
|
d****n
发帖数: 12461 | 38 是不是flagt五大啊？
【在 f*****e 的大作中提到】
: 我们公司用的就是你说的那些！
|
d****n
发帖数: 12461 | 39 transaction只是实时系统的一部分，这部分就是排序，但是和网络质量有关(~50ms)
但是另一部分是实时pub/sub。每个transaction要传播到所有的服务器上面，等到得到
最慢的那个服务器sync了以后就可以pub。然后上一系列transaction又会影响下一系列
transaction。
因为gc，所以这个服务器sync的速度上不去(worst >500ms)，所以目前transaction会
有瓶颈。
【在 z****e 的大作中提到】
: 拍卖，bidding这种东西就是典型的ordering的应用
: 就是你表出现两个同时，因为缺少global clock
: 你必需想出一种方式来确认其ordering，否则是灾难
: 期间latency没有人在乎，因为不至于出现错误
: 顶多慢那么几十ms，那这个不重要
: 其实股票交易市场，比如a股，集合竞价就是bidding
: 这个其实是异步处理的，大家一堆人同时发单
: 但是呢，你要等5分钟才能看到结果
: 5分钟阿，你可以做n*10^10次gc了
|
z****e
发帖数: 54598 | 40 我说的transaction是db里面的transaction
感觉你们gc停顿时间太长了
当前什么java版本？
1.6？换1.7,然后调成g1试试
>500ms的gc停顿jvm需要tune了
可能需要在代码中插入一些system.gc()
这个虽然不能保证一定会执行gc，但是在计算资源有富余的时候
一般还都是会执行的，还有就是spring这些是不是没用？
感觉都是singleton的话，spring压根不释放对象引用
gc也gc不掉，直接绕开了，速度快很多，整个spring就像一个大obj cache
以前我做的那个系统一般能够控制在~100ms
少量能够控制在55ms之内这样，也是pub/sub系统
不过主要是给美帝公司提供接口，比如twitter
光pub就需要gc > 500ms感觉有些问题
pub的操作相对简单，你们用了轮子没？
比如storm？spark？还是mq？
【在 d****n 的大作中提到】
: transaction只是实时系统的一部分，这部分就是排序，但是和网络质量有关(~50ms)
: 但是另一部分是实时pub/sub。每个transaction要传播到所有的服务器上面，等到得到
: 最慢的那个服务器sync了以后就可以pub。然后上一系列transaction又会影响下一系列
: transaction。
: 因为gc，所以这个服务器sync的速度上不去(worst >500ms)，所以目前transaction会
: 有瓶颈。
|
|
|
z****e
发帖数: 54598 | 41 今天想到一个
你们的pub本身不能分流？
不能爆instances？
【在 d****n 的大作中提到】
: transaction只是实时系统的一部分，这部分就是排序，但是和网络质量有关(~50ms)
: 但是另一部分是实时pub/sub。每个transaction要传播到所有的服务器上面，等到得到
: 最慢的那个服务器sync了以后就可以pub。然后上一系列transaction又会影响下一系列
: transaction。
: 因为gc，所以这个服务器sync的速度上不去(worst >500ms)，所以目前transaction会
: 有瓶颈。
|
b*******s
发帖数: 5216 | 42 he knows nothing about realtime
【在 S**********C 的大作中提到】
: 老赵又来了，不懂你就直接说不懂，不要扮成专家误导别人，如果客户发个IOC(
: Immediate Or Cancel) Order 过来，你说你等会，我过5分钟才告诉你结果，你这是咸
: 丰年代的交易系统啊?
|
W***o
发帖数: 6519 | 43 realtime系统一般用什么实现？c++ 还是c 多一些？ |
d****i
发帖数: 4809 | 44 This depends. For server based real-time system, more C++, less C. If you
talk about embedded real time system like many industrial devices or
consumer devices, then more C, with a little bit C++ on UI and upper layer
side.
【在 W***o 的大作中提到】
: realtime系统一般用什么实现？c++ 还是c 多一些？
|
b*******s
发帖数: 5216 | 45 嵌入式c多，其实速度上是c++11要更快，但嵌入式上面所有的工具都很陈旧，支持很差
国内的做高并发后端的c++还是主流，不过java也在增多
【在 W***o 的大作中提到】
: realtime系统一般用什么实现？c++ 还是c 多一些？
|
d****i
发帖数: 4809 | 46 我们在好几个支持不同的嵌入式系统的平台上跑过测试，C还是比C++效率高一点（90%
的样子)，主要还是各种嵌入式上面的compiler要么只支持C, 要么C++的compiler非常
有限制，毕竟是跑在bare metal上的，不能玩花样，只能老老实实。而且因为嵌入式上
的操作系统都是C写的，用C++的话要在system call上套一层，自然效率低一些，而且C
++不如C来的容易按照机器指令集来优化。至于C++11,在几乎所有embedded平台上的编
译器是完全不支持，太多上层的东西了，完全不能适应底层的需求。
【在 b*******s 的大作中提到】
: 嵌入式c多，其实速度上是c++11要更快，但嵌入式上面所有的工具都很陈旧，支持很差
: 国内的做高并发后端的c++还是主流，不过java也在增多
|
b*******s
发帖数: 5216 | 47 我说的c++11，比如以前在葵版我给的求斐波那契数列某个值比如F（20）的例子，O（1
）复杂度
且C
【在 d****i 的大作中提到】
: 我们在好几个支持不同的嵌入式系统的平台上跑过测试，C还是比C++效率高一点（90%
: 的样子)，主要还是各种嵌入式上面的compiler要么只支持C, 要么C++的compiler非常
: 有限制，毕竟是跑在bare metal上的，不能玩花样，只能老老实实。而且因为嵌入式上
: 的操作系统都是C写的，用C++的话要在system call上套一层，自然效率低一些，而且C
: ++不如C来的容易按照机器指令集来优化。至于C++11,在几乎所有embedded平台上的编
: 译器是完全不支持，太多上层的东西了，完全不能适应底层的需求。
|
b*******s
发帖数: 5216 | 48 嵌入式领域的一个问题是，做专用编译器的水准不如那些linux下做通用编译器的水平
高，或者没有足够资源做。
很多复杂优化都做不出来。c领域的新标准大家也得过且过不愿意跟上。这个和嵌入式领
域不需要真正的高性能，多数情况只需要在板子上能跑不卡这种需求有关。
嵌入式在工业界的发展，底层都不是软件推动的，做软件的好的是比较稳，对学习新知
识要求不迫切
坏处是，做的比较琐碎，积累的经验不仅过时，而且积累周期很长
一些简单系统调用的overhead其实还好了，现在的嵌入式系统的硬件一般也不错了，比
我七八年前才工作时的要强不知道多少了，很多限制已经没有那么紧了。前几年我以前
在国内工作的单位他们就都在板子上用c#写界面了，而且听说现在都在用c#写一些中间
层的应用了，只有信号处理等领域还在用c写
c++一样可以直接嵌汇编，自己手工优化，除了驱动，没什么c能做c++反而不能做的。
我以前第一个项目就是做一个信号处理的，做一组滤波器，一部分就用了单指令多数据
流的指令集
且C
【在 d****i 的大作中提到】
: 我们在好几个支持不同的嵌入式系统的平台上跑过测试，C还是比C++效率高一点（90%
: 的样子)，主要还是各种嵌入式上面的compiler要么只支持C, 要么C++的compiler非常
: 有限制，毕竟是跑在bare metal上的，不能玩花样，只能老老实实。而且因为嵌入式上
: 的操作系统都是C写的，用C++的话要在system call上套一层，自然效率低一些，而且C
: ++不如C来的容易按照机器指令集来优化。至于C++11,在几乎所有embedded平台上的编
: 译器是完全不支持，太多上层的东西了，完全不能适应底层的需求。
|
z****e
发帖数: 54598 | 49 很简单，这种机会就赌上你全家
我懂的话，你全家死绝，哈哈
【在 b*******s 的大作中提到】
: he knows nothing about realtime
|
z****e
发帖数: 54598 | 50 快来围观做嵌入式的傻逼啊
做个鸡八猫嵌入式还觉得自己牛逼
傻逼到家的行当
你想做嵌入式就做呗，做个探阴器就可以发家致富了
日本那些宅男就靠你这个产品来探测妇女阴部了
哈哈
工业界压根没有人鸟底层了，底层你个大便啊
现在机器便宜得跟什么一样，随随便便就可以搞个东西出来
嵌入式你该换个行当去装逼，搞软件没有人在乎这些东西
因为cheap，而且越来越cheap
式领
【在 b*******s 的大作中提到】
: 嵌入式领域的一个问题是，做专用编译器的水准不如那些linux下做通用编译器的水平
: 高，或者没有足够资源做。
: 很多复杂优化都做不出来。c领域的新标准大家也得过且过不愿意跟上。这个和嵌入式领
: 域不需要真正的高性能，多数情况只需要在板子上能跑不卡这种需求有关。
: 嵌入式在工业界的发展，底层都不是软件推动的，做软件的好的是比较稳，对学习新知
: 识要求不迫切
: 坏处是，做的比较琐碎，积累的经验不仅过时，而且积累周期很长
: 一些简单系统调用的overhead其实还好了，现在的嵌入式系统的硬件一般也不错了，比
: 我七八年前才工作时的要强不知道多少了，很多限制已经没有那么紧了。前几年我以前
: 在国内工作的单位他们就都在板子上用c#写界面了，而且听说现在都在用c#写一些中间
|
|
|
L***s
发帖数: 1148 | 51
（1
展开说说？
复杂度跟语言不是正交的吗？
【在 b*******s 的大作中提到】
: 我说的c++11，比如以前在葵版我给的求斐波那契数列某个值比如F（20）的例子，O（1
: ）复杂度
:
: 且C
|
b*******s
发帖数: 5216 | 52 编译期决定，在编译阶段能够提示编译器进行计算，实际代码里就已经是一个常数而不
需要再次计算了
【在 L***s 的大作中提到】
:
: （1
: 展开说说？
: 复杂度跟语言不是正交的吗？
|
b*******s
发帖数: 5216 | 53 前面你都讲了多少外行话了，呵呵，还装
【在 z****e 的大作中提到】
: 很简单，这种机会就赌上你全家
: 我懂的话，你全家死绝，哈哈
|
b*******s
发帖数: 5216 | 54 现在做金融，能不能鄙视下做企业应用的？(好虫说过就是点垃圾业务逻辑，没劲)
其实嵌入式比你那块有趣
别装你在big event里面好不好
【在 z****e 的大作中提到】
: 快来围观做嵌入式的傻逼啊
: 做个鸡八猫嵌入式还觉得自己牛逼
: 傻逼到家的行当
: 你想做嵌入式就做呗，做个探阴器就可以发家致富了
: 日本那些宅男就靠你这个产品来探测妇女阴部了
: 哈哈
: 工业界压根没有人鸟底层了，底层你个大便啊
: 现在机器便宜得跟什么一样，随随便便就可以搞个东西出来
: 嵌入式你该换个行当去装逼，搞软件没有人在乎这些东西
: 因为cheap，而且越来越cheap
|
