由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - haskell在生产环境的生产力到底如何?
相关主题
有人用Haskell吗成功无偶然啊
看了一下Meteor很不错总觉得python 用缩进定义逻辑block 这种思想很诡异
haskell 可以运行在iOS上了how to catch croak? (Perl)
最新haskell实现可用40+ cores花了一个小时学习了python
haskell有潜力成为最好的web framework[合集] 大家的set sw都设多少啊?
haskell 怎样解决库的版本问题?请问大家怎样让程序难以读懂
Scala又被鄙视了这个程序怎么解决
对 (im)mutability 的误解和深度理解perl eval and if
相关话题的讨论汇总
话题: haskell话题: perl话题: lazy话题: eval话题: lines
进入Programming版参与讨论
1 (共1页)
p*****2
发帖数: 21240
1
是很高还是一般?
p*****2
发帖数: 21240
2
还有就是有好的rest framework吗

【在 p*****2 的大作中提到】
: 是很高还是一般?
d******e
发帖数: 2265
3
yeosd, wrap, snap

【在 p*****2 的大作中提到】
: 还有就是有好的rest framework吗
p*****2
发帖数: 21240
4
貌似scotty更好?

【在 d******e 的大作中提到】
: yeosd, wrap, snap
w******p
发帖数: 166
5
i wrote something to parse logs and then do something else, the log files is
less than 10k lines and it's slow like hell, optimized compiled code is way
slower than Perl. Not to mention that "functional" statement doesn't look
easier to read than perl.
I know that I'm hit by its lazy evaluation, and I tried to use foldr or
foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
quickly. This is quite bad compared to my experience with Standard ML, which
produced code much faster than perl, and was what I have expected for
compiled code.
d******e
发帖数: 2265
6
Haskell‘s default string implemention is linked list. it is extremely slow.

is
way
which

【在 w******p 的大作中提到】
: i wrote something to parse logs and then do something else, the log files is
: less than 10k lines and it's slow like hell, optimized compiled code is way
: slower than Perl. Not to mention that "functional" statement doesn't look
: easier to read than perl.
: I know that I'm hit by its lazy evaluation, and I tried to use foldr or
: foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
: quickly. This is quite bad compared to my experience with Standard ML, which
: produced code much faster than perl, and was what I have expected for
: compiled code.

d******e
发帖数: 2265
7
没用过。二爷可以试试?

【在 p*****2 的大作中提到】
: 貌似scotty更好?
w******p
发帖数: 166
8
In Standard ML I also treat them as linked list, using explode/implode,
still much faster.
Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
t use lazy eval at all.

slow.

【在 d******e 的大作中提到】
: Haskell‘s default string implemention is linked list. it is extremely slow.
:
: is
: way
: which

w***g
发帖数: 5958
9
lazy eval是为了写所谓漂亮的functional代码引入的伪问题。
lazy eval起作用的前提就是写了实际上不会被运行到的代码。
imperative programming里面很少有写了不用的代码。

don'

【在 w******p 的大作中提到】
: In Standard ML I also treat them as linked list, using explode/implode,
: still much faster.
: Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
: t use lazy eval at all.
:
: slow.

w******p
发帖数: 166
10
I think lazy eval is okay, but it shouldn't be the default, whoever want to
have lazy eval just do their own thunks, and with any language that supports
pointer/reference.
By making it the default really confuses people about performance, and
invents problem that wasn't there before.
However, lazy eval seems essential for Haskell because it wants to be "pure"
, in that the function parameter evaluation orders doesn't matter for
deterministic calculations, and at the same time save duplicated evaluations
like calculation "a+b" twice in square(a+b) => (a+b) * (a+b), therefore
making a pointer/thunk for "a+b" calculation and don't do it unless needed.
Yes, Haskell is "powerful" because of this, it can implement cool things
like if_then_else with short circuits with a function -- that other
languages like lisp/ml/java/c/etc cannot do -- they all have to eval all
args before calling a function and therefore cannot short circuit. But in
the end, how useful is lazy eval other showing off with cool tricks?
相关主题
haskell 怎样解决库的版本问题?成功无偶然啊
Scala又被鄙视了总觉得python 用缩进定义逻辑block 这种思想很诡异
对 (im)mutability 的误解和深度理解how to catch croak? (Perl)
进入Programming版参与讨论
a*****e
发帖数: 1700
11
我最喜欢这类问题了,你方便贴一下代码么?

is
way
which

