injinj

8 ms·

31.
by injinj 5y ago
My gut feeling with io_uring is that it wouldn't help as much with messaging applications with 100 byte request/reply patterns. It would be better in a with a pipelined situation, through a load balancing front end. I would love
32.
by injinj 5y ago
Great work, thanks! I'm curious whether disabling the slow kernel network features competes with an tcp bypass stack. I did my own wrk benchmark [0], but I did not try to optimize the kernel stack beyond pinning CPUs and busypoll, bec
33.
by injinj 5y ago
"We found that states with higher income inequality experienced a higher number of deaths due to COVID-19." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7313247/
34.
by injinj 5y ago
I prefer the 1950s style, the produce isn't wrapped to death in plastic. My general rule is that the more plastic it has, the further away it was produced. The small Asian places have their own farm pipeline for the specialty vegetab
35.
by injinj 5y ago
I have a graph for this: https://github.com/raitechnology/raikv/blob/master/graph/mt_... The CPU in this case is a Threadripper 3970x, 32 cores, 64 SMT. My experience is this: When the L3 cache is
36.
by injinj 5y ago
Yeah. "Refactor" may be more accurate.
37.
by injinj 5y ago
No, I don't believe that's what it means in this case. I took the usage to mean that since Rust has memory model which is different enough from C to require a redesign. I looked at many implementations of Redis and read many KV p
38.
by injinj 5y ago
I've done a C clean room version and I will say that the networking part is as important as the multi-threading the data structures: https://github.com/raitechnology/raids/ . If you go to the landing page of
39.
by injinj 5y ago
Just trying to expand on the points made by GP. 1. Salt is randomly generated, I see no reason why this would not be the case other than using the salt parameter incorrectly. I primarily want the GP to list the symmetric ciphers which miti
40.
by injinj 5y ago
Do I have this right? 1. A duplicate salt, which in this case should be a 16 byte random value, causes an repeated use of an KEY+IV for AES, which allows for a dictionary attack on the KEY (which looks like a password in this case) and wea
41.
by injinj 6y ago
Amusingly, I've done a multi-threaded version of the word counting program in order to test a shm kv store. I needed benchmark that created a lot of cross thread concurrent accesses to keys and I found a blog about this test. My vers
42.
by injinj 6y ago
The meow 0.4 was faster at short keys, but failed at the smhasher "LongNeighborTest" [1]. However, doubling the AES rounds makes it pass that test. Two rounds is enough for full diffusion in AES [2]. I recently looked at comput
43.
by injinj 6y ago
I was thinking of extending my shell (desh) so that stores the environment and history on a server so that a shell started on any host in a network could optionally stay in sync with the other instances. Eg. ENV={ssh host envstore} ; HIST=
44.
by injinj 6y ago
$ taskset -c 1 redis-server $ taskset -c 2 redis-benchmark -p 6379 -P 8 -q -c 1 -n 100000 PING_INLINE: 775193.81 requests per second PING_BULK: 869565.19 requests per second SET: 724637.69 requests per second GET: 787401.56 r
45.
by injinj 6y ago
I would bet that the redis-benchmark and the redis-server were running across the CCD, not tasklocked to CPUs on the same chiplet. I have a 3970x, I'll run this test on different chiplets and the same chiplet...
46.
by injinj 7y ago
I'll bet he is aware. The problem with the trading industry is that they have hundreds of users with bespoke solutions catering to extreme performance criteria rather than hundreds of thousands like NATS. They will keep reinventing t
47.
by injinj 7y ago
The problem with first class functions in a shell is that the main duty of a shell is to fork processes. Once the shell is forked, the only communication available are inter process. All of the environment is no longer shared. For example
48.
by injinj 8y ago
This is notable, because this is what rurban/smhasher does in the small key test, which many are using nowadays. In SpeedTest.cpp, there is a function called timehash(): uint64_t *aligned_result = (uint64_t *) aligned_alloc( 64, 25
49.
by injinj 8y ago
The cache line latency is strongly associated with the number of hash call repetitions. At 1, 2, 3, 4 repeats, the latency is not present in the timestamp counter. From 5 -> 9 repeats, the latency builds, adding 2 cycles of latency eac
50.
by injinj 8y ago
Good point. I created a graph with these attributes: 0 total += hash (XXH364) 1 seed += hash (XXH364Seed) 2 seed += hash, val += hash (XXH364SH) https://gist.github.com/injinj/138543ccc6a23ceb1fcdc05f46288... There a
51.
by injinj 8y ago
I can make Meow pass the LongNeighbors test by doubling the number of AES rounds on each pass. The original Meow algo: while(Len >= 64) { S0 = Meow128_AESDEC_Mem(S0, Source); S1 = Meow128_AESDEC_Mem(S1, Source +
52.
by injinj 8y ago
Hmm, Meow fails the TwoLongNeighbors test. More information on this test here: https://github.com/hmakholm/smhasher/blob/master/src/LongNei... [[[ Keyset 'TestLongNeighbors' Tests ]]
53.
by injinj 8y ago
Meow is a freak of nature, it has a constant overhead for all of the small sizes. I added Meow to my test graphs: https://github.com/injinj/smhasher I still find xxh3 to slightly faster for small hashes on my machine
54.
by injinj 8y ago
I just re-ran this with a total += hash(). It adds about 2 - 4 cycles to the throughput test (the non-latency graph).
55.
by injinj 8y ago
Yes, it is the same size. I agree, a complex test like that in the original article is better (the Throughput versus Latency section). The graphs from the "latency" test are doing this: for (;;) { h = hash( val, seed );
56.
by injinj 8y ago
I added xxh3 to my fork of smhasher: https://github.com/injinj/smhasher I find it to be the fastest hash in my stable of hashes. Graphs for 64 / 128: https://github.com/injinj/smhasher/bl
57.
by injinj 8y ago
Look at the aeshash in the go runtime: https://github.com/golang/go/blob/master/src/runtime/asm_amd...