与Project Euler的速度比较:C,Python,Erlang,Haskell

与Project Euler的速度比较:C,Python,Erlang,Haskell,第1张

与Project Euler的速度比较:C,Python,Erlang,Haskell

使用

GHC 7.0.3
gcc 4.4.6
Linux 2.6.29
一个x86_64的Core2双核(2.5GHz的)机器上,编译使用
ghc-O2 -fllvm -fforce-recomp
用于Haskell和
gcc -O3 -lm
为C.

  • 您的C例程在8.4秒内运行(比运行速度快,原因可能是
    -O3
  • Haskell解决方案可在36秒内运行(由于显示
    -O2
    标记)
  • 您的
    factorCount'
    代码未明确输入且默认为
    Integer
    (感谢Daniel在这里纠正了我的误诊!)。使用给出显式类型签名(无论如何都是标准做法)
    Int
    ,时间更改为 11.1秒
  • factorCount'
    你不必要的呼唤
    fromIntegral
    。修复不会产生任何变化(编译器很聪明,对您来说很幸运)。
  • mod
    rem
    更快更充分的地方使用了。这将时间更改为 8.5秒
  • factorCount'
    不断应用两个永不改变的自变量(
    number
    sqrt
    )。工人/包装工人的转型为我们提供了:

    $ time ./so
    842161320

    real 0m7.954s
    user 0m7.944s
    sys 0m0.004s

没错, 7.95秒 。始终 比C解决方案快半秒 。没有

-fllvm
标记,我仍然会收到消息
8.182seconds
,因此NCG后端在这种情况下也表现良好。

结论:Haskell很棒。

结果代码

factorCount number = factorCount' number isquare 1 0 - (fromEnum $ square == fromIntegral isquare)    where square = sqrt $ fromIntegral number          isquare = floor squarefactorCount' :: Int -> Int -> Int -> Int -> IntfactorCount' number sqrt candidate0 count0 = go candidate0 count0  where  go candidate count    | candidate > sqrt = count    | number `rem` candidate == 0 = go (candidate + 1) (count + 2)    | otherwise = go (candidate + 1) countnextTriangle index triangle    | factorCount triangle > 1000 = triangle    | otherwise = nextTriangle (index + 1) (triangle + index + 1)main = print $ nextTriangle 1 1

编辑:现在,我们已经探索了这一点,让我们解决问题

问题1:erlang,python和haskell是否会由于使用任意长度的整数而导致速度下降,还是只要它们的值小于MAXINT,它们就不会丢失吗?

在Haskell中,使用

Integer
的速度慢于
Int
但要慢多少,取决于执行的计算。幸运的是(对于64位计算机)
Int
就足够了。出于可移植性考虑,您可能应该重写我的代码以使用
Int64
Word64
(C不是唯一带有的语言
long
)。

问题2:为什么haskell这么慢?是否有编译器标志可以使您刹车?或者这是我的实现?(后者很可能因为haskell是一本对我有七个印章的书。)

问题3:能否为我提供一些提示,说明如何在不改变确定因素的方式下优化这些实现?以任何方式进行优化:对语言更好,更快,更“原生”。

那就是我上面回答的。答案是

  • 0)通过使用优化
    -O2
  • 1)尽可能使用快速(特别是:不可装箱)类型
  • 2)
    rem
    不是
    mod
    (经常被遗忘的优化),并且
  • 3)worker / wrapper转换(也许是最常见的优化)。

问题4:我的功能实现是否允许LCO,从而避免在调用堆栈中添加不必要的帧?

是的,这不是问题。做得好,很高兴您考虑了这一点。



欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5666119.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-16
下一篇 2022-12-16

发表评论

登录后才能评论

评论列表(0条)

保存