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
>>40
It's pointless, but the whole point of the example was to show that text output/formatting functions are pretty fast. There was no need to use FORMAT there at all, not only that but that code doesn't generate any real side-effects, so it's just garbage for the gc to feed on. In one case, one implementation just removed the entire thing as it deemed it dead code. The only reason the function was tested to output to a string and not to the console, is because then it would just be testing the operating system's console code performance. A fair benchmark would instead either output the data to a file or just discard it altogether or pipe it to nul.
Name:
Anonymous2009-10-27 8:47
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?
Well, let me see, efficiency, a ram smaller than 4GB, power.
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.
Notice how the blind lisp moron changes his position accordingly; first it was "lisp is fast" now it is "fairly fast for practical purposes". You don't need to cache anything, the compiler can use memoization, at least C compilers do.
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.
If you're not going to waste time trying to change something about my opinion then it makes me wonder why you argue with me. Do you just want to advocate lisp and show your lisp buddies that you're the coolest geek in the block?
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
No it isn't. Lisp is cons cells and atoms.
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.
These can all be expressed in terms of cons cells and atoms. Another reason why lisp is slow - all the run-time mix-match and jumps from superclass to subclass lookup is no good, CLOS is the only thing lisp got right all these years and nobody uses it because they don't want to approach the rest of lisp. I can continue bashing lisp forever, but please make it at least enjoyable by arguing PROPERLY with me (something most lispers can't/won't do).
Name:
Anonymous2009-10-27 8:49
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.
380 bytes more than needed is not "much"? You sound like a spoiled brat, and what spoiled you is moma-industry with its Moores law.
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...
I don't think so, but you're welcome to try.
This thread is fucking retarded. Morons compare performance of high-level dynamically-typed expressive multiparadigm programming language with high level assembly, e.g. C. Congratulation, idiots.
Well, let me see, efficiency, a ram smaller than 4GB, power.
There have been embedded Lisps that used less than 48KB of RAM total. There's some modern implementations aimed at such limits, but they barely interest me as I do have 4GB of RAM and a fast CPU, and so do all my boxes that I'm going to run my software on, however in practice the Lisp image would be using between 10-30mb of RAM, and then fluctuate up and down by a few dozen MB as the application conses and gets gc'ed. You can actually write apps that cons little or not at all, but lets be fair and say that most Lisp programmers won't write such things unless they either hit a performance wall or just need to microoptimize everything from the start (in which case they might as well be using C if they're planning to specify every little detail anyway).
You don't need to cache anything, the compiler can use memoization, at least C compilers do.
Many Lisp compilers can do memoization, but if you don't trust your compiler or want to do your own? It's only a few extra characters(locally cache something at readtime) to a few lines of code to implement such a mechanism (full memoization at runtime). In Lisp, implementing all kinds of (front-end) optimizations you might want your compiler to implement is easy, and people do it all the time because of that. (Back-end optimizations are just as doable, but the implementation would no longer be portable in most cases as it depends on a specific backend...) These can all be expressed in terms of cons cells and atoms.
Sure, but it's a waste of memory to only use cons cells. Any serious Lisp implementation tends to just use arrays and structures(memory layout) to implement more complex objects. A cons cell is just a structure with 2 elements. If you're not going to waste time trying to change something about my opinion then it makes me wonder why you argue with me.
You showed you don't know Lisp very well in the previous examples, that nullified any interest in me arguing with you. Why would I argue about things someone doesn't fully understand? I would be fine arguing with someone who knows Lisp inside-out. Such a person can actually make valid arguments about things to dislike or that might need fixing in Lisp. Your problems are not actual issues to any real Lisp programmer. The only reason I'm arguing with you is not to change your opinion since you seem dead-set on thinking that Lisp isn't for you, but to make sure you don't misinform other readers of /prog/.
380 bytes more than needed is not "much"? You sound like a spoiled brat, and what spoiled you is moma-industry with its Moores law.
It's plenty, but it's very very little for most modern hardware. Not only that, while the case I gave doesn't need this at all, but a real use of FORMAT might need to use that memory.
Name:
Anonymous2009-10-27 9:33
maybe i should start programming in lisp.
my computer has 6GB of memory, but i hardly ever see over 3GB in use at one time :(
>>52
get with the times, man.
memes run in loops.
1. Enjoyed by all.
2. Hated by all but newfags.
3. Abandoned by newfags.
4. Used only by oldfags (who were previously newfags).
5. Goto 1.
Name:
Anonymous2009-10-27 9:44
>>53
"newfagging" is not a meme, and we still don't do it on /prog/.
Name:
Anonymous2009-10-27 9:45
There have been embedded Lisps that used less than 48KB of RAM total.
What does THIS have to do with anything previously said? Do you realize we're discussing about SBCL and state of the art lisp implementations? (which could be more aptly characterized as state of the fart lisps). But of course, you're a lisper. Tedious as it may be, I'm going to point out every illogicy of yours.
I do have 4GB of RAM
How did I guess?
however in practice the Lisp image would be using between 10-30mb of RAM, and then fluctuate up and down by a few dozen MB as the application conses and gets gc'ed.
Misinformation, and dare I say the worst kind, for its unintentional. Just because YOUR stripped down implementation under YOUR system... Let's take a look at mine;
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2009
Type :h and hit Enter for context help.
[1]> (room)
Number of garbage collections: 0
Bytes freed by GC: 0
Time spent in GC: 0
Bytes permanently allocated: 791,004
Bytes currently in use: 32,207,216
Bytes available until next GC: 401,048
Notice: bytes freed is equal 0. That's a pretty useless GC if it can't clean its own mess! the real number to look at here is the bytes in current use. Not surprising, I'm using about 32MBs just to invoke clisp, and like you said, it's the most lightweight (sic) implementation.
Let's try something now:
[7]> (prog1 t (loop repeat 1000000 collect (random 1))
t
[8]> (room)
Number of garbage collections: 2
Bytes freed by GC: 417,784
Time spent in GC: 10,000
Bytes permanently allocated: 791,004
Bytes currently in use: 32,894,888
Bytes available until next GC: 344,168
That's a +0.8MB increase, performance slowed down by the GC and a pending bag of bytes to slurp. I didn't even use the notorious CONS.
You can actually write apps that cons little or not at all, but lets be fair and say that most Lisp programmers won't write such things unless they either hit a performance wall or just need to microoptimize everything from the start (in which case they might as well be using C if they're planning to specify every little detail anyway).
In other words, lisp programmers should just use C if they want to be precise. Wonderful! We agree.
Many Lisp compilers can do memoization,
Excuse me, "many"? There's hardly 10 lisp implementations out there and I know at least two of them did not perform this optimization you talk about (in contrast with C - the bsd compiler, gcc, icc, lcc, pcc and the list goes on, and they all perform this kind of optimization). C has real software. Lisp does not - it was an ambitious project that sinked WTR.
Sure, but it's a waste of memory to only use cons cells.
Another confession came out. Keep 'em coming! Yes, cons cells are a waste of memory. I pointed that out first.
You showed you don't know Lisp very well in the previous examples,
You haven't provided a SINGLE example of my incompetence or yours. In fact, that is negative for you since you have the burden of proof, but I'll let you slack some more.
Your problems are not actual issues to any real Lisp programmer.
great way to treat criticism and a serious critic. what an asshole.
>>55
[7]> (prog1 t (loop repeat 1000000 collect (random 1))
t
[8]> (room)
Number of garbage collections: 2
Bytes freed by GC: 417,784
Time spent in GC: 10,000
Bytes permanently allocated: 791,004
Bytes currently in use: 32,894,888
Bytes available until next GC: 344,168
That's a +0.8MB increase, performance slowed down by the GC and a pending bag of bytes to slurp. I didn't even use the notorious CONS.
Do you even know what CONS is? Do you know how LOOP or the COLLECT clause works?
COLLECT works by collecting elements into a list... How do you make lists? By chaining CONSes! COLLECT is a bit more advanced, as in most implementation it's implemented by keeping a reference to the tail cons and appending the last element in O(1) time as opposed to O(n) for normal appending.
As for the stripped down implementation claim. I use multiple CL implementations, from SBCL to CCL to CLISP to ECL, and they have different memory footprints, which may vary by depending on compilation settings used and of course what is loaded into them... just like normal applications do.
Name:
Anonymous2009-10-27 9:51
I find trolling Factor coders to be funnier, because all the reasons it's supposed to be better than other PLs are so obviously delusions, it's pathetic.
That's because unlike C and such, there are no static executable segments to fetch from disk on demand, and share between executables.
libc is small, but a Lisp image isn't. This is due to inclusion of the whole developer enviroment in every instance of the image: compiler, relevant debug info (source forms, xref, docstrings, you name it). Source forms take a lot, check out ROOM usage before and after loading a few systems.
Lisp wasn't traditionally meant for multiprocessing (and remains a poor choice). It's not The Lisp Way to run a Lisp program from Unix command line. The Lisp Way is to either run it from the REPL or some CLIM command prompt.
Lisp parallelism is based upon threads. I know explicit locking sucks, but there are many ways to make threads suck less: dataflow-oriented programming; message-passing; STM (or so i herd, implicit locking) and moar.
Shit like dataflow or STM that's impossible to express elegantly in this langs like Java or C++ is pretty elegant in Lisp. And yes, there are many working implementations.
(format 'nil control ...) allocates a fresh string every time.
Name:
Anonymous2009-10-27 10:02
'implicit locking' supposed to go after close-paren.
s/this langs/shit langs/
Name:
Anonymous2009-10-27 10:05
CL-USER> (time (loop repeat 1000000 do (progn (format nil "OP is a faggot"))))
Evaluation took:
3.225 seconds of real time
3.246455 seconds of total run time (3.186459 user, 0.059996 system)
[ Run times consist of 0.262 seconds GC time, and 2.985 seconds non-GC time. ]
100.65% CPU
5,146,799,916 processor cycles
576,125,952 bytes consed
NIL
CL-USER> (time (loop repeat 1000000 do (progn #.(format nil "OP is a faggot"))))
Evaluation took:
0.001 seconds of real time
0.000000 seconds of total run time (0.000000 user, 0.000000 system)
0.00% CPU
2,001,288 processor cycles
0 bytes consed
I'm not sure if I like this thread. It's at least programming related, but is filled with so much bullshit and misinformation I may as well be on reddit/slashdot/stack overflow. *sigh* Downvoted
>>62
So the way to make lisp code tolerable is to not run it? I agree.
Name:
Anonymous2009-10-27 11:04
>>62
Cheating, C can do that too.
#define dot(x) x
int main(void) { unsigned i = 0; while(i++ < 10000) dot("OP is a faggot"); return 0; }
Try to compile this with -O2 and strip unecessary information from the resulting executable.
and DON'T you dare claim it is not the same, or else you don't understand the c preprocessor nor the #. read macro.
P.S. the "2,001,288 processor cycles" number is a purely theoritical one (say, a hard bound). The truth is the processor took more cycles than that. I could probably refuse to believe any of your numbers, you biased lisp farthead.
>>65 and strip unecessary information from the resulting executable
With what flags? You get a hell of a lot of unnecessary bullshit (like 10kb) when you compile anything with gcc/mingw on windows
>>69
Oh, isn't that right? Do you want me to lose my humour now too? Hey listard, what caused you to get the blues? Don't you like being told santa claus isn't real?
>>65
you're so fucking stupid, I can't fucking believe it. here's a proper version
(let ((string "OP is a faggot"))
(defun prog-trollan ()
"it's dangerous to go alone. here, take this"
(setq string string)))
I have no fucking idea where you pulled that "soft bound" from. maybe your ass.
>>71
Actually, I wasn't on anyones side. But you are the one who was throwing his toys out of the pram and calling people names. I also thought it was cute that you called him out for being biased.
>>86
I think MrVacBob is a pretty cool guy, eh makes his own avatards and doesn't afraid of nothing.
Name:
Anonymous2009-10-27 20:38
Good greif, 20 MiB just to execute this simple hello world solution?! This is why lisp will never be ready for the desktop. I'll just keep coding in .NET 4.0, thank you very much. (dotimes [x 10] (prn "Hello, world!"))
>>88
Lisp will "never be ready for the desktop" is more a product of "how i parentheses? u mad?" than "this implementation uses too much memory" and will be for the foreseeable future. That said, 20 MiB is too much, even if we were using something like Sepples
>>90
It's because it contains the entire environment, including compiler and everything else available at runtime. If you want less, you need to treeshake your image.
>>88
Clojure? Doesn't that come with the entire JVM and the entire Clojure environment. I don't see how it would be less. If you want less, you'll need a real Lisp environment.
Name:
Anonymous2009-10-28 9:09
Would Dylan have been a successful, acceptable substitute for Lisp, had Apple not withdrawn their support for it?
>>95
If you can't handle a simple, honest question, then it is you who is trolling yourself.
Name:
Anonymous2009-10-28 9:18
>>94 implying there is an acceptable substitute for Lisp （゜Д゜）
Name:
Anonymous2009-10-28 9:23
>>94
Nothing Apple supports will ever be successful. Witness the failure of inventions like Hypercard, Firewire, PowerPC, Objective-C, multitouch, wi-fi, USB.... Hmm, I fucked up somewhere
Name:
Anonymous2009-10-28 9:27
>>99 supports or invents?
because i'm not a macfag, but i'm pretty sure macs have monitors, keyboards, and mice.
you best be trolling if you're implying apple invented wi-fi and usb.
>>105
Don't know but I'm relatively certain I'd seen them in component catalogues before I'd even heard of the iPod
Name:
Anonymous2009-10-28 10:30
>>33
[quote]#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; }[/quote]
This is actually an UB.
Here's my attempt at this stupid benchmark, more close to the original Lisp version:
#include <stdlib.h>
#include <sys\timeb.h>
#include <wchar.h>
int main ( void )
{
wchar_t *s;
unsigned int i;
struct timeb time_start,time_end;
int total_duration_sec,total_duration_ms,total_duration;
s = L"OP is a faggot";
ftime(&time_start);
for (i=0;i<1000000;i++)
{
wchar_t *junk;
junk = calloc(strlen(s),sizeof(wchar_t));
sprintf(s,"%s",s);
free(junk);
}
ftime(&time_end);
total_duration_sec = time_end.time - time_start.time;
total_duration_ms = time_end.millitm - time_start.millitm;
total_duration = 1000* total_duration_sec + total_duration_ms;
printf( "Total duration %d ms.\n", total_duration);
}
// Gives result:
// Total duration 187 ms.
Lisp version:
CL-USER> (time (loop repeat 1000000 do (format nil "OP is a faggot")))
Evaluation took:
0.687 seconds of real time
0.687500 seconds of total run time (0.687500 user, 0.000000 system)
[ Run times consist of 0.096 seconds GC time, and 0.592 seconds non-GC time. ]
100.15% CPU
1,679,401,305 processor cycles
447,993,992 bytes consed
Lisp version is about 3.6 times as slow, however examining the disassembly of the Lisp version shows that it's actually just a simple loop overall, and the major difference is of course time taken for GC and that format is slower since it has to parse much more complex format strings than sprintf.
>>108
It's also a possibly infinite loop on systems where INT_MIN >= -32768.
P.S. memmove(s, s, strlen(s)+1);
P.S.2. /prog/ is a special kind of community: even trolls know programming better than you. I suggest you hesitate before posting ">>X is wrong!" because it might be the case that you sir HBT.
Name:
Anonymous2009-10-28 13:04
>>108 i++ < 100000
Undefined operation. Calling the cops.
Name:
Anonymous2009-10-28 13:50
>>112
That is not undefined. Calling the trollpolicia.