No Such Blog or Diary

«Prev || 1 | 2 | 3 |...| 56 | 57 | 58 || Next»

Python は遅いのか?(その2)

昨日の続きで,ループ系の計算でも比較してみた.

#include
#include
int main(int argc, char *argv[])
{
	int sum = 0;
	int n = 0, i, j;
	n = atoi(argv[1]);
	for(j = 0; j  < 1000; j++) for(i = 0; i < n; i++) sum += i;
	printf("%d\n", sum);
	return 0;
}
import sys
n=int(sys.argv[1])
s=0
for j in range(0,1000): 
	for i in range(0, n):
		s += i
print(s)

結果:

hogehoge:~/work/pypytest$ gcc -O3 -o sumI sumI.c
hogehoge:~/work/pypytest$ time ./sumI 1000000
882236160
 
real    0m0.255s
user    0m0.252s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy sumI.py 1000000
499999500000000
 
real    0m2.105s
user    0m2.088s
sys    0m0.020s

もう一回:

hogehoge:~/work/pypytest$ time ./sumI 1000000
882236160
 
real    0m0.155s
user    0m0.152s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy sumI.py 1000000
499999500000000
 
real    0m2.130s
user    0m2.120s
sys    0m0.008s

10数倍くらい? 再起しまくりのフィボナッチと同じ程度.多倍長整数の演算になっている点が響いてるかも?

ということで,double でやった時:

hogehoge:~/work/pypytest$ time ./sum 1000000
5e+14
 
real    0m1.159s
user    0m1.156s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy sum.py 1000000
4.999995e+14
 
real    0m3.085s
user    0m3.064s
sys    0m0.024s

こっちは 2~3倍程度.

ということで,Python は C の 3~10倍程度の遅さでしょう.なお,CPU は Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz で.

Python は遅いのか?

フィボナッチ数の計算で C の 70倍遅いとかいうことを聞いて,何となく今までの体感と違かったので手元で測ってみた.PyPy だけど.

プログラム達:

#include
int fib(int n) {
	if(n  <= 1) return 1;
	return fib(n-1)+fib(n-2);
}
int main(int argc, char *argv[])
{
	printf("%d\n", fib(42));
	return 0;
}
def fib(n):
	if n  <= 1:
		return 1
	else:
		return fib(n-1)+fib(n-2)
print(fib(42))

結果:

hogehoge:~/work/pypytest$ gcc -O3 -o fib fib.c
hogehoge:~/work/pypytest$ time ./fib
433494437
 
real    0m0.902s
user    0m0.900s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy fib.py
433494437
 
real    0m9.285s
user    0m9.240s
sys    0m0.044s 

もう一回:

hogehoge:~/work/pypytest$ time ./fib
433494437
 
real    0m0.883s
user    0m0.880s
sys    0m0.000s
hogehoge:~/work/pypytest$ time pypy fib.py
433494437
 
real    0m9.429s
user    0m9.372s
sys    0m0.056s 

10倍? 大体このくらいな気がする.

それぞれの --version の結果:

gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
Python 2.7.10 (5.1.2+dfsg-1~16.04, Jun 16 2016, 17:37:42)
[PyPy 5.1.2 with GCC 5.3.1 20160413]

NetworkX

Python のライブラリの NetworkX が実験用のグラフをちょちょいと生成しようと思った時に便利だった.よくある生成の仕方に対して各種生成器が提供されているので.あとは目的の形にファイルに書き出すスクリプトを書いてあげれば OK.

インストールも pip で入るので楽.cygwin でも OK だった(setuptools 入れて easy_install pip して).

どこまで大きなサイズまで実用できるのかはわからないけれど.

round 関数で嵌る

幾つかの言語で 0.5, 1.5, 2.5, 3.5, 4.5 を round 関数を使って丸めてみる.

C: 1, 2, 3, 4, 5 (直感的な四捨五入)

Java: 1, 2, 3, 4, 5 (直感的な四捨五入)

Haskell: 0, 2, 2, 4, 4 (偶数しか出てこない……)

ということで,Haskell は X.5 の時には偶数に丸めてくれるらしい.累積誤差を小さくできるとかで銀行で好まれるとか.Haskell は銀行に優しいのかもしれない.

これを知らずに微妙にハマった.

Literate Haskell (.lhs) での GHC プラグマ

普通の Haskell ソース(.hs) だと下のような {-# LANGUAGE ... #-} をファイルの頭に書くのだけど,.lhs でそのまま同じに書いといたら ghc が認識してくれなくて困った.

{-# LANGUAGE FlexibleInstances,MultiParamTypeClasses,FunctionalDependencies #-}

で,{- -} がコメントだから,コメントがデフォルトになってる Literate Haskell では # LANGUAGE ... # と書くのか? とかアホなことをしつつ,最終的にプラグマはプログラムの一部なんだから頭に > つけなきゃ認識されないよなとかいうことを理解した.

ということで,こう書けばよかった:

> {-# LANGUAGE FlexibleInstances,MultiParamTypeClasses,FunctionalDependencies #-}

今まで Literate Haskell でプラグマが必要なプログラムなんか書いてなかったのでアホなことに躓いた.

cabal install で依存関係のバージョン上限を外す:--allow-newer

Hackage は基本的に「テストしたバージョンまでで依存パッケージのバージョン上限を設けとけよ」的なノリなので,実際には問題ないんだけど上限よりも上のバージョンの依存パッケージしか入れられないから目的のパッケージがインストール出来ない,とかいう状況がチラホラある.バージョン上限を書き換えるためだけにデプロイやり直すのも作者が面倒だろうし.

んで,この状況にハマった時には目的のパッケージのソースを持ってきて手動でコンパイルするかとかやってたのだけど,cabal install のヘルプを良く見てみたら --allow-newer とかいう便利なオプションがあることに(今更ながら)気づいた.これつけとくとバージョン上限を無視してくれる.ほんと便利.

閑話休題.

cabal install を使った時とパッケージのソースで runghc Setup.hs configure とかやった時とでオプション無しの時の振る舞いが異なっていてハマった.cabal install がデフォルトでユーザ個別にパッケージをインストールをする(--user オプションがデフォルト?)のに対して,手元に持ってきたパッケージで runghc Setup.hs configure とかやった時にはグローバルにインストールされたものを探しに行っていた(--global オプションがデフォルト).おかげで入れたはずのパッケージが見つからないと怒られて,でも ghci で確かめると普通に import できて,何がおかしいのか暫く悩みまくった. runghc Setup.hs configure --verbose=3 とかやったら ghc-pkg を呼ぶときに --global をつけているのが見えて分かったのだけど,ここらのデフォルトの違いはどこから出てきたのやら.

«Prev || 1 | 2 | 3 |...| 56 | 57 | 58 || Next»
Search
Feeds

Page Top