nomemory

Electrons brought us a lot positivity with their negativity! Checkmate!

This guy summarised the community well. I wouldn't go that far to call them unabombers though. Some of them might have some radical ideas regarding the way software should be written. But that's it.

Well at least they are transparent about all that.

> He’s a good son. I also have a daughter. She was a women’s and gender studies major in college. Naturally, she loathes mayonnaise.

This is gold.

Well, I don't consider I've insulted someone by saying I like the way Wikipedia is.

Not at all a complimensult. I can appreciate the work of someone, if even I won't use it. I don't know how to put it otherwise.

I am one of those people who actually like Wikipedia the way it is. It's what I hoped the web to become.

But i am sure there are people who will appreciate your effort. Thank you for your work.

So without playing dumb or anything, you say they say:

"We have security issues every year because we program in unsafe languages like C, and to solve this, we should start rewriting things in Rust because it's 'memory safe'."

Amazing!

So it's more like a "Look, it's possible to do this in Rust!"

than

"We did it in Rust, and we believe it's better because ..."

?

> Many GNU, Linux and other utilities are useful, and obviously some effort has been spent in the past to port them to Windows. However, those projects are written in platform-specific C, a language considered unsafe compared to Rust, and have other issues.

I wonder why some people in the Rust community seem to remind us every few sentences how Rust is superior to C because it's safer.

/s And now it's C, yesterday it was C++... what's next, ASM ?

Coding is just electrons having fun.

You can have hash tables that cannot be targeted by DoS attacks.

You can use a family of hash functions and seed the hash table instance with a key.

The attacker won't be able to do make assumptions regarding collisions because he doesn't have access to the initial key.

The point of the article was too prove that it's hard to do Open Adressing in Java and beat HashMap performance, that uses Separate Chaining.

The article contains also a Robin Hood implementation that overall works worse than HashMap. If you can give something recommendation on how to improve it I would forever in debt.

I didn't perform any deletes, and I've tried to keep everything clean without allocating intermediary objects. But one the pitfalls is that I cannot play easily on the memory lane with Java. For example in the entries and bins implementation I had to have two separate arrays. In C I would've kept a single array, with a compact zone, and another sparse zone, iterating through it using an offset.

Didn't have time to write about it, but I've used a GCProfiler as well. With a few exceptions, all the 5 implementations are comparable.

I've assumed they were inline initially, until I profiled and found out one of the swap methods was not. I believe there's also a limit on the amount of bytecode to inline, so no matter how hot a method, if the associated bytecode reaches a certain threshold it won't be. I need to double check though.

Maybe it was even more terrible, because it tried to be "smart".

Exactly, in Java i couldn't even inline my functions, and had zero control over the underlying memory layout.

I consider myself an optimist.

For me it was faster on average and with less variance. But the micro-benchmarks are flawed by default, so I believe it's room to improve them.

Also maybe there are some tricks that can be done, to have a faster Open Addressing implementation in Java.

PS: I've also tried Cuckoo Hashing and Hopscotch and they were also slower, but haven't managed to document my findings.

Exactly.

Looking at some discussions the open-jdk team had, they decided to continue with Separate Chaining. I don't have the link, but then I got interested to see how some Open Addressing (nothing fancy) will behave in Java, so this is the reason I've written this "article".

Unfortunately I coudln't beat HashMap with the "classic" approach, but I got close. I am curious to see a better implementation that brings more engineering tricks on the table.

I would love to see Nim used more in web development. I have a strong irrational dislike for go, and Nim feels right to me as alternative. Unfortunately without corporate support, it's hard...

harps , sharps, I believe this is pure parody, right, right ?

I remember when I was a kid, my father did this to a qbasic game with two monkeys throwing bananas. He eventually modified it so they can throw two instead of one.

I am a math hobbyist, and I wanted to work on my linear algebra knowledge. So I've decided to implement some of the most common algorithms from the CS curricula.

After some work, I've come-up with this small library. It has no production value, but it was fun learning experience.

https://github.com/nomemory/neat-matrix-library

I don't think there's consensus and very few people have a total grasp of the subject.

Look Java and python for example. The people working on the languages are quite smart, and they decided to take different routes. Who was right ?

There are a few valid points, but also unfounded pessimism.

The amount of stable libraries and stable innovative products is amazing. It's normal there's chaos, but what is good will survive the test of time.