n****1
发帖数: 1136 | 1 1. ref count其实只是GC strategy的一种, 而且是非常普遍的一种. 所以zhaoce拿ref
count来说事是很不妥的.
"Tracing and reference counting are uniformly viewed as being fundamentally
different approaches to garbage collection that possess very distinct
performance properties. [...] they are in fact duals of each other. [...]
all high-performance collectors [...] are in fact hybrids of tracing and
reference counting."
2. 内存管理策略有很多种,GC(包括ref count)只是最无脑的一种. 其他的策略往往是
根据具体模型的特点, 在适当的时候高效地申请和释放内存. 内存池就是典型的例子.
java直接rule out这种可能性.
不要老说内存管理不重要, 很多代码最核心的目的就是高效管理内存, 以达到高性能.
还有就是跑在客户端的程序内存占用越小越好, 这其实是很多人粉iOS贬android的原因.
3. 其实内存不过是一种特殊的资源罢了, 程序员除了管内存之外, 还有很多资源要管
理, 譬如file descriptor, 打开了一个descriptor, jvm不会自动关的, 所以不管是C+
+还是java都要手动管理file descriptor. 从这个角度来看, C++的RAII思想是很先进
的.
4. C++手动管理内存, 的却可以做到stack allocation, 提高cache利用率, 可是手动
管理内存也是基于某种策略的, 如果我们能把策略告诉机器, jvm就能利用起来, 达到
比naive GC更好的方式.
举个例子, java 7里面的escape analysis就可以自动分析出那些object是适合stack
allocation的. 如果程序员在java里能尽量使用immutable变量, 编译器就能更好地做
好static analysis, 从而提高运行效率.(这个当然很难做到, 不喜勿喷) |
z****e
发帖数: 54598 | 2 我的意思就是因为最普遍的一种，所以不怎样
java的jvm从根本上就不用这种机制
因为缺点太明显了
c++内存管理最大问题还不在这里
而是小菊花说的，不知道哪个屎坑出了问题
经常是你管一块，我管一块，互相之间老死不相往来
你也不知道对方会不会出问题，除非你读懂了别人的代码
别人也不知道你会不会出问题，除非读懂了你的代码
所以乱七八糟，最好的方式就是集中管理
那集中管理就是java的管理方式，也就是越做越象java
你看fb就大概明白了，php一开始编译成c++代码以提升效率
然后呢？hhvm，hhvm就是jvm的那种模式了
你说优化，我不否认可以优化，但是是否有必要优化呢？
随着机器性能的提升，需要优化的地方肯定是越来越少的
所以即便你懂优化，你也要明白，这一块是越来越不需要你亲自动手去做的
就像java以前还有对于new class的优化
ejb和spring很多设想就是建立在尽可能减少类加载的时间消耗上
但是现在，我这台laptop，一秒可以new 10^4个class
你说优化了干什么？所以结构往往重要性要优于效率，在绝大多数时候
其实要谈效率，这个主要是硬件上要支持
如果硬件上不支持，你软件怎么做管理都是扯淡的
real time如果cpu不支持，软件没法做
但是硬件本身又是一个夕阳产业，越做越没有利润
ibm当年靠卖机器来了个巨额亏损，吓坏了，赶紧转行做软件
才从当年的亏损中给拉出来，hp就没有改，还在坚持卖机器
当年hp和ibm是并列的两大巨头，今天hp已经快被淘汰了吧？ |
z****e
发帖数: 54598 | 3 我觉得人不能刻舟求剑
过去机器性能差，要各种折腾，因为不折腾不行
现在，就不要再拿过去的眼光来审视今天的机器了
今天各种发展起来了，不折腾完全可以
瞄准赚钱就好了，社会需要你做什么，你就去做什么
不要闭门造车，也不要想当然地以为什么东西最牛逼
我不否认有些东西牛逼，但是社会需求是另外一回事
我说的一切都是以搞定问题，拿到工资奖金
赶紧回家抱老婆睡觉生孩子为首要目的的
讨论怎么写出更牛逼的代码，不是首要目的 |
n****1
发帖数: 1136 | 4 因为C/C++内存管理混乱, 所以你就认为所有程序都该采用最傻逼的管理方式?
你说硬件是夕阳产业, 我还说web是夕阳产业呢, 现在这个web泡沫确实大, 可十年后
web能否像现在这么火很难说的.
【在 z****e 的大作中提到】
: 我的意思就是因为最普遍的一种，所以不怎样
: java的jvm从根本上就不用这种机制
: 因为缺点太明显了
: c++内存管理最大问题还不在这里
: 而是小菊花说的，不知道哪个屎坑出了问题
: 经常是你管一块，我管一块，互相之间老死不相往来
: 你也不知道对方会不会出问题，除非你读懂了别人的代码
: 别人也不知道你会不会出问题，除非读懂了你的代码
: 所以乱七八糟，最好的方式就是集中管理
: 那集中管理就是java的管理方式，也就是越做越象java
|
z****e
发帖数: 54598 | 5 显然我们可以考虑更优的gc方式啊
jvm的那种gc方式就很不错
这里面还有lars bak的好几项专利
其他语言就是想出来了
抄都不让抄
lars bak搞了一个v8，你看多少人说快
hotspot也就是这个家伙搞的
所以vert.x用hotspot，性能就比用了v8的nodejs要快
就是这个道理
这个其实那个软轮里面有一个hotspot2012还是2013的
比较懂
web是有泡沫，但是新兴的东西就是这样
一开始总有一个很高的预期，然后砸下来
再慢慢回暖，其实web泡沫最高是在02年.com泡沫时代
后来破灭了，现在只能说是逐步回暖罢了
那是不是有新一轮泡沫，这个用老魏的话说就是
下一个big thing是什么，大家都在思考
坑王的名言：我不禁陷入了沉思
【在 n****1 的大作中提到】
: 因为C/C++内存管理混乱, 所以你就认为所有程序都该采用最傻逼的管理方式?
: 你说硬件是夕阳产业, 我还说web是夕阳产业呢, 现在这个web泡沫确实大, 可十年后
: web能否像现在这么火很难说的.
|
n****1
发帖数: 1136 | 6 其实我希望看到JVM里能提供AOP式的内存管理, 默认采用GC管理, 但程序员可以选择其
他策略.
至于这些与业务逻辑无关的内存管理策略应该通过AOP的形式放到其他地方, 不和主代
码混在一起就可以了. |
n****1
发帖数: 1136 | 7 如果某些情况能够使用内存池, 无论你用啥GC, 性能都会差好几倍甚至数量级.
【在 z****e 的大作中提到】
: 显然我们可以考虑更优的gc方式啊
: jvm的那种gc方式就很不错
: 这里面还有lars bak的好几项专利
: 其他语言就是想出来了
: 抄都不让抄
: lars bak搞了一个v8，你看多少人说快
: hotspot也就是这个家伙搞的
: 所以vert.x用hotspot，性能就比用了v8的nodejs要快
: 就是这个道理
: 这个其实那个软轮里面有一个hotspot2012还是2013的
|
z****e
发帖数: 54598 | 8 jvm最早就是hotspot
然后庄思浩他们独立出来搞bea之后
就是照搬hotspot的构架搞出了jrockit
后来oracle吞并了bea和sun
然后oracle又说服了ibm和apple搞openjdk
然后oracle自身把jrokit贡献出一部分代码来给openjdk
同时还有sap和red hat也都开始参与进来
这样几大it公司通过联合搞openjdk来对hotspot做一个预防
就是防止oracle耍流氓
其实虚拟机的优化这些东西跟oop是一脉相承的
最早oop由smalltalk实现
然后有个人看好oop，但是当时oop的效率偏低
于是搞出了strongtalk，言外之意就是要强化优化这里面的效率
后来这家公司被sun吞并了，然后jg搞c++搞不下去
怒了
于是正好又遇到这群人，于是这群人就搞出了java的第一个虚拟机hotspot出来
然后就是这个帖子前面的内容了 |
z****e
发帖数: 54598 | 9 我不否认，我只能说随着时间的推移以及机器性能的提升
这种情况会逐步减少
gc的确是一个问题，但是仅仅因为要gc，而推而广之要求所有人都理解这个概念
那这个显然是错的，这就是猴屁股的错误，它就认为应该要求所有人都明白了才能动手
那这样没办法，等不起，老板有压力，要赶紧出活
【在 n****1 的大作中提到】
: 如果某些情况能够使用内存池, 无论你用啥GC, 性能都会差好几倍甚至数量级.
|
z****e
发帖数: 54598 | 10 aop是另外一种paradigm
比oop还要难以理解
一般c++程序员理解一个oop都要半天
当然这对于其他程序员来说也是如此
更不要说加一个aop上去了
paradigm其实越多，越容易乱，容易吵架
c++可以做aop，但是其实aop用得比较多得还是java
但是这个比较多是相对而言，实际上aop整体用得很少
我倒是灰常喜欢aop，但是同事没几个会的
【在 n****1 的大作中提到】
: 其实我希望看到JVM里能提供AOP式的内存管理, 默认采用GC管理, 但程序员可以选择其
: 他策略.
: 至于这些与业务逻辑无关的内存管理策略应该通过AOP的形式放到其他地方, 不和主代
: 码混在一起就可以了.
|
|
|
n****1
发帖数: 1136 | 11 AOP其实是monad的代名词, 熟了就很容易理解了.
C++的template所能达到的meta programming是很牛逼了, 用好了template, 实现AOP是
小菜一叠.
【在 z****e 的大作中提到】
: aop是另外一种paradigm
: 比oop还要难以理解
: 一般c++程序员理解一个oop都要半天
: 当然这对于其他程序员来说也是如此
: 更不要说加一个aop上去了
: paradigm其实越多，越容易乱，容易吵架
: c++可以做aop，但是其实aop用得比较多得还是java
: 但是这个比较多是相对而言，实际上aop整体用得很少
: 我倒是灰常喜欢aop，但是同事没几个会的
|
z****e
发帖数: 54598 | 12 fp也是一种paradigm啊
我觉得很多程序员paradigm弄多了真的不行
思维方式不一样，太经常转变思维会神经错乱的
同一个组内部我坚决反对用不同的paradigm搭配
如果有不同的paradigm需求，分开不同的组去做
比如支持的组用aop蛮好
对于gc这事，我记得买买提上一度有一种风潮
不少c++程序员开始关注jvm，决定挑战一下高难度
问我意见，我直接回邮件，openjdk，去看吧
然后……
目测是没有然后了
至少我没看到什么像样的东西出来
【在 n****1 的大作中提到】
: AOP其实是monad的代名词, 熟了就很容易理解了.
: C++的template所能达到的meta programming是很牛逼了, 用好了template, 实现AOP是
: 小菜一叠.
|
n****1
发帖数: 1136 | 13 没错, 所以我支持C++彻底做掉OOP, 然后就再没有C++ vs java了, 世界就清净了:)
说正经的, 如果只是为了转专业糊个口, 当然用不着multi-paradigm, 但见多识广绝对
是对职业有利的. 您老就别把"C++最烂"这种话说得那么死了.
【在 z****e 的大作中提到】
: fp也是一种paradigm啊
: 我觉得很多程序员paradigm弄多了真的不行
: 思维方式不一样，太经常转变思维会神经错乱的
: 同一个组内部我坚决反对用不同的paradigm搭配
: 如果有不同的paradigm需求，分开不同的组去做
: 比如支持的组用aop蛮好
: 对于gc这事，我记得买买提上一度有一种风潮
: 不少c++程序员开始关注jvm，决定挑战一下高难度
: 问我意见，我直接回邮件，openjdk，去看吧
: 然后……
|
z****e
发帖数: 54598 | 14 c++本身到底是什么paradigm有定论么？
它自己说是oop，但是一堆人写成了其他各种乱七八糟的paradigm
java倒是比较纯粹的oop，要做aop或者fp这些你要做点额外的操作
所以这样可以防止一般的java程序员滥用其他的p
paradigm只是一种手段，不是目的啊
多种paradigm我主要不明白为的是实现什么目的？
【在 n****1 的大作中提到】
: 没错, 所以我支持C++彻底做掉OOP, 然后就再没有C++ vs java了, 世界就清净了:)
: 说正经的, 如果只是为了转专业糊个口, 当然用不着multi-paradigm, 但见多识广绝对
: 是对职业有利的. 您老就别把"C++最烂"这种话说得那么死了.
|
g*****g
发帖数: 34805 | 15 The performance gain on C++ over Java comes from startup time, JIT warm up,
JIt binary code compilation, but not memory reclamation. As a matter of fact
, Java memory reclamation would be faster than C++ unless you work hard to
optimize memory reclamation on C++ side. The reason is because:
1. Java runs garbage collection on a separate thread or threads, C++ code
typically runs in the main thread. In a multicore environment as the
commonplace today. Java has the advantage.
2. When CPUs are loaded, JVM can delay GC by running it on a lower priority,
and later batch cleanup memory when CPU load are lower. C++ doesn't have
that luxury.
3. JVM has the holistic view of memory usage, it knows how long a block has
been there thus it can make educated guess and reduce memory segmentation.
It has the concept of generation, and manual C++ GC doesn't.
ref
fundamentally
.
【在 n****1 的大作中提到】
: 1. ref count其实只是GC strategy的一种, 而且是非常普遍的一种. 所以zhaoce拿ref
: count来说事是很不妥的.
: "Tracing and reference counting are uniformly viewed as being fundamentally
: different approaches to garbage collection that possess very distinct
: performance properties. [...] they are in fact duals of each other. [...]
: all high-performance collectors [...] are in fact hybrids of tracing and
: reference counting."
: 2. 内存管理策略有很多种,GC(包括ref count)只是最无脑的一种. 其他的策略往往是
: 根据具体模型的特点, 在适当的时候高效地申请和释放内存. 内存池就是典型的例子.
: java直接rule out这种可能性.
|
z****e
发帖数: 54598 | 16 我这两天在看vert.x用的各种脚本引擎
比如jruby, jython还有rhino这些
感觉最强烈的一点就是
这些脚本语言，在讨论他们类似why jython rather than cpython的时候
都明确说，用了jvm的gc
也就是说jvm的gc机制比这些语言搞的，那是要强到不知道哪里去了
我相信能做出cpython这种东西的人是大牛
如果这些专业人士做出来的gc都不如jvm的gc
我更没有理由去相信其他人了能写出更好的gc机制了
我现在大概理解为什么hotspot2012曾经说过
其他语言的gc，优化好了，也就是比jvm慢几倍而已
甚至比jvm慢两倍都做不到
关于优化的话，静态类型是必须的，v8对于js的优化
做到极致，再往后，不静态不行啊 |
q*c
发帖数: 9453 | 17 只能更火。
信息时代。。。。，才刚开始。现在不是泡沫，而是一个大时代的前夜。
【在 n****1 的大作中提到】
: 因为C/C++内存管理混乱, 所以你就认为所有程序都该采用最傻逼的管理方式?
: 你说硬件是夕阳产业, 我还说web是夕阳产业呢, 现在这个web泡沫确实大, 可十年后
: web能否像现在这么火很难说的.
|
b*******s
发帖数: 5216 | 18 讲得蛮好的，我也补充一点
c++的设计原则就是非必要不进入语言特性，所以相比别的，轮子不够多，需要大家自
己做轮子，不过11标准后大幅度改善了，生产力有提高，常见的各种容器，算法，i/o
，正则等等都支持了，但是怎么提高也不会达到点点鼠标那么方便，生产效率还是低的
。微软是试图用ide来帮助，但是大多数linux程序员还是喜欢vim这样的，说明思路上c
++程序员不是对生产率很敏感。
c++总有一天会退出历史舞台，比如有一天量子计算机成熟了，cpu bound永远消失了，
那时就鞠躬下台，没什么不好的，如果不这样，软件工业才是让人失望，也做不到给大
家带来机遇
目前，有志于复杂系统和底层设计的程序员，我觉得还是有必要学一点c++的，因为c++
是支持paradigm非常多的一种语言，对于开拓思路很有好处，像异步之类，c++程序员
可能会感到很奇怪前端程序员那么激动，像我现在公司00年代的老代码里，就有这样的
机制了。c++不是纯oo语言，所以各种静态语言的特性，往往都能插一手
我现在写c++也少了，大多数用python和一些别的，不过c++依然是我觉得最有魅力的语言
另外顺便提一下 stack allocation不是c++的惯用做法，因为stack 有限，大多数还是
在heap上分配和管理内存，有兴趣你可以看看stl的源代码实现。
ref
fundamentally
.
【在 n****1 的大作中提到】
: 1. ref count其实只是GC strategy的一种, 而且是非常普遍的一种. 所以zhaoce拿ref
: count来说事是很不妥的.
: "Tracing and reference counting are uniformly viewed as being fundamentally
: different approaches to garbage collection that possess very distinct
: performance properties. [...] they are in fact duals of each other. [...]
: all high-performance collectors [...] are in fact hybrids of tracing and
: reference counting."
: 2. 内存管理策略有很多种,GC(包括ref count)只是最无脑的一种. 其他的策略往往是
: 根据具体模型的特点, 在适当的时候高效地申请和释放内存. 内存池就是典型的例子.
: java直接rule out这种可能性.
|
g*****g
发帖数: 34805 | 19 web被 mobile抢去不少。但后端是一样的。
【在 q*c 的大作中提到】
: 只能更火。
: 信息时代。。。。，才刚开始。现在不是泡沫，而是一个大时代的前夜。
|
a***a
发帖数: 1879 | 20 记得GC有时候要挂起所有线程.
,
fact
priority,
【在 g*****g 的大作中提到】
: The performance gain on C++ over Java comes from startup time, JIT warm up,
: JIt binary code compilation, but not memory reclamation. As a matter of fact
: , Java memory reclamation would be faster than C++ unless you work hard to
: optimize memory reclamation on C++ side. The reason is because:
: 1. Java runs garbage collection on a separate thread or threads, C++ code
: typically runs in the main thread. In a multicore environment as the
: commonplace today. Java has the advantage.
: 2. When CPUs are loaded, JVM can delay GC by running it on a lower priority,
: and later batch cleanup memory when CPU load are lower. C++ doesn't have
: that luxury.
|
|
|
z****e
发帖数: 54598 | 21 忘了说一点
java对于file system的管理
的确是要打开关闭各种stream
however
java对于file system的管理
是交给database去做
db管理数据的persistence远比你自己打开关闭file要有效率
所以建立一个对db的统一接口就显得尤为重要起来
这就是著名的jdbc
然后通过建立连接池的方式来优化连接效率
这样就基本上能满足了大多数企业的需要了
后期在这个基础之上又发展出了nosql那些
楼主，其实我一直想说一点
你应该看看j2ee，尤其是j2ee里面各种组件的定义
j2ee的理念很先进，明显比同期其他语言要高n个时代，你说的很多问题
我现在看vert.x什么，怎么看怎么像是一个简化的ejb
甚至container什么概念，一模一样，包括event bus也是工作流的简化版
java本身只是起步，j2ee对于java programmer来说
则是一个training，一个从new grad.转换到一个合格的程序员的过程
会java就好比一个人应召入伍前会打枪一样，是个美国人都会开枪
但是j2ee的训练，则是入伍之后的各种训练，训练一个只会开枪的莽夫成长为一个合格
的战士
然后才能上阵杀敌，j2ee里面对于线程的管理，持久化的管理等都有明确的定义
能够回答你大部分问题，可以让你对软件工程的理解深入很多
不再流于表面，不管什么backend软件，做到后面，都越做越象sun那些东西
sun和今天google，说白了，都是stanford这个大学的校办工厂 |
z****e
发帖数: 54598 | 22 一个经过训练的程序员，一般看到什么资源没有被管理起来
就会去找一个东西来管
比如看到数据没有被管，就会去找数据库来管
看到内存，就找jvm来管，看到cpu就找os来管
包括java本身，java beans都会交给各种container去管
说到底，都是轮子，然后讨论最多的是哪种轮子更有效率
跟车版很接近了，话说德国的坦克是比小日本的纸皮要强很多
著名的dsb是车版哪个派系的？
这就跟你指挥打战一样
软件就是你的部队，你的手下必需有严格的编制
确保你在需要的时候能够通过某一种方式找到你所需要的资源
并且调动这个资源以达到你所想要达到的目的
而要做到这一切，没有管理是不行的
这就是软件工程的全部内容 |
n****1
发帖数: 1136 | 23 >>c++程序员可能会感到很奇怪前端程序员那么激动
这个我也有同感, 很多程序员看到些新框架就欣喜若狂或一惊一乍的, 本质是因为对底
层不熟, 只会套别人的东西, 也就根本没想过没有这些东西是怎么实现的.
我觉得靠语言来区分水平是很傻的, 最关键是看人是否能对自己所用的东西知其所以然
,而不是盲目接受. 如果老中都做不到这一点, 那就和烙印没啥区别了.
++
【在 b*******s 的大作中提到】
: 讲得蛮好的，我也补充一点
: c++的设计原则就是非必要不进入语言特性，所以相比别的，轮子不够多，需要大家自
: 己做轮子，不过11标准后大幅度改善了，生产力有提高，常见的各种容器，算法，i/o
: ，正则等等都支持了，但是怎么提高也不会达到点点鼠标那么方便，生产效率还是低的
: 。微软是试图用ide来帮助，但是大多数linux程序员还是喜欢vim这样的，说明思路上c
: ++程序员不是对生产率很敏感。
: c++总有一天会退出历史舞台，比如有一天量子计算机成熟了，cpu bound永远消失了，
: 那时就鞠躬下台，没什么不好的，如果不这样，软件工业才是让人失望，也做不到给大
: 家带来机遇
: 目前，有志于复杂系统和底层设计的程序员，我觉得还是有必要学一点c++的，因为c++
|
h*****a
发帖数: 1718 | 24 跟我猜的差不多。
【在 q*c 的大作中提到】
: 只能更火。
: 信息时代。。。。，才刚开始。现在不是泡沫，而是一个大时代的前夜。
|
