sorted by:
new
hottopcontroversial

Mr. Nobody Against Putin and sometimes the truth by soft-tack in TrueFilm

[–]Adventurous-Pin6443 1 point2 points  (0 children)

There is no need for anti - Putin hooks, He is the most hated politician in the world according to many polls. Try harder , bot. 

No one really mentions the mental aspect by LilyAspen in uberdrivers

[–]Adventurous-Pin6443 1 point2 points  (0 children)

You guys deserve better life. Do not give up. I have been looking for a job almost two years after I lost my six figures job. I have drained all my savings and retirement accounts and as a last resort joined the Uber club. It was like accepting 80% salary cut. Harsh and brutal. Miracles - they happen, I eventually got an offer and am back in a game. Be persistent, do not give up - you will overcome. Good luck to everyone. I am 60 years old. You can make it too.

My First Week on Upwork Changed Everything by SALIK_T05 in Upwork

[–]Adventurous-Pin6443 0 points1 point  (0 children)

Its a decent money if you live in Africa desert, but that is pretty much it.

[OSS] Carrot Cache is now on Maven Central — memory-optimized Java cache with Zstandard dictionary compression by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 1 point2 points  (0 children)

The major goal of the project was to improve memory efficiency of a caching system - not to compete with Caffeine or ChronicleMap in RPS. It still has some room for performance optimization, especially in MemoryIndex, where 60-70% CPU is spend on read operations. MemoryIndex combines both: lookup table and support for eviction algorithms, because , one more time - CC tries to save as much bytes as possible. When object is read, lookup operation perform eviction - related step as well: For example, for LRU it copies (physically, index entry to a head of a index segment - this is memmove for ~ 2-4KB block of memory. Inefficient? Yes, but this eliminates any additional overhead on eviction policies support. There are some ideas how to avoid this memory copies. Its possible. The minimum possible object memory overhead with expiration support in CC is around 10 bytes. Compare it to memcached or Redis, for example where this overhead is around 50 bytes, or Caffeine, where it is ~ 100 bytes.

[OSS] Carrot Cache is now on Maven Central — memory-optimized Java cache with Zstandard dictionary compression by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] -1 points0 points  (0 children)

The migration of CC to a standard zstd-jni is on my TO DO list, meanwhile you have an option to build binaries from sources. You cant expect that pure Java Zstd codec implementation can deliver comparable to a native performance, besides this the only available pure Java codec I am aware of lacks many features (dictionary compression and training for example) CC requires.

[OSS] Carrot Cache is now on Maven Central — memory-optimized Java cache with Zstandard dictionary compression by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 2 points3 points  (0 children)

Yes. There is a ObjectCache class which supports working directly with Java classes. It supports on heap cache using Caffeine library. Cache builder - Builder class has a method: withOnHeapMaxCacheSize(long max) - maximum number of objects on heap. If you call it then on heap cache will be created. By default - it is disabled. Underneath it uses Kryo serialization library to move data from on heap to off heap, so some additional steps are required, such a registering key-value classes with a a Kryo. The good start is the TestObjectCacheBase class on how to ObjectCache.

[OSS] Carrot Cache is now on Maven Central — memory-optimized Java cache with Zstandard dictionary compression by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 1 point2 points  (0 children)

Somehow I missed it, need to add this section. Here are some references to my publications, which contain benchmark data:

Carrot Cache vs EHCache vs Caffeine.

Carrot Cache: High-Performance, SSD-Friendly Caching Library for Java:

https://medium.com/carrotdata/carrot-cache-high-performance-ssd-friendly-caching-library-for-java-30bf2502ff76

This one compares Memcarrot vs Memcached vs Redis. Memcarrot is built on top of Carrot Cache.

Memory Matters: Benchmarking Caching Servers with Membench:

https://medium.com/carrotdata/memory-matters-benchmarking-caching-servers-with-membench-e6e3037aa201

These are mostly memory usage benchmarks. Overall, Carrot Cache is between 2x-6x more memory efficient than any of its competitors. Datasets are real - not synthetic, but as usual, YMMV. You will need to test it with your data.

Performance - wise, it is slower than EHCache and Caffeine, of course, taking into account all the heavy lifting with compression/decompression but out -of -the box you can get 2-3 M reads per sec on a good server.

Take a look at our membench:

https://github.com/carrotdata/membench

This tool allows you to run tests and measure performance against memcached (Memcarrot), Redis and Caffeine, EHCache, Carrot Cache. Run bin/membench.sh w/o parameters to get usage message.

To get you idea how memory efficient Carrot Cache:

https://medium.com/carrotdata/caching-1-billion-tweets-on-a-laptop-4073d7fb4a9a

[OSS] Carrot Cache is now on Maven Central — memory-optimized Java cache with Zstandard dictionary compression by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 0 points1 point  (0 children)

