About LISP

I started playing around with some LISP because you faggots never stop talking about its greatness and I'm truly amazed. At how shitty it really is.

A simple loop printing "hello world" eats up 40MB of RAM. And if you start up 10 of them it takes up 400MB. What the fuck?

No wonder no one uses this garbage.

>>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.

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).

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.

>>42

Proceed.

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.

>>45
YHBT

>>46
Damn, it's difficult to be newfag these days.

>>45
As soon as I ask for some real PROOF, this is all I get from lispers.

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.

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 :(

>>49
Feels like c.l.l

>>47
We don't “newfag” on /prog/.

back to /b/, please

>>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.

>>53
"newfagging" is not a meme, and we still don't do it on /prog/.

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

Welcome to GNU CLISP 2.48 (2009-10-03) <http://clisp.cons.org/>;

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
FFFFFFFFFFFFFFFFFFFFFFFFFFFFF YOUR A FUCKING MORON

>>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.

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.

>>40
macroexpand-1 loop.

>>1

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.

>>40

(format 'nil control ...) allocates a fresh string every time.

'implicit locking' supposed to go after close-paren.
s/this langs/shit langs/

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

NIL

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.

>>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.

lol at Ctard refusing to run his own benchmarks

>>66
shut up. you know I'm right.

>>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

you biased lisp farthead.
12 y.o. much?

>>68
Just use your compiler with the -s flag.

>>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.

>>73
run away. chicken out. lackey.

>>74
This is why we need IDs again

>>75
Oh shit I had forgotten we had IDs. Oh the lisp threads trying to get LISP match...

>>75
How do we get ID's back?  Somebody contact that MrVacuumCleaner guy or whatever who owns stuff....  I'm sure he'll do more than moot

>>75,77
Now's not a good time, I think. Maybe in a couple of years.

posting in epic thread

That's why we can't have nice things.