tripcode cracker in lisp

tripcode crackers are pretty easy to write. perhaps all you smug lisp weenies could demonstrate how lisp's superiority by writing a tripcode cracker that can do better than the ~400kcps 4brute-johnbs does on my computer?

Write me a tripcode cracker because I'm too stupid.

Is that what you meant?

>>2
more like "show me that lisp is actually worth learning  by doing something useful with it".
i already have a very fast tripcode cracker that i wrote in c.

I know I can't do that, so I'll try to weasel my way out.

Is that what you meant?

C is ofcourse faster than lisp, anyone who disagrees is a fool.
A tripcode cracker is not a trivial or semi-interesting program due to it's brute nature; therefore not worthy written in lisp.

>>5
it is trivial and bitslice DES is somewhat interesting.

>>6
Reimplementing and reinventing the wheel sure is interesting.

>>1
You're expecting way too much of a toy language.

>>5
C has crypt, Lisp doesn't.. that's why I wrote it in C

>>5
An average Lisp programmer using SBCL produces faster programs than an average C programmer. The C programmer is bound by the limitations of his language, and will ultimately concentrate on  the trees and miss the forest, producing a suboptimal algorithm that runs as fast as possible. The Lisp programmer has probably achieved Satori, and will use the best algorithm, which, ran at just a bit slower than C speed (SBCL), will easily outdo the C programmer's crap.

>>7
is that why we have about 7 million suboptimal implementations of fib in lisp?

>>9
why not write your own crypt in lisp?
or better yet, do bitslice DES in lisp.

LISP FAGS CAN'T DO SHIT!

Real Lisp programmers don't have to crack tripcodes, they can instantly calculate the key from looking at a tripcode.  That's one of the powers SICP gives you.

But remember this when reading SICP:  With great power comes great responsibility. (From Spiderman the movie.)

We will not help you crack codes, or use our powers for evil.

>>11
optimal fib requires matrix multply, so you want a vector based language, as cool as lisp is

fib(n) =

ans_mat = [[1,1][1,1]]^(n-1)

return(ans_mat[0,0])

end

If your matrix multiply is optimized using strassen's algorithm or the like, you just rock the house speeed wizzy.

or just use the fib formula

>>1
Oh, I'm sure Lisp compilers will totally own the highly optimized C/ASM code you stole from John the Ripper.

Give us something that isn't completely rigged from the start or go away.

>>17
gb2/soc/

Properties and shared methods   access to members.

It's been three years and the Lisp weenies still haven't proven themselves. Another victory for PHP.

>>20
Thread necromancy is a war crime.

>>21
My other war is a wdr.

>>1,20
The problem is trivial enough, but why would I rewrite an already rewrite something that has been done so many times.
The bottleneck of such code would be the DES implementation. A lisper would either use a library with bindings to openssl or similar to get crypt() from it, or reimplement crypt themselves. I doubt reimplementing crypt in Lisp would be faster than the optmized asm version, at best it would match its speed(with enough declarations added). I just looked over the 'bitslice' DES implementations and they would be trivial to implement indeed, however if you truly want speed, you shouldn't stop at just compiling some C or Lisp code to x86 asm, instead you should look into:
1) Parallelization - multiple threads for normal CPUs, or:
2) Hardware implementation: DES can be very efficiently implemented in hardware, much faster than you can do with sequential CPUs.
Besides threading, a poor man's solution of 2 is to use things like CUDA-based DES crackers or build your own using a bunch of FPGAs, or if you are truly rich, build a lot of DES cracker ASICs, then DES will be a joke to you. If needed you may use Lisp in the hardware design process, afaik there are/were some EDA tools which are/were Lisp-based.

If you want a more practical example that makes use of Lisp's speed and power, you should look at CL-PPCRE.

Another victory for PHP.
... Oh, IHBT.

>>23
I like that you said that as if implementing DES in assembly is easier than spawning a bunch of processes.

my other mario is a mdrio

my other AIDS is a DIDS

>>26

Don't DID.

DO.

>>27
laughingelfman.jpg.base64

My other laughingelfman.jpg.base64  is a ldaughingelfmdn.jpg.bdse64

My other meme is a mdy-mdy

My other anus is a dnus

>>29
Is your other caar a cdadr, too?

my other cabbage is a cdbbdge

my other dns is ddns         ;)

>>33
My other cabbage is a Babbage :)

TripCUDA: close to 1GTrips/sec on a mildly overclocked GTX295.

I doubt you can beat that.

This just in!
C is better than Lisp for low-level programming when speed is important!

>>37
It's hardly a 'this just in'. Even /prog/, which has an above average number of fp weenies has never really denied that C is still the best low level language we have. It's a shame,really, but it's not changing any time soon.

>>38
OR IS IT

>>39
I was reading a periodical the other day, which basically compared performances of different languages. C was consistently on top in all but one of the testing criteria.