n******7
发帖数: 12463 | 1 这牛皮是不是吹爆了？别人要看代码他说卖掉了。
Case study: QR decomposition This is a basic numerical method from linear
algebra provided by libraries like LAPACK. The reference LAPACK
implementation is 2,077 lines of Fortran. I wrote an F# implementation in
under 80 lines of code that achieves the same level of performance. But the
reference implementation is not fast: vendor-tuned implementations like
Intel's Math Kernel Library (MKL) are often 10x faster. Remarkably, I
managed to optimize my F# code well beyond the performance of Intel's
implementation running on Intel hardware whilst keeping my code under 150
lines of code and fully generic (it can handle single and double precision,
and complex and even symbolic matrices!): for tall thin matrices my F# code
is up to 3× faster than the Intel MKL.
stackoverflow的链接见二楼 |
n******7
发帖数: 12463 | |
n******7
发帖数: 12463 | 3 后面有个国人哥们儿朱印说：
Here are two examples I can share:
1. Matrix multiplication: I have a blog post comparing different matrix
multiplication implementations.
2. LBFGS
I have a large scale logistic regression solver using LBFGS optimization,
which is coded in C++. The implementation is well tuned. I modified some
code to code in C++/CLI, i.e. I compiled the code into .Net. The .Net
version is 3 to 5 times slower than the naive compiled one on different
datasets. If you code LBFGS in F#, the performance can not be better than C+
+/CLI or C#, (but would be very close).
I have another post on Why F# is the language for data mining, although not
quite related to the performance issue you concern here, it is quite related
to scientific computing in F#.
这个牛逼说：
This is not true: "If you code LBFGS in F#, the performance can not be
better than C++/CLI or C#, (but would be very close).". This is exactly the
kind of application where F# can be a lot faster than C#.
-----
No, the main benefit of inline in F# is not that it removes the overhead of
function calls but, rather, that it causes the CLR to type-specialize your
code. If your LBFGS is only handling float array or vector inputs and
outputs then you have type specialized it by hand for one particular case
and that has made it much less useful. A general-purpose BFGS implementation
should read its input and write its output directly in the user's data
structures using functions that the user supplies. F# has a huge performance
advantage over C# here.
我具体不懂，但是还是觉得牛逼要爆了。哪位大牛点评一下？ |
S****8
发帖数: 401 | 4 LAPACK层的性能现在几乎完全取决于底层BLAS的性能，LAPACK的算法层的算法都是基本
固定了
这哥们除非在lapack层作出重大变化，否则干不过MKL的blas+lapack，但是能在LAPACK算
法层做重大优化的，估计能去mit当叫兽了 |
g****t
发帖数: 31659 | 5 他可以优化多核调度。不一定走改进加减乘除的路线。
: LAPACK层的性能现在几乎完全取决于底层BLAS的性能，LAPACK的算法层的算法都
是基本
: 固定了
: 这哥们除非在算法层作出重大变化，否则干不过MKL的blas lapack，但是能在
LAPACK算
: 法层做重大优化的，估计能去mit当叫兽了
【在 S****8 的大作中提到】
: LAPACK层的性能现在几乎完全取决于底层BLAS的性能，LAPACK的算法层的算法都是基本
: 固定了
: 这哥们除非在lapack层作出重大变化，否则干不过MKL的blas+lapack，但是能在LAPACK算
: 法层做重大优化的，估计能去mit当叫兽了
|
g****t
发帖数: 31659 | 6 他说的有一定道理。现有成熟的矩阵库并不是单方面追求速度的。predictable 也很重
要。另外调用的over head改进下是可能的。
最后over all来讲， F#很快。编译型FP都不慢。
: 后面有个国人哥们儿朱印说：
: Here are two examples I can share:
: 1. Matrix multiplication: I have a blog post comparing different
matrix
: multiplication implementations.
: 2. LBFGS
: I have a large scale logistic regression solver using LBFGS
optimization,
: which is coded in C . The implementation is well tuned. I modified
some
: code to code in C /CLI, i.e. I compiled the code into .Net. The .Net
: version is 3 to 5 times slower than the naive compiled one on
different
: datasets. If you code LBFGS in F#, the performance can not be better
than C
【在 n******7 的大作中提到】
: 后面有个国人哥们儿朱印说：
: Here are two examples I can share:
: 1. Matrix multiplication: I have a blog post comparing different matrix
: multiplication implementations.
: 2. LBFGS
: I have a large scale logistic regression solver using LBFGS optimization,
: which is coded in C++. The implementation is well tuned. I modified some
: code to code in C++/CLI, i.e. I compiled the code into .Net. The .Net
: version is 3 to 5 times slower than the naive compiled one on different
: datasets. If you code LBFGS in F#, the performance can not be better than C+
|
o**o
发帖数: 3964 | 7 扯蛋的事。。
多半是Fortran或者C++参考编译器设置有问题或者没有用新CPU特性，比较不公平 |
S****8
发帖数: 401 | 8 玩毛的多核调度，mkl对自家多核向量架构的支持别人根本玩不过，您老的知识停留在
十年前. 以现在的处理器架构跟mkl的成熟度，不可能再出Goto类似的人物了
【在 g****t 的大作中提到】
: 他可以优化多核调度。不一定走改进加减乘除的路线。
:
:
: LAPACK层的性能现在几乎完全取决于底层BLAS的性能，LAPACK的算法层的算法都
: 是基本
:
: 固定了
:
: 这哥们除非在算法层作出重大变化，否则干不过MKL的blas lapack，但是能在
: LAPACK算
:
: 法层做重大优化的，估计能去mit当叫兽了
:
|
|
g****t
发帖数: 31659 | 9 1.
你应该找找10年EE版我讲电源的贴。那时候很多人和你现在的说法都是类似的。几年过
去技术换代，我可以肯定他们所在的公司都在这个圈子消失了。
后来出现的intc turbo boost 的项目，以及最近新闻说的某手机CPU变慢。这些算法相
关部分最早是我写。然后我司business man拿去做生意。现在我们组维护的人也是我培
训的。
2.
自己写多核调度可以提高矩阵运算。原因很简单，mill 优化的assumption不是
在specific的用户层。你的程序知道自己要做什么，所以根据多余的信息，完全可能你
可以进一步优化。
3.
另外回到F#,
FFTW is arguably the world's fastest Fourier transform implementation and is
used in many commercial applications including MATLAB as well as being
freely available and prepackaged for almost all Linux distributions. The FFT
routines that make up the FFTW library are C code generated by an OCaml
program called genfft.
143,802 registered installs on Debian and Ubuntu.
: 玩毛的多核调度，mkl对自家多核向量架构的支持别人根本玩不过，您老
的知识
停留在
: 十年前. 以现在的处理器架构跟mkl的成熟度，不可能再出Goto类似的人
物了
【在 S****8 的大作中提到】
: 玩毛的多核调度，mkl对自家多核向量架构的支持别人根本玩不过，您老的知识停留在
: 十年前. 以现在的处理器架构跟mkl的成熟度，不可能再出Goto类似的人物了
|
g****t
发帖数: 31659 | 10 最大的可能是：
他知道自己要做的计算。
通用库的assumption与此不同。
: 扯蛋的事。。
: 多半是Fortran或者C 参考编译器设置有问题或者没有用新CPU特性，比
较不公平
【在 o**o 的大作中提到】
: 扯蛋的事。。
: 多半是Fortran或者C++参考编译器设置有问题或者没有用新CPU特性，比较不公平
|
|
|
S****8
发帖数: 401 | 11 你说的这个本身overhead就很小，再去看看mkl最近一两年的release note，现在mkl也
允许
直接忽略掉一些对assumption的处理，比如一些小矩阵的各种check.
你十年前电源的贴跟blas有毛关系嘛，不要倚老卖老
【在 g****t 的大作中提到】
: 1.
: 你应该找找10年EE版我讲电源的贴。那时候很多人和你现在的说法都是类似的。几年过
: 去技术换代，我可以肯定他们所在的公司都在这个圈子消失了。
: 后来出现的intc turbo boost 的项目，以及最近新闻说的某手机CPU变慢。这些算法相
: 关部分最早是我写。然后我司business man拿去做生意。现在我们组维护的人也是我培
: 训的。
: 2.
: 自己写多核调度可以提高矩阵运算。原因很简单，mill 优化的assumption不是
: 在specific的用户层。你的程序知道自己要做什么，所以根据多余的信息，完全可能你
: 可以进一步优化。
|
g****t
发帖数: 31659 | 12 我这不是倚老卖老。是举个例子告诉你，
不要看个大公司的名字就觉得你赢不了。
更不要因为是大公司多少人做的活，就觉得别人也赢不了。
我本科时候写的fortran比blas里有的函数都快也是可能的。
信不信由你。
: 你说的这个本身overhead就很小，再去看看mkl最近一两年的release
note，现
在mkl也
: 允许
: 直接忽略掉一些对assumption的处理，比如一些小矩阵的各种check.
: 你十年前电源的贴跟blas有毛关系嘛，不要倚老卖老
【在 S****8 的大作中提到】
: 你说的这个本身overhead就很小，再去看看mkl最近一两年的release note，现在mkl也
: 允许
: 直接忽略掉一些对assumption的处理，比如一些小矩阵的各种check.
: 你十年前电源的贴跟blas有毛关系嘛，不要倚老卖老
|
S****8
发帖数: 401 | 13 我不否认会存在牛逼的人在lapack层能搞出惊为天人的算法，但这样的人不需要去
stackoverflow宣传他的算法.
我个人的看法是，blas层现在想搞出什么动静说比mkl的BLAS快个50%一倍什么的，这基
本不可能，多半如楼上那位哥们所说是忽略了什么编译器option,vectorization支持啥
的，属于unfair benchmark.
比老版本的mkl blas快在以前的老架构上是有可能的，但也仅限于小矩阵blas level3
的操作，这是
常识.
【在 g****t 的大作中提到】
: 我这不是倚老卖老。是举个例子告诉你，
: 不要看个大公司的名字就觉得你赢不了。
: 更不要因为是大公司多少人做的活，就觉得别人也赢不了。
: 我本科时候写的fortran比blas里有的函数都快也是可能的。
: 信不信由你。
:
:
: 你说的这个本身overhead就很小，再去看看mkl最近一两年的release
: note，现
: 在mkl也
:
: 允许
|
g****t
发帖数: 31659 | 14 Stack overflow 上宣传自己东西的神人多了。得诺贝尔奖经济学的我都见过来回答问
题。你给Terrance Tao 问个问题说不定就秒回你。
很多人没自己做过新东西，理解的“常识”多数都是
大学和公司里的老流氓做产品，然后洗到用户脑
子里的。别的不多说了。
: 我不否认会存在牛逼的人在lapack层能搞出惊为天人的算法，但这样的人
不需要去
: stackoverflow宣传他的算法.
: 我个人的看法是，blas层现在想搞出什么动静说比mkl的BLAS快个50%一倍
什么的
，这基
: 本不可能，多半如楼上那位哥们所说是忽略了什么编译器option,
vectorization
支持啥
: 的，属于unfair benchmark.
: 比老版本的mkl blas快在以前的老架构上是有可能的，但也仅限于小矩阵
blas
level3
: 的操作，这是
: 常识.
【在 S****8 的大作中提到】
: 我不否认会存在牛逼的人在lapack层能搞出惊为天人的算法，但这样的人不需要去
: stackoverflow宣传他的算法.
: 我个人的看法是，blas层现在想搞出什么动静说比mkl的BLAS快个50%一倍什么的，这基
: 本不可能，多半如楼上那位哥们所说是忽略了什么编译器option,vectorization支持啥
: 的，属于unfair benchmark.
: 比老版本的mkl blas快在以前的老架构上是有可能的，但也仅限于小矩阵blas level3
: 的操作，这是
: 常识.
|
n******7
发帖数: 12463 | 15 但是也有可能是吹牛B不是？
如果不是成名的人物，我还是觉得assume是吹牛B比较可靠？
比较真牛B是小概率事件，不然不符合牛B的定义了
【在 g****t 的大作中提到】
: Stack overflow 上宣传自己东西的神人多了。得诺贝尔奖经济学的我都见过来回答问
: 题。你给Terrance Tao 问个问题说不定就秒回你。
: 很多人没自己做过新东西，理解的“常识”多数都是
: 大学和公司里的老流氓做产品，然后洗到用户脑
: 子里的。别的不多说了。
:
:
: 我不否认会存在牛逼的人在lapack层能搞出惊为天人的算法，但这样的人
: 不需要去
:
: stackoverflow宣传他的算法.
:
: 我个人的看法是，blas层现在想搞出什么动静说比mkl的BLAS快个50%一倍
|
g****t
发帖数: 31659 | 16 我的浅见:
(1)
技术问题不要看人。
不然你等于自己脖子上套绳子。
迟早技术这行做不下去。
这点其实王银做的很好。
(2)
仅就你的标题而言.
技术上我认为doable.
如果你给我钱让我打mkl
思路很简单.
Mkl这种通用库约束和assumptions很复杂.
本身的设计它就不是只打速度这一点.
小startup或者散户用速度打MKl, 完全可以做到.
用更多的已知条件，改约束，出错不要求predictable,等等。然后
只打速度就可以了。
但你要出一个比MKL更好的产品.
那就是另一回事.
就算你有了火星级的算法突破.
散户也是做不了的.
: 但是也有可能是吹牛B不是？
: 如果不是成名的人物，我还是觉得assume是吹牛B比较可靠？
: 比较真牛B是小概率事件，不然不符合牛B的定义了
【在 n******7 的大作中提到】
: 但是也有可能是吹牛B不是？
: 如果不是成名的人物，我还是觉得assume是吹牛B比较可靠？
: 比较真牛B是小概率事件，不然不符合牛B的定义了
|
x****u
发帖数: 44466 | 17 提起网银，现在他微博删空blog近况也都删了，什么情况
【在 g****t 的大作中提到】
: 我的浅见:
: (1)
: 技术问题不要看人。
: 不然你等于自己脖子上套绳子。
: 迟早技术这行做不下去。
: 这点其实王银做的很好。
: (2)
: 仅就你的标题而言.
: 技术上我认为doable.
: 如果你给我钱让我打mkl
|
n******7
发帖数: 12463 | 18 对于自己精通的领域，自然有能力判断高下
也看过很多烂事，知道不能盲目葱白
但是对于不熟悉的东西还是要看人的
网络上鱼龙混杂，看人是个提高信噪比的有效方法
比如就这个版面，有些ID粗看说的很牛x的样子
知道有一天你看到他一个帖子，只想说WTF
以后就可以省时间了
【在 g****t 的大作中提到】
: 我的浅见:
: (1)
: 技术问题不要看人。
: 不然你等于自己脖子上套绳子。
: 迟早技术这行做不下去。
: 这点其实王银做的很好。
: (2)
: 仅就你的标题而言.
: 技术上我认为doable.
: 如果你给我钱让我打mkl
|
g****t
发帖数: 31659 | 19 人太复杂了。incredible 的复杂。
我的一点浅见：
做技术时间长了，技能到了一定程度，自然会只看技术。因为一般人那点粗浅的看人的
本事，
迟早是
相对于技术能力可以忽略不计。
: 对于自己精通的领域，自然有能力判断高下
: 也看过很多烂事，知道不能盲目葱白
: 但是对于不熟悉的东西还是要看人的
: 网络上鱼龙混杂，看人是个提高信噪比的有效方法
: 比如就这个版面，有些ID粗看说的很牛x的样子
: 知道有一天你看到他一个帖子，只想说WTF
: 以后就可以省时间了
【在 n******7 的大作中提到】
: 对于自己精通的领域，自然有能力判断高下
: 也看过很多烂事，知道不能盲目葱白
: 但是对于不熟悉的东西还是要看人的
: 网络上鱼龙混杂，看人是个提高信噪比的有效方法
: 比如就这个版面，有些ID粗看说的很牛x的样子
: 知道有一天你看到他一个帖子，只想说WTF
: 以后就可以省时间了
|
N*****r
发帖数: 94 | 20
单纯的要在特定情况下比mkl或者fftw快， 还是不算难的，我原来公司也自己重写过
fft
mkl目标是通用库 不只是为了快
【在 g****t 的大作中提到】
: 我的浅见:
: (1)
: 技术问题不要看人。
: 不然你等于自己脖子上套绳子。
: 迟早技术这行做不下去。
: 这点其实王银做的很好。
: (2)
: 仅就你的标题而言.
: 技术上我认为doable.
: 如果你给我钱让我打mkl
|