【在 w******p 的大作中提到】
: i wrote something to parse logs and then do something else, the log files is
: less than 10k lines and it's slow like hell, optimized compiled code is way
: slower than Perl. Not to mention that "functional" statement doesn't look
: easier to read than perl.
: I know that I'm hit by its lazy evaluation, and I tried to use foldr or
: foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
: quickly. This is quite bad compared to my experience with Standard ML, which
: produced code much faster than perl, and was what I have expected for
: compiled code.

a*****e
发帖数: 1700
12
lazy vs strict 这个问题,基本的 facts 都总结在这两个文章里面:
http://existentialtype.wordpress.com/2011/04/24/the-real-point-
第一篇是 Bob Harper 写的,学过 SML 的应该都知道他吧,估计没有人比他更痛恨
Haskell 了,呵呵。文章讲到的都很有道理,没讲到的我觉得应该是故意略过了。所以
要看第二篇。
http://augustss.blogspot.com/2011/05/more-points-for-lazy-evalu
第二篇是 Lennart Augustsson 写的,早期 Haskell 的重要功臣之一,他在 Standard
Chartered 写的内部用的 mu haskell 是 strict by default。他这个文章讲了几点
laziness 的好处,就算是 Harper 也不好反驳。

don'

【在 w******p 的大作中提到】
: In Standard ML I also treat them as linked list, using explode/implode,
: still much faster.
: Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
: t use lazy eval at all.
:
: slow.

w******p
发帖数: 166
13
sure here's the code, i want to get a map from the log lines, with the 2nd
or 3rd record as key. You see that I try to make it quicker by only getting
first 30 chars of each line because I know that the keys cannot be too long,
and I filter out empty lines and short lines with less than 50 words. In
practice the `isInfixOf` filtering did speed up the parsing by about 1x or
2x.
parseLog candidates = readFile "records" >>= buf ->
return $ foldl' (accu -> x->
let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
in (x!!1,v):(x!!2,v):accu
) [] $ filter (x->length x>50) $ map words $ filter (line->
any (c->((' ':c)++" ") `isInfixOf` (take 30 line)
) candidates
) $ lines buf
above code is much harder to read and much slower than perl's simple
(split)[1,2,29,27,32,33,49]

【在 a*****e 的大作中提到】
: 我最喜欢这类问题了,你方便贴一下代码么?
:
: is
: way
: which

a*****e
发帖数: 1700
14
你那行 perl 显然做的不是同一件事情。如果做和 perl 同样的事情,以下是 Haskell
程序:
main = parse >>= mapM_ (putStrLn . show)
parse = readFile "records" >>= return . concat . map (takeOut . words) .
lines
where
takeOut x = let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
in [(x!!1,v), (x!!2,v)]
以下是 Perl 程序:
my $filename = "records";
open (my $fh, $filename)
or die ("could not open file '$filename'");
while (my $row = <$fh>) {
my @x = (split(/ /, $row))[1,2,29,27,32,33,49];
print "($x[1], @x)\n";
print "($x[2], @x)\n";
}
基本上做的是同一件事情。我用 100K 行输入,perl 2秒,haskell 4秒。
考虑到 Haskell 用的是 default String,这个 performance not too shabby.
如果用 ByteString,就和 perl 速度一样。而且 Haskell 里面 !! 还是在用 linked
list 而 Perl 里面取下标是数组。
而且无论你用什么语言,想要优化,总是有空间。
我的意思是,上面那个 Haskell 程序效率方面完全可以接受,一行程序也不难读。

getting
long,

【在 w******p 的大作中提到】
: sure here's the code, i want to get a map from the log lines, with the 2nd
: or 3rd record as key. You see that I try to make it quicker by only getting
: first 30 chars of each line because I know that the keys cannot be too long,
: and I filter out empty lines and short lines with less than 50 words. In
: practice the `isInfixOf` filtering did speed up the parsing by about 1x or
: 2x.
: parseLog candidates = readFile "records" >>= buf ->
: return $ foldl' (accu -> x->
: let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
: in (x!!1,v):(x!!2,v):accu

w******p
发帖数: 166
15
your input is definitely different than mine, my log lines are all very long
, thousands of chars each line.
with Perl I don't need to do the filtering to check if the search candidates
are within the first 30 chars, with Haskell I have to make code much more
lengthy and harder to read to try to be on par with Perl.
同样的事情 for me is to get my result as soon as could be operating on my
long log-line files, perl one line vs. Haskell multi-line ugliness I had to
do -- perl one-liner sufficient, and in the end perl wins in 生产环境的生产
力, be it coding speed or code execution speed.
with SML I don't need to do that ugly filtering and it's faster than perl.
make no mistake I like Haskell because it broadens one's horizon.
One more bad thing about Haskell though: its code must be formatted with
proper indentation, like Python but much worse than Python, Python's is much
simpler rule, Haskell's is much more unpredictable. Whenever I just do a
simple thing like changing a function name to be longer, the indentation
breaks and I had to adjust every freaking lines in the function manually! If
Python indentation annoys people, Haskell's is just pure pure evil. With
Emacs I can simply press tab to make Python indentation right, I tried 3
Emacs haskell plugins, none can make it right all the time.

