CL-USER> (time (loop repeat 1000000 do (format nil "OP is a faggot.")))
Evaluation took:
0.688 seconds of real time
0.687500 seconds of total run time (0.687500 user, 0.000000 system)
[ Run times consist of 0.108 seconds GC time, and 0.580 seconds non-GC time. ]
100.00% CPU
1,662,811,389 processor cycles
447,995,736 bytes consed
That prints "OP is a faggot" to a string and leaves it for the gc to collect, one million times. As you can see it consumes about 447 bytes on average and ~1662 CPU cycles on average per each print. Another thing to be noted here is that we're talking about the full power of the format function, which is likely one of the most advanced string formatting functions I've ever seen, and that for each instance, a new string stream is created and left for the gc to feed upon.
tl;dr: OP must be doing something very wrong, or most likely a troll. IHBT
Name:
Anonymous2009-10-27 6:15
>>23
this is cherry picked data.
either that or completely falsified.
>>24
Go and test it in SBCL or other Lisp implementations. I gave it a go in CCL, but the compiler was smart enough to just remove the dead code, making it a total of 0.000s, so I disqualified it. A good CL implementation is on average only some 3-4 times slower than C, and with proper type declarations it can easily aproach its performance.
I just gave it a go in one of the slowest CL implementations which is CLISP(interpreter, however they do have a JIT, but it wasn't used in this case):
[1]> (time (loop repeat 1000000 do (format nil "OP is a faggot.")))
Real time: 7.34375 sec.
Run time: 7.34375 sec.
Space: 384004620 Bytes
GC: 657, GC time: 1.15625 sec.
NIL
It seems to be about 10 times as slow as SBCL's performance, but consumes less memory overall. I haven't bothered trying to compile it and see how fast it would go with CLISP's JIT.
>>23,26
You clearly are idiots. I used the so called "fastest" implementation around, SBCL. It took me 3 hours to compile and install this, just to prove you how wrong you are.
CL-USER(1): 'works?
WORKS!
CL-USER(2): (sb-profile:profile format)
CL-USER(3): (loop repeat 100 do (format nil "OP is a faggot"))
NIL
CL-USER(4): (sb-profile:report)
measuring PROFILE overhead..done
seconds | consed | calls | sec/call | name
----------------------------------------------------
0.000 | 80,016 | 106 | 0.000000 | FORMAT
----------------------------------------------------
0.000 | 80,016 | 106 | | Total
estimated total profiling overhead: .000 seconds
overhead estimation parameters:
2.e-8s/call, 1.9259999e-6s total profiling, 9.98e-7s internal profiling
80,016 CONS CELLS just for the generation of 100 C strings. Completely moronic implementation I'd say. Do you idiot lispers even know how much memory that is? A cons cell is (AT MINIMUM!) represented with this C structure in memyory:
struct cons {
void *ptr;
void *head;
int size;
}
IT IS ALREADY 16 BYTES! (4*2 + 4 + offsetof) Multiply that by 80,016:
CL-USER(6): (* 80,016 16)
debugger invoked on a SB-INT:SIMPLE-READER-ERROR:
SB-INT:SIMPLE-READER-ERROR at 6 (line 1, column 6) on #<SB-IMPL::STRING-INPUT-STREAM {LB33AD1}>:
comma not inside a backquote
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-INT:SIMPLE-READER-ERROR
#<SB-IMPL::STRING-INPUT-STREAM {LB33AD1}>
"comma not inside a backquote")[:EXTERNAL]
Oh yeah, I forgot, your high level language that can do everything can't even learn how to understand both 80.016 and 80,016. Pff..., man 3 scanf.
P.S. (it's 1280.256 MiBs, I could get an OS running with that memory)
>>27
It does it 1000000 times, and measures the memory/time/CPU usage before/after. This just means ~384bytes per FORMAT call, and a truly negligible amount of time overall for a single FORMAT call. And CLISP is one of the slowest implementations out there.
>>28
CL-USER> (sb-profile:profile format)
; No value
CL-USER> (loop repeat 1000000 do (format nil "OP is a faggot"))
NIL
CL-USER> (sb-profile:report)
seconds | consed | calls | sec/call | name
-------------------------------------------------------------
1.183 | 472,126,240 | 1,000,191 | 0.000001 | FORMAT
-------------------------------------------------------------
1.183 | 472,126,240 | 1,000,191 | | Total
estimated total profiling overhead: 0.97 seconds
overhead estimation parameters:
3.2000003e-8s/call, 9.68e-7s total profiling, 1.24e-7s internal profiling
; No value
Besides that, PROFILE comes with its own overhead, which is quite a bit over here when we're calling it that many times.
80,016 CONS CELLS
That's not cons cells. It's bytes allocated you retard.
CL-USER(6): (* 80,016 16)
Haha, shows you don't even know the language if you type that in.
FORMAT is incredibly complex, yet it's so well optimized that it only had to alloc ~400 bytes to print that string.
Oh, and the total allocated memory at the end is just that. That memory is being free'd by the gc shortly after it is alloced. Just like you manually malloc and free your strings.
You clearly are idiots. I used the so called "fastest" implementation around, SBCL. It took me 3 hours to compile and install this, just to prove you how wrong you are.
It takes me 5 minutes total to build the latest SBCL on a Windows XP box which isn't even considered a recommended platform by SBCL devs. It just takes one single fucking command to get the build running and done.
If you have trouble doing something as trivial as running a "sh make.sh", maybe this whole programming thing isn't for you at all?
Oh, and why couldn't you pick a binary distribution, when one was available, if you couldn't build it yourself?
Name:
Anonymous2009-10-27 7:37
>>30 Besides that, PROFILE comes with its own overhead
My version doesn't. See "CALCULATE OVERHEAD"???
That's not cons cells. It's bytes allocated you retard.
Angels on a pinhead, ad hominem,
Haha, shows you don't even know the language if you type that in.
straw man argument, FORMAT is incredibly complex, yet it's so well optimized that it only had to alloc ~400 bytes to print that string.
Yeah, it had only ~380 unecessary bytes allocated. We should be glad it didn't blow up as well? Also, like you said it's incredibly complex but misbehaves on something simple, I wonder how it'd do for complex input... CRAP!
Just like you manually malloc and free your strings.
I don't. Take a look at this code and LEARN what means to be fast
#include <stdio.h>
int main(void)
{ char s[] = "OP is a faggot"; unsigned int i = 0; while(i++ < 100000) sprintf(s, "%s", s); return 0; }
Bytes allocated: 14 bytes for the string, 4 bytes for int and another 4 for the return value (int). I was right: lisp sucks.
Name:
Anonymous2009-10-27 7:42
It takes me 5 minutes total to build the latest SBCL on a Windows XP box which isn't even considered a recommended platform by SBCL devs. It just takes one single fucking command to get the build running and done.
We don't use the same hardware, nor the same OS.
If you have trouble doing something as trivial as running a "sh make.sh", maybe this whole programming thing isn't for you at all?
What a compelling argument.
Oh, and why couldn't you pick a binary distribution, when one was available, if you couldn't build it yourself?
Because THAT exactly is your plan. You're just trying to find an excuse for lisps inferiority, namely that it is a slow clunky piece of shit that leaks ~380 bytes in every iteration with it's "complex" tools. I don't want complexity if that is the price (FYI lisp isn't complex). If I had chosen a binary distribution, all the replies would say "Lisp performs much better in the compiled version! lisp rocks!". I'm not having that. Today, lisp and the faggots of this board was exposed.
Name:
Anonymous2009-10-27 7:43
Today, ... the faggots of this board was exposed.
How is that any different from any other day
>>33
I could easily make it not alloc any memory if I wanted it not to. If I want to write C in Lisp, I can do so, but what reason do I have to do that? For all practical purposes this is fairly fast. If I really needed to run that FORMAT 1000000 times, I would just cache the value by typing 2 extra characters to make the string loaded at readtime or perform some other sort of caching.
I'm not going to waste my time clearing up misconceptions about Lisp in your head nor how you misinterpreted the results of a simple benchmark.
You're so desperately trying to look for an excuse not learn Lisp, then don't learn it! People come to Lisp to learn something, and gain a valuable tool. If you have no need for such things, then why do it? You don't need stupid excuses like this not to learn it.
General on topic reply: tuning your Lisp application for performace isn't that hard and there's many books that go into excellent detail about this. Oh, and whoever responded to this thread seemed to be under the impression that Lisp is all Cons cells, which is just wrong, it has plenty of rich data types: http://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm Arrays, Hashtables, Strings, Characters, Numbers of all kinds(integers, fixnums, bignums, ratios, complex, etc), Classes/Instances/Meta-classes, Structures, Cons cells and so on.
You're just trying to find an excuse for lisps inferiority, namely that it is a slow clunky piece of shit that leaks ~380 bytes in every iteration with it's "complex" tools.
I used one of the more complex output functions to show that even in the worst case scenario it doesn't really alloc much. And there's a huge difference between leak and alloc/free by gc.
It's easy to make this not alloc a single byte if it need be (cache it), but that wasn't the point of that example...
Name:
Anonymous2009-10-27 8:08
why the hell are you guys even allocing any memory if the text is constant?
shit is illogical