那个如果开了优化,C是压根没算。直接结束了。。。你注意一下生成的汇编。。。我这里开了O3就直接结束了。
这些代码我都是按照默认优化跑的。然后Julia都是 1.0版本,1.0比起0.6有很多新的优化(虽然某些性能有regression,但是会随着后面版本的更新慢慢修复)
如果代码考虑到并行,matlab是很厉害的
不就开个多线程,多大点事儿[doge]
function runme()
Threads.@threads for i = 1:500000
testp(Cint(i))
end
end
这有点开始歪楼了,OP强调了实验都是单核执行,感觉这贴讨论的差不多了,适当时机可以锁了。这类帖在官方discourse也一样,最后有可能会变成引战贴,后面的内容都不会太有营养。 说实话,Julia用了这么长时间,这类帖子早就看厌了,懒得争。
不好,别用。-- 张实唯
bounds check不是针对数组indexing的么
你说的对,我看错了
C就是直接的gcc -o …
Julia是在Include(“…”)
请问你说的抽象是什么呢?
最后一个不是Python嘛…
我用的Mathematica是11.2
不同编译器对long long的理解不一样的,因为标准只规定了long long 不应该小于int, 你可以试一试sizeof(int)和sizeof(long long).
我觉得差距不大的原因是因为你的编译器理解的这两个类型是一样的
Mathematica不是主流科学计算语言。。。。。
非引战,这个要看领域的吧,学物理的人用Mathematica的比例还是挺多的…
I see…
果然我把类型定在Int32就很快了,跑了40s, 和C(35.6s) 就在一个量级上了
但这似乎同时对其它语言不太公平,matlab是用double在跑? 所以说要做好这种benchmark是挺难的,公平性就很难定义,这也是这类讨论容易引战的原因吧。
是这样的,其实如果裸写循环,或者裸写个cython大家总有办法写出来差不多太多速度的代码。但是当你需要封装出来一个 class
(在python里),在Julia里面声明一些抽象类型和类型。这个时候其实才是真正对实际工作有意义的(你总不可能永远用一些Float之类的数值类型搞低抽象吧)。但是这种很难说公平的测试,但是我想说的是目前我们自己的实践是比Python + C++快的。而且不需要C++。当你真的写Python + C++的时候,一些新手其实反而因为没搞清楚CPython的机制,写出效率低的wrapper(我在知乎上也曾经见到有人问为什么自己写的CPython比cython生成的慢)。所以最后大家还是看一个完整的实践比如einsum和另外一个语言里完整的实践比吧。这样对实际的工作更有意义一些。
该主题在创建22小时后自动关闭。不再允许新的回复。