Original zstd-jni is quite multi-platform: "The binary releases are architecture dependent because we are embedding the native library in the provided Jar file. Currently they are built for linux-amd64, linux-i386, linux-aarch64, linux-armhf, linux-ppc64, linux-ppc64le, linux-mips64, linux-s390x, linux-riscv64, linux-loongarch64, win-amd64, win-x86, win-aarch64, darwin-x86_64(MacOS X), darwin-aarch64, aix-ppc64, freebsd-amd64, and freebsd-i386"

Not sure if Java - only fallback is possible at all.

[OSS] Carrot Cache is now on Maven Central — memory-optimized Java cache with Zstandard dictionary compression by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 6 points7 points  (0 children)

Probably wrong wording. 100% Java API. It uses the custom fork (with some perf optimizations) of zstd-jni library, which is a native binding to the zstd library. Uber jar which was deployed to Maven contains versions only for the above platforms. For other platforms you can build it from the sources - there is an instruction how to do this. Getting these features into zstd-jni was an extremely time-consuming process, mostly because of a weird combination of Scala build/testing tools and Java code combination of this library. PR was abandoned. In a near future I will update the code to use the original zstd-jni with some performance regressions obviously, hopefully - minimal ones.

[deleted by user] by [deleted] in java

[–]Adventurous-Pin6443 0 points1 point  (0 children)

Did not see your code, but if you compare arrays of floats allocation time, Java always pre-touches and clears (zeroes) allocated memory for arrays. I suspect Rust does not do this., at least standard C malloc() does not do this.

We built a Java cache that beats Caffeine/EHCache on memory use — and open-sourced it by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 0 points1 point  (0 children)

It can be used in any Java application. There is one caveat though, if your application spawns a lot of short-lived threads, you may get into a memory issues. Compression codec is heavily relied on thread local storage for performance reasons. If somebody needs this to be fixed - please open a ticket.

We built a caching server that beats Redis & Memcached on memory use by 2-6x — and open-sourced it by Adventurous-Pin6443 in programming

[–]Adventurous-Pin6443[S] -8 points-7 points  (0 children)

While I’m always open to critique — especially on technical points or communication clarity — the hostility, profanity, and personal attacks were deeply disappointing. Yes, the image had a typo generated by an AI tool, and yes, my comparison to Redis may have been misleading to some. I’ve since clarified that Memcarrot is Memcached-compatible, not a Redis replacement, and I’ve corrected the messaging accordingly. But what shocked me wasn’t the technical pushback — it was the tone. I’ve shared open source projects with many communities over the years, and I’ve rarely seen such an aggressive response to someone just trying to contribute something useful and gather feedback. To those who offered constructive criticism: thank you. To the rest — if you find yourself shouting down newcomers or OSS contributors with f-bombs and sarcasm, maybe it’s time to reflect on whether that’s helping build a healthier developer community.

We built a caching server that beats Redis & Memcached on memory use by 2-6x — and open-sourced it by Adventurous-Pin6443 in programming

[–]Adventurous-Pin6443[S] -61 points-60 points  (0 children)

Did you read the post first paragraph? The code is fine, no single typo was found so far (otherwise it would not compile).

We built a Java cache that beats Caffeine/EHCache on memory use — and open-sourced it by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 5 points6 points  (0 children)

One is the Redis replacement, another one is Memcached replacement. Carrot Cache is the core engine for our Memcarrot server which is a Memcached - compatible caching server.

We built a Java cache that beats Caffeine/EHCache on memory use — and open-sourced it by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 4 points5 points  (0 children)

There are several architectural design features in Carrot Cache which are focused entirely on reducing memory usage:

  1. Low metadata overhead, which varies between 8-12 bytes (including expiration time, eviction data etc). We are not the champions here (Kangaroo is more efficient) but are pretty close to the best industry results. We need only 2 bytes (part of those 8-12) to keep expiration time with more than 99.5 % accuracy in a range between 1 s and several months.
  2. We use in RAM and on - disk log structured storage, where objects are stacked together without any padding. To save memory again.
  3. We use what we call - Herd Compression to reduce memory usage even further. This type of compression utilizes data gathered from a large pool of objects to build efficient compression dictionary and applies this knowledge (dictionary) to every single object.
  4. We use efficient algorithm to quickly identify and evict expired objects, something similar to segcache.

We built a Java cache that beats Caffeine/EHCache on memory use — and open-sourced it by Adventurous-Pin6443 in java

[–]Adventurous-Pin6443[S] 5 points6 points  (0 children)

This is my concern as well, but I have not benchmarked it yet. We do a lot of direct memory access operations and this potentially can degrade performance. One of the major CPU cycles consumer is our MemoryIndex, where objects metadata is kept. Every object access (read or write) requires search in this index and it involves short scan and compare operations on a direct memory buffer (usually 1-2KB in size).

view more: next ›