Show newer

For what I could run, here's the info:

- 576 bytes at exit
- 20 allocs
- 18 frees
- 5408 bytes allocated

- 488k bytes at exit
- 31 allocs
- 16 frees
- 534k bytes allocated

That puts ECL squarely in the same ballpark as Go, and SBCL roughly between Go and Python. If /deallocs is more important, then clearly these CLs outperform Go here.

Of course I have no runtimes here and this is just one poorly implemented micro benchmark.

Show thread

I'm trying out different CLs and I can't figure out how to consistently invoke with valgrind. With cmucl I can't even see how to invoke a cl program as a script. I guess CLs often have an interpreted vs compiled mode, too; so my approach may be incongruous to CLs in general?
I also tried timings, but the one example I found just returns 0 for the execution time; so that's not helpful.
For something that was just a curiosity, this is really killing my interest.

Isn't there some saying about how programming in common lisp is at least 50% programming the loop macro?

Show thread

I'm looking at some common lisp solutions for common lisp and its all the loop macro.
I think I need to come to terms with loop!

It's bizarre. Decent CPU performance, better than other dynamic languages by quite a bit; but completely shitting the bed on memory usage.

Show thread

I'd like to write the same micro-benchmark in scheme and common lisp, then compare the multitude of implementations available for each. I'm very curious!

Show thread

Based on my extremely limited exposure so far, I would say that Julia looks interesting, but is still way too early to use for production. I'm worried they might not be able to make it good enough compared to the competition considering they're at 1.6 and the memory usage just appears to be completely bugged.

I am no expert and I only did the most minimal of experimenting here; so don't let me dissuade you. I'm just writing for myself here.

Pretty interesting stuff, to be honest!

OK, programming done for the day! (I think!)

That was a fun little experiment.
I played with a trivial fizzbuzz type problem in 5 different languages, using Valgrind to profile memory usage and iterating 10k times to find average execution time; discounting startup and shutdown overhead.

If I did it correctly, then Zig is:
0 bytes in use at exit
0 bytes allocated
0 allocs
0 frees

I think this is because Zig uses non-standard allocators for everything so Valgrind just doesn't know what to poke at.

Show thread

I don't know what's up with Zig; but Valgrind reports 0 for all.
I have some work to do there, though - I need to average the execution times properly. It's been a while since I've written Zig and I need to look up the dynamic array APIs.

Show thread

The memory profile of Julia gets worse when running the microbenchmark in a 10k loop.

In use at exit: 99MB
Allocated: 195MB
Allocs: 484K
Frees: 463K

This is crazy!

Python: 294K, 4.12MB, 2.38K, 2.25K
Ruby: 36MB, 51MB, 64K, 44K
Go: 3K, 15K, 74, 63

I'm not missing suffixes on the Go one.

Show thread

I ran the core microbenchmark in a loop iterating 10k times; then averaged the results.

I get 18.57ns for Julia compared with 0.15ms for Python and 0.11ms for Ruby.

That seems more in-line with the claims I've seen. Although that's also a very small number. I wonder if everything useful is getting optimized away by the jit.

Show thread

Running into type trouble trying to figure out how to reduce over an array in Julia.
The compiler warnings, julia reference docs and trying to cram this into my day are not aiding my progress here.

Running Valgrind on my Project Euler #2 solution yields 50MB of allocations and 28MB of memory usage at exit.

For #1 I wrote the equivalent Python to compare with Julia.

Py: 294kb in use at exit, 2335 allocs, 2200 frees, 3.83mb allocated.
0.223s real

Julia: 26mb in use at exit, 200393 allocs, 155140 frees, 50mb allocated.
0.040s real

That is a TREMENDOUS difference.
Obviously a micro benchmark with the usual caveats... but HOLY COW.

Ah, well forcing desktop mode for the site at least gives you more info.

Stupid "mobile view" that reduces a website to practically worthless.

Show thread
Show older

A instance dedicated - but not limited - to people with an interest in the GNU+Linux ecosystem and/or general tech. Sysadmins to enthusiasts, creators to movielovers - Welcome!