Haskell

【在 a*****e 的大作中提到】
: 你那行 perl 显然做的不是同一件事情。如果做和 perl 同样的事情,以下是 Haskell
: 程序:
: main = parse >>= mapM_ (putStrLn . show)
: parse = readFile "records" >>= return . concat . map (takeOut . words) .
: lines
: where
: takeOut x = let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
: in [(x!!1,v), (x!!2,v)]
: 以下是 Perl 程序:
: my $filename = "records";

a*****e
发帖数: 1700
16
重点在于要用 ByteString,而不是你那个 30 字符 prefix match 的优化(而且吧,
你那个优化其实效率很差,因为你还在用 list)。你不能指望 linked list 和 Perl
或者 SML 的 array based String 一个效率。
至于缩进,我觉得你还是没理解它的设计要素,我从来没有遇到过你说的手工改动多行
的情况。如果实在不喜欢,可以直接用 { 和 } 和 ; 然后就和写 C 一样了,完全不需
要理会缩进规则。GHC 编译器里面有不少代码都是这种格式写的,也没什么啊

long
candidates
to

【在 w******p 的大作中提到】
: your input is definitely different than mine, my log lines are all very long
: , thousands of chars each line.
: with Perl I don't need to do the filtering to check if the search candidates
: are within the first 30 chars, with Haskell I have to make code much more
: lengthy and harder to read to try to be on par with Perl.
: 同样的事情 for me is to get my result as soon as could be operating on my
: long log-line files, perl one line vs. Haskell multi-line ugliness I had to
: do -- perl one-liner sufficient, and in the end perl wins in 生产环境的生产
: 力, be it coding speed or code execution speed.
: with SML I don't need to do that ugly filtering and it's faster than perl.

w******p
发帖数: 166
17
ByteString 好像不好用啊,读zip文件得用Data.ByteString.Lazy,但是用的是GHC.
Word.Word8,跟Char转换挺费劲的,我需要一个统一的interface既能读一般文件,又能
读zip文件,Data.ByteString.Lazy跟Data.ByteString.Lazy.Char8又不兼容,看来
haskell是kill time利器啊
a*****e
发帖数: 1700
18
绝对的 kill time 利器 :-)
ByteString.Lazy 和 ByteString.Lazy.Char8 怎么会不兼容呢,后者是为前者提供向
Char 转化的工具(直接 truncate),但是操作的结果和对象可都是 ByteString.Lazy
啊。所以你用 Codec.Archive.Zip 读写的 ByteString.Lazy.ByteString 类型的值,
直接用 ByteString.Lazy.Char8 里面的函数操作即可。
不过说实在话,我不知道你为什么喜欢用 Char,直接用 Word8 并没有很不方便。
尤其是 String literal 可以直接使用 {-# LANGUAGE OverloadedStrings #-}
如果你说的是 ByteString 和 [Char] 之间转换,只需要用到 ByteStirng.Lazy.Char8
.pack 和 unpack 两个函数,其它不需要考虑。如果你需要 UTF8 编码转换,用 utf8-
string 这个库。

【在 w******p 的大作中提到】
: ByteString 好像不好用啊,读zip文件得用Data.ByteString.Lazy,但是用的是GHC.
: Word.Word8,跟Char转换挺费劲的,我需要一个统一的interface既能读一般文件,又能
: 读zip文件,Data.ByteString.Lazy跟Data.ByteString.Lazy.Char8又不兼容,看来
: haskell是kill time利器啊

w******p
发帖数: 166
19
谢谢高手解答,不过我得去看看别的啥透透气去,过几天再来看haskell吧,想提高提
高效率这么多trick
1 (共1页)
进入Programming版参与讨论
相关主题
perl eval and ifhaskell有潜力成为最好的web framework
Is Javascript the new PERL?haskell 怎样解决库的版本问题?
Re: 问个google面试题 (转载)Scala又被鄙视了
perl problem对 (im)mutability 的误解和深度理解
有人用Haskell吗成功无偶然啊
看了一下Meteor很不错总觉得python 用缩进定义逻辑block 这种思想很诡异
haskell 可以运行在iOS上了how to catch croak? (Perl)
最新haskell实现可用40+ cores花了一个小时学习了python
相关话题的讨论汇总
话题: haskell话题: perl话题: lazy话题: eval话题: lines