?

Log in

No account? Create an account
HLL performance - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

HLL performance [Dec. 26th, 2004|10:51 pm]
Brad Fitzpatrick
[Tags|, ]

It sucks that high-level languages suck so much at performance.

I wrote a particular Perl daemon the other day with Whitaker... busted it out in about an hour, if even. It consumed 100% CPU. Suck.

Tuned the Perl... 60-80% CPU. Way too much.

This evening wrote it in C, it took about 3 hours to write .... 10% CPU, with debugging, assertions, no tuning, no -O flags.

Cool, but sad.
LinkReply

Comments:
(Deleted comment)
[User Picture]From: brad
2004-12-27 07:28 am (UTC)
It'll be better, if it ever comes out.

Being able to optionally provide types to variables helps in performance-sensitive code, as does a JITer.
(Reply) (Parent) (Thread)
[User Picture]From: dakus
2004-12-27 07:30 am (UTC)
get more CPU's?

;-))
(Reply) (Thread)
[User Picture]From: brad
2004-12-27 07:45 am (UTC)
wouldn't help this problem.
(Reply) (Parent) (Thread)
[User Picture]From: dakus
2004-12-27 08:01 am (UTC)
Reboot?

"thanks for calling technical support, have a nice day"
(Reply) (Parent) (Thread)
From: (Anonymous)
2004-12-27 08:19 am (UTC)

Look on the good side

At least you where able to test your idea first, before getting down into C.

I suspect that if you did it straight in C, it would have taken longer.
(Reply) (Thread)
[User Picture]From: brad
2004-12-27 08:22 am (UTC)

Re: Look on the good side

Yeah, that's totally true. It would've taken much longer in C had I not prototyped it first.
(Reply) (Parent) (Thread)
[User Picture]From: xaosenkosmos
2004-12-27 08:28 am (UTC)

This is totally in left field.

In a recent foray into java (here, for posterity), i learned that character conversion is fucking expensive. This could be biting you, though it's probably just perl being slow. Since perl doesn't typically do UTF-8/etc by default, but, you never know these days.
(Reply) (Thread)
From: evan
2004-12-27 10:14 am (UTC)
need i mention the obvious high-level language you're forgetting? :P

i think languages designed for "scripting" are slow: every new variable is another malloc, interpreters walk the parse tree, etc. i think you could reimplement perl these days with a different focus in mind (and subtract out a few of the more magical bits) and get much better performance. see also that perl fields module you've raved about, or psyco.
(Reply) (Thread)
[User Picture]From: brad
2004-12-27 10:21 am (UTC)
but OCaml is like gibberish-looking. Hell, you don't even understand it! :P
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-12-27 07:26 pm (UTC)
let rec gah infinite recursion mind explodes!
(Reply) (Parent) (Thread)
[User Picture]From: whitaker
2004-12-27 06:50 pm (UTC)
Is your post-tuning perl in cvs anywhere? I wouldn't mind taking a look at it.
(Reply) (Thread)
From: legolas
2004-12-27 09:31 pm (UTC)
This is something I like about STL. I had a problem once were I was creating an stl string (which was allocating memory internally) in a dll, and destructing it (and so deallocating the memory again) in the main app, which (on windows) caused trouble. After a lot of searching, I found out that all stl type have an optional parameter that allows you to give them an allocator that will be used to allocate memory. Implemented an allocator that allocated from the 'global heap' and the problem went away.

So I wonder if this isn't an avenue that would work on perl etc too: give performance specififc bits defaults but if you have trouble allow you to put in replacements for them. Or wouldn't that make any sense, since replacements would be in perl too and hece not faster?
(Reply) (Thread)
From: jeffr
2004-12-28 12:28 am (UTC)
What's the line count for each?
(Reply) (Thread)
[User Picture]From: brad
2004-12-28 12:33 am (UTC)
perl:   387  1153   9105 
   c:  1302  4531  39577
(Reply) (Parent) (Thread)
From: jeffr
2004-12-28 05:08 am (UTC)
And the assembly version? :-)
(Reply) (Parent) (Thread)
[User Picture]From: caladri
2004-12-28 09:00 pm (UTC)
Does it count if it's a bunch of GCC crap assembly? If I ever get a project where I get paid for lines of code, I'm hella gonna make sure it's assembly with GCC's help on a RISCy architecture. It generates more lines of code to do things than I could ever imagine.

allocate-stack
get-pointer-value-from-argument-register
load-word-from-pointer-value-offset-0-to-register0
load-word-from-pointer-value-offset-1-to-register1
store-word-from-register0-to-stack-offset-0
store-word-from-register1-to-stack-offset-1
load-word-from-stack-offset-1-to-register0
work-on-register0
store-word-from-register0-to-stack-offset-1
load-word-from-stack-offset-0-to-register1
work-on-register1
store-word-from-register1-to-stack-offset-0
needlessly-clobber-registers
load-word-from-stack-offset-0-to-register0
load-word-from-stack-offset-1-to-register1
compute-return-value
store-word-from-register0-to-stack-offset-0
store-word-from-register1-to-stack-offset-1
store-return-value-to-stack-offset-2
needlessly-clobber-registers
load-word-from-stack-offset-2-to-return-register
release-stack
return
(Reply) (Parent) (Thread)
[User Picture]From: avatraxiom
2004-12-28 03:07 am (UTC)
If we're talking about the difference between perl and C, wouldn't it also be a big hit on the difference between an interpreted and a compiled language?

After all, C is technically a "high-level language," because it allows you to express programming concepts instead of machine instructions.

-Max
(Reply) (Thread)
[User Picture]From: brad
2004-12-28 06:59 am (UTC)
C is glorified assembler. Each line you can see how it'll map to real instructions.
(Reply) (Parent) (Thread)
[User Picture]From: caladri
2004-12-28 08:49 pm (UTC)
I think that's a bit fallacious, though. The only difference is calling syntax. C++ proves this point all too well. If you can change the meaning of operators, this stops being true. Or if you accept a function as being as-good-as an operator. But then you might as well use Lisp like a fucking communist.
(Reply) (Parent) (Thread)
From: ex_networke
2004-12-28 03:57 pm (UTC)

That's progress

Can you imagine doom 3 writen in c?
(Reply) (Thread)
From: legolas
2004-12-29 08:00 pm (UTC)

Re: That's progress

Can you imagine doom3 NOT being written in C++? (anyone know what it was written in?)
(Reply) (Parent) (Thread)
[User Picture]From: taral
2004-12-29 05:36 am (UTC)
Haskell. ♥
(Reply) (Thread)