
A 10-minute description of how Judy arrays work and why they are so fast - joss82
http://judy.sourceforge.net/doc/10minutes.htm
======
jemfinch
Also worth investiation: a comparison of 20000 lines-of-code Judy versus a 200
lines-of-code hash table: <http://www.nothings.org/computer/judy/>

~~~
AlisdairO
It's worth noting that this comparison is flawed: Judy (iirc) is designed for
64 byte cache line sizes, yet the test is performed on a 32 byte cache line
processor. Currently, most common processors have a cache line size of 64
bytes, so nowadays it's quite likely that Judy is a fair bit faster. Further,
the processor is old enough that memory delays were (while still important)
perhaps less of a big deal than they are now: the relative latency of RAM to
processor speed wasn't as bad.

Yes, this does highlight the problem with such heavily optimised structures -
that they are somewhat hardware specific - but it doesn't mean that this is an
accurate demonstration of the performance improvement you'd see nowadays.

~~~
tptacek
The fact that Judy has to be optimized (and extensively modified) for specific
architectures is a big part of this article's critique.

~~~
AlisdairO
Absolutely, and I certainly acknowledge that this is a fair criticism. I guess
my beef with it is more that the tone of the article is "Judy has to be
extensively modified depending on the machine it runs on, and it's not even
_that_ much faster" - whereas, given that he's testing it on a machine for
which Judy was not optimised, one could quite reasonably take the position of
"While you have to optimise Judy for the machine it's running on to get the
best out of it, even if you don't it's substantially faster than a hash table.
The downside is code complexity".

Personally, while the 32-byte cache line size is mentioned as an aside in a
couple of places, I'd prefer to see it acknowledged in a bit more of an
upfront manner. He doesn't exactly go out of his way to say that Judy would be
a lot faster on a different machine.

------
ars
At one point data structures were tuned to work fast when loaded from disk
(avoid seeks, try to read linearly).

Then they were tuned to work fast from inside main memory (avoid jumps).

Now they are tuned to work within the typical cache of a CPU (keep reads near
each other).

~~~
anamax
You forgot tapes (don't seek, and we mean it) and avoid arithmetic.

Today, divides can be cheaper than branch mispredictions and cosines can be
cheaper than cache misses.

------
Irfaan
The very last line from the article:

 _Well I cannot describe Judy in 10 minutes -- what possessed me? I hope you
understand some of what I have said and question me on the rest --
particularly those doubts. I will try to elaborate on parts where I get
questions._

An interesting read, nonetheless. But a warning for those expecting a full
description in 10 minutes. :)

------
bsaunder
EDIT: Sorry, placed comment on wrong parent, should be on:
<http://news.ycombinator.com/item?id=1419647>

In this post.

 _Additionally, some of Judy's space and speed improvements come from
strategies that could be used by any data structure but aren't because they're
not good software engineering._

Seemed like an odd statement. That's like saying "Assembly is obtuse and it's
bad software engineering to use it." IMHO, it depends. If you are writing low-
level code that will run very frequently, perhaps good engineering would
suggest that you should optimize in assembler.

I think, there are places in your code where you need good runtime performance
and spending programmer time and sacrificing generic dogma are justified.

Like the author says at the end. If some tool/library/service meets my needs
(in this case robust and fast being among them), then I'm not too concerned
about how it gets there:

 _Of course, you can certainly take the attitude that Judy performs well
enough, and the fact that it's 20,000 lines of code doesn't really matter, as
long as those lines of code work and you never have to look at them--and it
appears Judy is mature enough that this is the case._

------
darose
Funny this should get posted today. I was just reading about this very data
structure last week!

------
torpor
I love Judy, I have used it for years, its really the only dynamic array a C
programmer needs .. ;) Well, okay Judy + list.h (from the linux kernel) == all
you need!

~~~
jerdfelt
sys/queue.h

It has singly-linked list, lists, simple queues, tail queues and circular
queues.

If you're comfortable with Linux kernel style lists, then sys/queue.h will be
familiar, and it's shipping in glibc and on BSD systems (where it was
originally from).

~~~
torpor
You're right, sys/queue.h is wonderful ..

