w********s
发帖数: 1570 | |
w********s
发帖数: 1570 | |
h*******e
发帖数: 1377 | 3 不错，学习了。 不过， 工程里用的多么，这种写法我是头一次见到。 |
y**********u
发帖数: 6366 | 4 max(a,b)
【在 w********s 的大作中提到】
: rt
|
h*******e
发帖数: 1377 | 5 成都哥你看看他给的open source 视频，据说上面的方法会比较快。因为不用branch.
你怎么觉得的阿。
【在 y**********u 的大作中提到】
: max(a,b)
|
m********2
发帖数: 89 | 6 至少在arm上面 (a>b?a:b) 比这个快。
【在 w********s 的大作中提到】
: rt
|
s***i
发帖数: 503 | |
h*******e
发帖数: 1377 | 8 展开说说呢，大学的时候就记得老师说i+++++++之类的题目很无聊，结果一个当时的本
科cs师兄，还和一个cs研究生因为这个++吵了一架，居然都到要见面约架的地步了~~
【在 s***i 的大作中提到】
: 这种题很无聊。
|
z****e
发帖数: 54598 | 9 纯粹无聊，有这功夫不如去弄点程序，现在行情这么好
app成功一个，就发财了，泡沫来的时候抓紧冲浪
等泡沫退了之后再吵不迟
【在 h*******e 的大作中提到】
: 展开说说呢，大学的时候就记得老师说i+++++++之类的题目很无聊，结果一个当时的本
: 科cs师兄，还和一个cs研究生因为这个++吵了一架，居然都到要见面约架的地步了~~
|
h*******e
发帖数: 1377 | 10 。。。。app成功很容易么。。我看我们系的中国学生大牛在FLG的业余自己开公司做
app做了2年了 游戏加应用都没做出来什么呢，产品都有但是估计不怎么赚钱，后来全
职加入别人的公司做cofounder了。。新公司不是继续做app的。
【在 z****e 的大作中提到】
: 纯粹无聊，有这功夫不如去弄点程序，现在行情这么好
: app成功一个，就发财了，泡沫来的时候抓紧冲浪
: 等泡沫退了之后再吵不迟
:
:
|
|
|
r*******k
发帖数: 1423 | 11 这个算是奇技淫巧了
不过代码可读性太差了吧
而且效率不比a>b?a:b;
高啊
【在 w********s 的大作中提到】
: 没看过有人写得出来？
|
w********s
发帖数: 1570 | 12 ｃｐｕ是流水的，如果branch预测失败要排空的话，就是16个cycle
【在 r*******k 的大作中提到】
: 这个算是奇技淫巧了
: 不过代码可读性太差了吧
: 而且效率不比a>b?a:b;
: 高啊
|
r*******k
发帖数: 1423 | 13 这个不懂
你的意思是说，还是这个诡异的方法更快？
那应该写成library让大家用，不用每个人写出这种后人看不懂的东东
看了眼java的实现
不过java是跑在jvm上的，没啥可比性
/**
* Returns the greater of two {@code int} values. That is, the
* result is the argument closer to the value of
* {@link Integer#MAX_VALUE}. If the arguments have the same value,
* the result is that same value.
*
* @param a an argument.
* @param b another argument.
* @return the larger of {@code a} and {@code b}.
*/
public static int max(int a, int b) {
return (a >= b) ? a : b;
}
【在 w********s 的大作中提到】
: ｃｐｕ是流水的，如果branch预测失败要排空的话，就是16个cycle
|
w********s
发帖数: 1570 | 14 java一向慢的呀
http://gcc.gnu.org/ml/libstdc++/2003-11/msg00295.html
【在 r*******k 的大作中提到】
: 这个不懂
: 你的意思是说，还是这个诡异的方法更快？
: 那应该写成library让大家用，不用每个人写出这种后人看不懂的东东
: 看了眼java的实现
: 不过java是跑在jvm上的，没啥可比性
: /**
: * Returns the greater of two {@code int} values. That is, the
: * result is the argument closer to the value of
: * {@link Integer#MAX_VALUE}. If the arguments have the same value,
: * the result is that same value.
|
W*********y
发帖数: 481 | 15 哈哈真的假的
【在 h*******e 的大作中提到】
: 展开说说呢，大学的时候就记得老师说i+++++++之类的题目很无聊，结果一个当时的本
: 科cs师兄，还和一个cs研究生因为这个++吵了一架，居然都到要见面约架的地步了~~
|
r*******k
发帖数: 1423 | 16 神奇啊，受教了
谢谢
楼主share一下你看的啥东西吧
不过这么底层的优化，
工作中碰到的机会太少了
【在 w********s 的大作中提到】
: java一向慢的呀
: http://gcc.gnu.org/ml/libstdc++/2003-11/msg00295.html
|
S*A
发帖数: 7142 | 17 这些都是老掉牙的假设了。
现在的 CPU 有很多技巧，这种 ugly hack 已经完全没有现实意义了。
其中一个是，现在 CPU 有 conditional mov instruction。
a > b ? a : b 这种实现完全可以用没有branch 来实现的，
而且常见的 compiler 都支持了。
例如这个程序：
int d(int a, int b)
{
return a >= b? a : b;
}
$ gcc -O2 -c -S /tmp/d.c
$ cat d.s
.LFB0:
.cfi_startproc
cmpl %esi, %edi
movl %esi, %eax
cmovge %edi, %eax
ret
看到没有， gcc 自己就会用 cmov instruction。
所以 branch predict 那个理由在现在的机器就不成立。
【在 w********s 的大作中提到】
: ｃｐｕ是流水的，如果branch预测失败要排空的话，就是16个cycle
|
S*A
发帖数: 7142 | 18 看我上一篇，这个只能算丑化和慢化，
优化是算不上的。
【在 r*******k 的大作中提到】
: 神奇啊，受教了
: 谢谢
: 楼主share一下你看的啥东西吧
: 不过这么底层的优化，
: 工作中碰到的机会太少了
|
w********s
发帖数: 1570 | 19 cmov也要6个cycle了呀，看多慢
【在 S*A 的大作中提到】
: 这些都是老掉牙的假设了。
: 现在的 CPU 有很多技巧，这种 ugly hack 已经完全没有现实意义了。
: 其中一个是，现在 CPU 有 conditional mov instruction。
: a > b ? a : b 这种实现完全可以用没有branch 来实现的，
: 而且常见的 compiler 都支持了。
: 例如这个程序：
: int d(int a, int b)
: {
: return a >= b? a : b;
: }
|
S*A
发帖数: 7142 | 20 不知道不可怕，误导别人就不好了。
你的 6 cycle CMOV 是什么年代的机器啊？
要不要我来教你如何看 instruction cycle 啊？
http://www.intel.com/content/dam/www/public/us/en/documents/man
翻到 appendix C -27 页。
CMOVcc 是 2 cycle.
CMOVBE/NBE/NA 是 3 cycle。
对比一下两个实现:
return a >= b? a : b;
cmpl %esi, %edi
movl %esi, %eax
cmovge %edi, %eax
return b ^((a^b) & -(a < b));
xorl %eax, %eax
cmpl %esi, %edi
setl %al
xorl %esi, %edi
negl %eax
andl %edi, %eax
xorl %esi, %eax
就算 cmovge 是 3， 不是 1，差别是 2 ，
你的那个实现里面多了止不止 2 个instruction?
你的实现整整多了 4 个 instruction.
把代码写那么难懂，然后还要更慢，图什么啊，就是
为了 show off ？？
【在 w********s 的大作中提到】
: cmov也要6个cycle了呀，看多慢
|
g****y
发帖数: 2810 | 21 现在的游戏计算工具也不需要自己写了吧
【在 w********s 的大作中提到】
: rt
|
