||[Dec. 26th, 2004|10:51 pm]
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.
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.
2004-12-27 07:45 am (UTC)
wouldn't help this problem.
"thanks for calling technical support, have a nice day"
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.
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.
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.
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
2004-12-27 10:21 am (UTC)
but OCaml is like gibberish-looking. Hell, you don't even understand it! :P
let rec gah infinite recursion mind explodes!
Is your post-tuning perl in cvs anywhere? I wouldn't mind taking a look at it.
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?
What's the line count for each?
2004-12-28 12:33 am (UTC)
perl: 387 1153 9105
c: 1302 4531 39577
And the assembly version? :-)
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.
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.
2004-12-28 06:59 am (UTC)
C is glorified assembler. Each line you can see how it'll map to real instructions.
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.
Can you imagine doom 3 writen in c?
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?)