Hacker News new | past | comments | ask | show | jobs | submit login





On x10 (no optimization yet so consing is killing performance):

firmament: 10

firmament, 10

genesis 10

version 10

Evaluation took:

  2.798 seconds of real time

  2.813069 seconds of total run time (2.677126 user, 0.135943 system)

  100.54% CPU

  8,125,595,437 processor cycles

  934,110,048 bytes consed


It's just testing the output. For benchmark each variant is run 5 times with kjvbible.txt as input and then the lowest execution time is used as benchmark.


In that case, unoptimized lisp for kjvbible.txt at 0.365 is 3rd fastest beating C


Do you have the same exact hardware that the article is using? Otherwise, we can't say one way or another on that with the data you've provided.

I'm also pretty certain the article is benchmarking against the 10x copy file for the actual benchmarks.

See this example command in the article:

    time $PROGRAM <kjvbible_x10.txt >/dev/null
So, even if you had the exact same hardware, I'm pretty sure your program would only be a bit faster than the unoptimized C# version. However, it's possible that your machine is a lot slower than what's used in the article, and your program is actually pretty fast -- but without more points of comparison, we just don't know. You haven't run the other benchmark programs on your hardware and posted the results.


It would be interesting to have the article author run the lisp code on their machine for a real comparison - would be very interested to see the results. My machine is a Linux (Ubuntu) laptop. I just sent an email to the author with the common lisp code - we'll se if he's interested enough to check.


It seems like he did. (Or may be someone else's. I didn't check the repo.) Common Lisp is the second slowest on his results table.


Missed the sample set from the example. on the kjvbible.txt file with no optimization: ... WEB> (time (performance-count "/home/frederick/kjvbible.txt"))

the 64015

and 51313

of 34634

26879

to 13567

that 12784

in 12503

he 10261

shall 9838

unto 8987

for 8810

i 8708

... Evaluation took:

  0.365 seconds of real time

  0.370322 seconds of total run time (0.338364 user, 0.031958 system)

  101.37% CPU

  1,060,005,621 processor cycles

  106,297,040 bytes consed
I had a bug in my original code which alphabetized rather than sorted by count, so the sort line should be:

((keys (sort (alexandria:hash-table-keys map) (lambda(x y)(> (gethash x map)(gethash y map))))))




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: