16 Feb
2018
16 Feb
'18
9:01 p.m.
So people have called me on the claim that lisp is not fast. Here's a
rebuttal.
Please write a clone of GNU grep in lisp to demonstrate that the claim
that lisp is slower that C is false.
Best of luck and I'll be super impressed if you can get even remotely
close without dropping into C or assembler. If you do get close, I
will with draw my claim, stand corrected, point future "lisp is slow"
people at the lisp-grep, and buy you dinner and/or drinks.
--lm
16 Feb
16 Feb
9:03 p.m.
On Fri, Feb 16, 2018 at 01:01:14PM -0800, Larry McVoy wrote:
And to help you, here is Mike explaining how he made GNU grep fast.
You are welcome to use the same techniques in lisp.
https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html#
10:05 p.m.
On Fri, 16 Feb 2018 13:01:14 -0800 Larry McVoy <lm(a)mcvoy.com> wrote:
Larry McVoy writes:
If you want to do more of an apples to apples comparison, you
should pick a brand new problem not known to be solved in
either C or Lisp so that both sides start at the same point!
I do think that if you consider just the raw performance as
the sole metric, C will almost always win. After all it is
sort of a portable assembly language & you can compile
programs in most language to C. But in the real world many
other factors matter too. So to make the contest a bit more
fair, you should put a time limit on the effort.
10:28 p.m.
On Fri, Feb 16, 2018 at 02:05:09PM -0800, Bakul Shah wrote:
Nope. It's my challenge and it stands as I stated it. People said
I was wrong when I said Lisp was perceived as slow. I picked a
perfectly reasonable example of a common problem (text processing),
gave a benchmark, gave a pointer to how the C program was made fast,
and asked for a lisp program that even comes close.
If that can't be done, then the claim that lisp is slow still stands.
When people said I was "putting inaccuracies into the archives" or
"perpetuating a myth" I wondered if I was wrong. Nobody said "well,
yes, C is faster for systems stuff or this or that, but lisp is faster
in this domain". They said that the claim that lisp is slow is not
true.
Just saying that lisp is not slow is not the same as demonstrating it.
I'm more than willing to be wrong, that's how I learn. But the proof
here is to show up with a pure lisp grep that is fast as the C version.
I'm no lisp expert, not by any stretch, but I've never seen a lisp
program that out performed a well written C program.
The point was that lisp was/is perceived as a slow language. Several
people said that's false, I'm just asking for them to demonstrate that
it is false by writing grep in lisp. Who knows? Maybe it can be done.
10:53 p.m.
I definitely agree with your words. Furthermore I point to the fact
that lisp is totally different to any other language, the archaic
algol, cobol and fortran languages included. Therefore one makes
automatically mistakes after longer periods of intensive
lisp coding and vice versa, despite the fact that the lisp approach
basically is very simple, not to say oversimplified. Anyhow there
aren't many lispers anymore. In business lisp plays no role at all.
Its a pet of so backward oriented academicians.
At 16 Feb 2018 22:29:33 +0000 (+00:00) from Larry McVoy <lm(a)mcvoy.com>:
11:01 p.m.
On 2/16/2018 5:53 PM, Donald ODona wrote:
Anyhow there
aren't many lispers anymore. In business lisp plays no role at all.
I know of
a first-person shooter game that has embedded scripts in the maps.
The scripting language in the maps is ... LISP. ;) - Not sure if it's
JIT, but it's definitely interpreted and not compiled.
It's been around since the early 2000's, has versions on XBOX and PC and
newer versions are being released to this day. Knowing the company
creating these new versions and maps, I doubt they moved away from LISP.
Good ole Halo.
10:56 p.m.
Has ANY language (except assembler) EVER outperformed C in a big way?
Give or take any optimizations that may be done by either?
On 2/16/2018 5:28 PM, Larry McVoy wrote:
I'm no lisp expert, not by any stretch, but
I've never seen a lisp
program that out performed a well written C program.
11:02 p.m.
I suspect that back in the day Fortran may have beat C for scientific
computations (vector stuff would be my guess). But x86 extensions do
vectors as do the GPUs so I don't know of anything that beats C in a
big way.
On Fri, Feb 16, 2018 at 05:56:59PM -0500, Arthur Krewat wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
11:18 p.m.
On 2018-02-16 5:56 PM, Arthur Krewat wrote:
As Tim wisely pointed out, performance isn't a property of a language,
but a program, so the idea that C is some kind of untouchable ultimate
in speed makes no sense. There are aspects of its design that militate
_against_ performance and preclude optimisations that are possible in
other languages.
Therefore nobody should be shocked that programs in other languages
certainly _have_ beaten C for the same tasks. An illuminating example is
the Haskell Mio system which has benchmarked to outperform C web
servers. Expect more progress from that direction.
--Toby
11:41 p.m.
On Fri, Feb 16, 2018 at 06:18:28PM -0500, Toby Thain wrote:
Nobody claimed that. I claimed, based on what I've been told by people
who programmed in lisp and some small personal experience, that lisp
was and is perceived as a slow language, certainly slower than C.
Lisp fans hate that claim because they want everyone to program in Lisp,
or at least let them program in lisp.
I tipped my hat to the belief, I've never experience it myself but I've
heard it claimed, that a skilled lisp coder solves problems, especially
compiler like problems, in lisp faster than a skilled C programmer would.
I think that reality is that lispers like lisp because they can claim
they are "done" faster than they would if they had to do the same thing
in C (or other procedural) languages.
That is a HORRIBLE reason to like a language. In my not at all
humble opinion. If lisp were a language that was easy to read, for all
programmers not just people who love lisp, OK, maybe. But it is not,
it's a miserable language to scan and understand. Contrast it with C or
go or any of other procedural languages. Any programmer can read C
and quickly understand what it is doing. The same is not true of
lisp.
I strongly suspect that lisp people optimize for speed of writing
whereas most experienced people optimize for the speed of reading.
It's write one, read many.
Therefore nobody should be shocked that programs in
other languages
certainly _have_ beaten C for the same tasks.
But not lisp. Or at least, nobody wants to take up my grep challenge.
--lm
P.S. For the record, I tried to like lisp. I wrote lisp programs,
I tried. Just like I tried to like emacs. I'm apparently not smart
enough to join the hallowed grounds where the lispers live. C/vi for
stupid me.
11:49 p.m.
On Fri, 16 Feb 2018 14:28:35 -0800 Larry McVoy <lm(a)mcvoy.com> wrote:
By issuing this challenge you automatically "win" as no one is
going to take up your challenge and spend the kind of time
that was needed to optimize GNU grep. Very clever of you! But
if you are serious, it is only fair that both sides start with
a clean slate.
Here's a somewhat related problem: Consider trees with zero or
more integers as leaves. For example, ((1 2)3(4 (5 () 6))).
A file contains 0 or more such trees. Write a tree-grep to
find and print trees with matching fringes. For example:
.*3.*5.* matches the above tree
.*(3).* doesn't as there is no subtree with 3 as its sole leaf
.*(.*2)[2,3].* also matches
.*(.*2.+).* doesn't as 2 is the last leaf and we want at least one more
.*(4#(.*().*).*).* matches -- (4...) contains (.*().*) 0 or more levels down.
. is any, * is 0 or more, + is 1 or more, # is like ** in zsh.
[...] is used to specify alternatives. e.g {0-5,11-23, 99-}.
Assume unsigned ints.
#(5.*) says there is some subtree with 5 as the first leaf.
Syntax needs to be refined to be able to exactly specify
the shape one wants.
For extra credit also generate a tree-sed!
http://www.ffconsultancy.com/ocaml/ray_tracer/languages.html
Has a comparison of several languages used for implementing
raytracing. Harrop's graph is weird but for 32bit word
machines Stalin comes close to g++ results.
11:34 p.m.
On Friday, February 16, 2018, Larry McVoy <lm(a)mcvoy.com> wrote:
Good challenge. I consider anything that came out of MIT's ITS/Lisp
(including Emacs) culture as totally opposite to the UNIX/C culture.
Complexity vs. minimalism are the best words to explain both approaches to
computing.
--Andy
2644
days inactive
2644
days old
11 comments
6 participants
participants (6)
-
Andy Kosela -
Arthur Krewat -
Bakul Shah -
Donald ODona -
Larry McVoy -
Toby Thain