G**Y
发帖数: 33224 | |
T***1
发帖数: 445 | 2 应该是吧。这方面自动优化（java）比不上人脑优化（c++） |
G**Y
发帖数: 33224 | 3 这么说C++永远不会退役呀。
至少科学计算的，要么R/Matlab，要么就C/C++了（甚至fortran），但是Java较少。
【在 T***1 的大作中提到】
: 应该是吧。这方面自动优化（java）比不上人脑优化（c++）
|
c******o
发帖数: 1277 | 4 不一定，其实99.99% 的 gc会比你做得更好。 |
G**Y
发帖数: 33224 | 5 问题是用C++的目标是不生产垃圾呀。当然，这个debug非常痛苦。
看哪个阶段了，很多时候搞计算的只用C++写最核心的部分，那么#LOC相对小。还可以
控制。
我跟一个搞Visualization的CS聊天，他说别的语言都不够快。而且不好tweak low
lower的东西。不过他们也是research。不是做产品。
【在 c******o 的大作中提到】
: 不一定，其实99.99% 的 gc会比你做得更好。
|
g*****y
发帖数: 7271 | 6 是什么标准下，GC做得更好？
做得那么好，为什么不把其它resource都一起管起来呢？
我一直以为是因为内存够cheap，回收快慢无所谓，所以才
GC盛行的呢。哈哈
【在 c******o 的大作中提到】
: 不一定，其实99.99% 的 gc会比你做得更好。
|
N******K
发帖数: 10202 | 7 c++的也算gc 半自动而已
【在 c******o 的大作中提到】
: 不一定，其实99.99% 的 gc会比你做得更好。
|
c******o
发帖数: 1277 | 8 在一定缓冲的情况下 (不是那种embedded device, minimum memory), 没有特别要求
（ 必须保证在特定latency之类）
一般GC都比人控制好。
当然极端最佳，肯定是manual 控制在任何情况下都好，但是第一是没人能一直做到极
端最佳,第二是GC又更多runtime的信息。
【在 g*****y 的大作中提到】
: 是什么标准下，GC做得更好？
: 做得那么好，为什么不把其它resource都一起管起来呢？
: 我一直以为是因为内存够cheap，回收快慢无所谓，所以才
: GC盛行的呢。哈哈
|
j*****8
发帖数: 3635 | 9 又要速度，又要自动化管理内存，哪有那么完美的阿。这中间就得有一个平衡
而且现在concurrent gc效率已经不错了 |
S**I
发帖数: 15689 | 10 C++当然不会退役，不过基本上也只能在现有的几块自留地里折腾了。
【在 G**Y 的大作中提到】
: 这么说C++永远不会退役呀。
: 至少科学计算的，要么R/Matlab，要么就C/C++了（甚至fortran），但是Java较少。
|
k**********g
发帖数: 989 | 11
做到极端最佳
that's my job ...
【在 c******o 的大作中提到】
: 在一定缓冲的情况下 (不是那种embedded device, minimum memory), 没有特别要求
: （ 必须保证在特定latency之类）
: 一般GC都比人控制好。
: 当然极端最佳，肯定是manual 控制在任何情况下都好，但是第一是没人能一直做到极
: 端最佳,第二是GC又更多runtime的信息。
|
g*****y
发帖数: 7271 | 12 加了这么多限制，剩下的怎么个“好”法？我能理解的好处只有
帮programmer省点事一项了。
【在 c******o 的大作中提到】
: 在一定缓冲的情况下 (不是那种embedded device, minimum memory), 没有特别要求
: （ 必须保证在特定latency之类）
: 一般GC都比人控制好。
: 当然极端最佳，肯定是manual 控制在任何情况下都好，但是第一是没人能一直做到极
: 端最佳,第二是GC又更多runtime的信息。
|
c****p
发帖数: 6474 | 13 我记得某研究说程序占用的内存超过物理内存一定比例之后GC的性能就开始下降的。。 |
t*****n
发帖数: 4908 | 14 马工除了做网站，还有很多干其他的。当C++在玩腻了sse优化，gpu计算的时候，其他
语言还不知道在哪里做梦那。
【在 G**Y 的大作中提到】
: 这么说C++永远不会退役呀。
: 至少科学计算的，要么R/Matlab，要么就C/C++了（甚至fortran），但是Java较少。
|
