d********t
发帖数: 9628 | |
c******o
发帖数: 1277 | |
z****e
发帖数: 54598 | |
d********t
发帖数: 9628 | 4 C++更正规啊
【在 c******o 的大作中提到】
: 基本上，正规化，用的人多
|
z****e
发帖数: 54598 | 5 ide烂死
没有jvm，麻烦死，什么都要自己做
自己做的各种bugs，一天到晚就给人擦屁股了
【在 d********t 的大作中提到】
: C++更正规啊
|
c******o
发帖数: 1277 | 6 版上有人争论c++怎么写，有人争论java么
java人最多 |
z****e
发帖数: 54598 | 7 也有
昨天刚讨论了static vs spring
【在 c******o 的大作中提到】
: 版上有人争论c++怎么写，有人争论java么
: java人最多
|
c******o
发帖数: 1277 | 8 他问的是语言层面的
【在 z****e 的大作中提到】
: 也有
: 昨天刚讨论了static vs spring
|
z****e
发帖数: 54598 | 9 pattern算不算？
古德霸刚刚教育了怎么用factory
不过这个可以算成是c++的
oop pattern都通用
【在 c******o 的大作中提到】
: 他问的是语言层面的
|
b*******g
发帖数: 603 | 10 static, much better performance, more libraries.
【在 d********t 的大作中提到】
: 为啥一堆人膜拜
|
|
|
n******7
发帖数: 12463 | 11 一个做software programming，一个是脚本
连我们杀老鼠的都要求c/c++/java 必须熟悉一个
然后perl/python会一个 |
d********t
发帖数: 9628 | 12 为啥static好？而且没觉得Java比Perl和Python快啊
【在 b*******g 的大作中提到】
: static, much better performance, more libraries.
|
d********t
发帖数: 9628 | 13 vim用起来很爽啊，还有boost。讲lib的话Python就很好啊。
【在 z****e 的大作中提到】
: ide烂死
: 没有jvm，麻烦死，什么都要自己做
: 自己做的各种bugs，一天到晚就给人擦屁股了
|
c******o
发帖数: 1277 | 14 这个快应该是没有什么争论吧。
java production 和 C++差不多快，有时候甚至更快 （JIT)
资源上用的多一些。
静态语言好是因为约束严，错误在compile时能抓住好多。与不容易有在production运
行时的错误。
【在 d********t 的大作中提到】
: 为啥static好？而且没觉得Java比Perl和Python快啊
|
b*******s
发帖数: 5216 | 15 性能上差别还是很大的，高频谁用java?除了一家传为笑柄的
【在 c******o 的大作中提到】
: 这个快应该是没有什么争论吧。
: java production 和 C++差不多快，有时候甚至更快 （JIT)
: 资源上用的多一些。
: 静态语言好是因为约束严，错误在compile时能抓住好多。与不容易有在production运
: 行时的错误。
|
c******o
发帖数: 1277 | 16 高频是因为GC stop the world?不是速度吧？
当然， bare metal是不一样，C/C++除了assembly 无人可比
【在 b*******s 的大作中提到】
: 性能上差别还是很大的，高频谁用java?除了一家传为笑柄的
|
h*******u
发帖数: 15326 | 17 有把gc屏蔽了，把Java当二逼用的
【在 b*******s 的大作中提到】
: 性能上差别还是很大的，高频谁用java?除了一家传为笑柄的
|
b*******s
发帖数: 5216 | 18 not exactly. our system can do an order placement in 1/1000000 seconds with
a normal HP server. If we use java, could be 1000 times slower
【在 c******o 的大作中提到】
: 高频是因为GC stop the world?不是速度吧？
: 当然， bare metal是不一样，C/C++除了assembly 无人可比
|
b*******s
发帖数: 5216 | 19 still not practical, coz you can't control your memory allocation. it is not
guaranteed to be cache friendly. a cache miss can make your operations
hundreds times slower
【在 h*******u 的大作中提到】
: 有把gc屏蔽了，把Java当二逼用的
|
b*******s
发帖数: 5216 | 20 and modern c++ is much much faster than c
【在 c******o 的大作中提到】
: 高频是因为GC stop the world?不是速度吧？
: 当然， bare metal是不一样，C/C++除了assembly 无人可比
|
|
|
n****l
发帖数: 1739 | 21 surely you're joking, mr brainless.
what is modern c++ anyway? why is it much much faster than c?
note: not previous version of c++, but plain old c.
【在 b*******s 的大作中提到】
: and modern c++ is much much faster than c
|
w******w
发帖数: 126 | 22 factory pattern 应该是很简单的pattern当中的一种了。 要搞清楚 visitor pattern
的应用场合才算对pattern 理解上升一个高度。 其实pattern 在我眼里面看来核心就
是封装， 哪里有变化，哪里就有封装！这个才是pattern的核心思想。factory
pattern 这样的构造的pattern ， 个人看来是很基本的pattern。 到了后来我感觉有
的时候 pattern 都是拉花架子，总是搞个中间类在哪里适应变化， 层层叠绕的。大多
数的时候 用functor 加上boost 里面的bind 足够了。直接应用装配，不用啥包这个
class 那个class的。想咋装配就咋装配！ 更加灵活一点。 个人意见， 望少拍砖！ ^
_^ |
d****i
发帖数: 4809 | 23 实际上plain old pure C的速度是最快的，这一点是毫无争议的，而且即便是和手写的
asm比，C也往往更快，编译器的优化已经可以做的极致，即便是在性能要求苛刻的不能
再苛刻的embedded上面，一般也不提倡手写asm, 只有一些极少数特殊的场合采用。C++
比C在ARM Linux上纯速度大概是1.2比1的样子，主要耗费在类的construct上面了和
virtual table上面了。Java则无可比性，大概差个3-5倍，不过在server上这个比例一
般不是问题。
【在 c******o 的大作中提到】
: 高频是因为GC stop the world?不是速度吧？
: 当然， bare metal是不一样，C/C++除了assembly 无人可比
|
b*******s
发帖数: 5216 | 24 a classic example, calculate fibonacci(10000) please.
modern c++ can finish it in O(1)
【在 n****l 的大作中提到】
: surely you're joking, mr brainless.
: what is modern c++ anyway? why is it much much faster than c?
: note: not previous version of c++, but plain old c.
|
d********t
发帖数: 9628 | 25 笑柄是哪家
【在 b*******s 的大作中提到】
: 性能上差别还是很大的，高频谁用java?除了一家传为笑柄的
|
d********t
发帖数: 9628 | 26 啥是GC
【在 c******o 的大作中提到】
: 高频是因为GC stop the world?不是速度吧？
: 当然， bare metal是不一样，C/C++除了assembly 无人可比
|
d****i
发帖数: 4809 | 27 garbage collection, not allowed by C and C++ since they are system level
languages thus cannot afford any bit of performance loss.
【在 d********t 的大作中提到】
: 啥是GC
|
n****l
发帖数: 1739 | 28 it is cute to do that cheating, but a more straightforward way in c
is to construct a lookup table, which is O(1) and can be more
flexible at runtime than c++ template metaprogramming if such need
rises.
【在 b*******s 的大作中提到】
: a classic example, calculate fibonacci(10000) please.
: modern c++ can finish it in O(1)
|
d****i
发帖数: 4809 | 29 Or more precisely, when you program in C and C++, you actually want to have
full control of memory management by YOU as a programmer rather than
automatically managed by GC.
【在 d****i 的大作中提到】
: garbage collection, not allowed by C and C++ since they are system level
: languages thus cannot afford any bit of performance loss.
|
b***e
发帖数: 17 | 30 因为一堆人是全堆程序员，除了Java啥也学不会。这"堆“人基本来自某南亚国家。
【在 d********t 的大作中提到】
: 为啥一堆人膜拜
|
|
|
b*******s
发帖数: 5216 | 31 do you understand the downside of your solution?
if I want some values between F(1) and F(10000)
you should keep a large lookup table. and it is not cache friendly
the best idea from c++ is: you dont use, you dont pay for it
【在 n****l 的大作中提到】
: it is cute to do that cheating, but a more straightforward way in c
: is to construct a lookup table, which is O(1) and can be more
: flexible at runtime than c++ template metaprogramming if such need
: rises.
|
b*******s
发帖数: 5216 | 32 c++ now has light weight gc. or said smart pointers
auto release is no longer a problem
【在 d****i 的大作中提到】
: garbage collection, not allowed by C and C++ since they are system level
: languages thus cannot afford any bit of performance loss.
|
n****l
发帖数: 1739 | 33 i never thought modern c++ bloat is cache friendly to begin with.
so how is your c++ version solving this precise issue if it can even solve
it at all dynamically at runtime?
【在 b*******s 的大作中提到】
: do you understand the downside of your solution?
: if I want some values between F(1) and F(10000)
: you should keep a large lookup table. and it is not cache friendly
: the best idea from c++ is: you dont use, you dont pay for it
|
d****i
发帖数: 4809 | 34 Smart pointer isn't GC at all. For the code I have ever encountered, smart
pointers in C++ are used sparsely particularly on server side . But for
other use cases such as embedded system, Android, iOS, RTOS,... whatsoever,
they are never used.
【在 b*******s 的大作中提到】
: c++ now has light weight gc. or said smart pointers
: auto release is no longer a problem
|
b*******s
发帖数: 5216 | 35 Okay I will give you an example. Suppose you have already known something
about meta programming.
If I want to use F(1) F(1000) and F(10000) in my application. Maybe like
this,
constexpr int64_t val = F(1) + F(1000) + F(10000);
Do you think there any cache issue? No, obviously
And F(1) F(1000) F(10000) are in different cache lines in your solution.
Or you should design a complicated hash function.
We don't like runtime things. That's modern c++
【在 n****l 的大作中提到】
: i never thought modern c++ bloat is cache friendly to begin with.
: so how is your c++ version solving this precise issue if it can even solve
: it at all dynamically at runtime?
|
b*******s
发帖数: 5216 | 36 hmmm... exactly. It is not. But do its job pretty well. As good as a GC but
affordable.
【在 n****l 的大作中提到】
: i never thought modern c++ bloat is cache friendly to begin with.
: so how is your c++ version solving this precise issue if it can even solve
: it at all dynamically at runtime?
|
b*******s
发帖数: 5216 | 37 and we cant avoid some silly context switching with Java. another reason we
don't like it. it is a so expensive penalty.
All silly "c++ vs java" benchmarks are single threaded and written by Java
programmers. LOL |
w******w
发帖数: 126 | 38 高频交易主要focus 在 low latency。不是说大并发就是高频，追求的是反应时间。在
追求这个latency 的问题上，有os 都闲慢，更别说啥语言不语言了。像啥JMS 这样的
message传送机制，在高频交易当中就可以当作个笑话了。追求low latency吗？ 硬件
直接来！你软件再怎么快也跟硬件还是查一个数量级吧？ os 怎么也要从kernel 到
user space的转换， 这个时间人家都省下来了。 |
b*******g
发帖数: 603 | 39 所以这就叫井底观天，Java不适合实时应用是事实，C++还不适合网络应用呢。总有傻
逼做个高频就觉得天就这么大了, Java是笑话，哪怕最基本的数据库概念都没有。
【在 w******w 的大作中提到】
: 高频交易主要focus 在 low latency。不是说大并发就是高频，追求的是反应时间。在
: 追求这个latency 的问题上，有os 都闲慢，更别说啥语言不语言了。像啥JMS 这样的
: message传送机制，在高频交易当中就可以当作个笑话了。追求low latency吗？ 硬件
: 直接来！你软件再怎么快也跟硬件还是查一个数量级吧？ os 怎么也要从kernel 到
: user space的转换， 这个时间人家都省下来了。
|
z****e
发帖数: 54598 | 40 直接上汇编吧
硬件让你用啥指令你就用啥指令
平台永远是老大
【在 w******w 的大作中提到】
: 高频交易主要focus 在 low latency。不是说大并发就是高频，追求的是反应时间。在
: 追求这个latency 的问题上，有os 都闲慢，更别说啥语言不语言了。像啥JMS 这样的
: message传送机制，在高频交易当中就可以当作个笑话了。追求low latency吗？ 硬件
: 直接来！你软件再怎么快也跟硬件还是查一个数量级吧？ os 怎么也要从kernel 到
: user space的转换， 这个时间人家都省下来了。
|
