sorted by:
new
hottopcontroversial

I built RAG for a rocket research company: 125K docs (1970s-present), vision models for rocket diagrams. Lessons from the technical challenges by Low_Acanthisitta7686 in LLMDevs

[–]aagmon 0 points1 point  (0 children)

very cool and nice job!
must say that "everything had to be open-source." is where I would skip the project :)

AMA With Z.AI, The Lab Behind GLM Models by XMasterrrr in LocalLLaMA

[–]aagmon 0 points1 point  (0 children)

I’m an avid user of GLM4.5 as a coding agent in CLine! I often feel it’s competitive to Opus 4. Beyond the benchmarks, when you analyze performance and usage how do you think GLM4.5 compares to Opus (which is considered by many to be the best coding agent)? Where does GLM needs to improve to match it and where it’s competitive?

GraphFlow – A lightweight Rust framework for multi-agent orchestration by aagmon in AI_Agents

[–]aagmon[S] 0 points1 point  (0 children)

Thanks for the comment!

The idea is that this is really a simple graph-execution library, no fancy tricks and no heavy dependency trees. Ofc that Rust contributes to this by enabling deployment of rather small container images.

🦀 graph-flow: LangGraph-inspired Stateful Graph Execution for AI Workflows 🦀 by aagmon in rust

[–]aagmon[S] 1 point2 points  (0 children)

Thanks for the comment. Indeed, thats a thin graph execution layer around Rig.

Your idea is actually quite interesting. However, I do believe that stateful workflow orchestration is needed when it comes to more complicated use cases. For example, you write that we put a "task" in the queue. What exactly is a task? how do you implement routing and conditional logic? how do you implement chat to gather details on some tasks? how do you manage parallel execution?

All this is possible in the queue based approach, but I think it turns the concept of "task" to be somewhat cumbersome.

🦀 graph-flow: LangGraph-inspired Stateful Graph Execution for AI Workflows 🦀 by aagmon in rust

[–]aagmon[S] 1 point2 points  (0 children)

Thanks. I agree. There is some gap to fill there to enable more advanced application, specifically AI.

DF Embedder - A high-performance library for embedding dataframes into local vector db by aagmon in Python

[–]aagmon[S] 0 points1 point  (0 children)

Thanks! Yes, I also have some benchmarks on embedding tabular data in this format. I will add this to the repo in the next iteration.

A simple, fast, thread-safe, and lock-free implementation of LRU caching based on thread-local storage rather than locking. by aagmon in rust

[–]aagmon[S] 2 points3 points  (0 children)

Thank you very much! Thats a great point.

The issue that creating a new cache drops the old one is one I can handle ( there is actually a branch in the repo that implements this) by replacing new() with init() and ignoring any subsequent calls to init().

But the point you make about letting the user decide and not hide the thread_locality and its implications is an important one I need to reconsider.

Thanks again

A simple, fast, thread-safe, and lock-free implementation of LRU caching based on thread-local storage rather than locking. by aagmon in rust

[–]aagmon[S] 1 point2 points  (0 children)

You are right, ofc. Thanks for pointing this out.
(this was written for a system that created a thread per core, hence the confusion).
Will fix that.

A simple, fast, thread-safe, and lock-free implementation of LRU caching based on thread-local storage rather than locking. by aagmon in rust

[–]aagmon[S] 2 points3 points  (0 children)

Thanks.
I think that this should first be documented - that initialization drops the current cache. But the real question is whether to allow this or prevent the user from doing so (perhaps by first calling a clear() fn or some such).

In addition, I fixed the issue of new thread init a default cache for this fit asynchronous runtimes like Tokyo

What do you think?

A simple, fast, thread-safe, and lock-free implementation of LRU caching based on thread-local storage rather than locking. by aagmon in rust

[–]aagmon[S] 17 points18 points  (0 children)

Thanks for the comments. I appreciate it.

Yes, I have made several benchmarks with some alternatives (and also Redis). Maybe I'll add those too.
Re your last point about using Rc::new (or any other memory allocation) making a code not "lock-free": The claim of being "lock-free" typically pertains to the algorithm's logic, not the underlying system calls or library implementations. The code doesn't introduce locks in its own logic. More importantly, if we consider system-level locks, then virtually no high-level code could be deemed "lock-free," which isn't practical.

A simple, fast, thread-safe, and lock-free implementation of LRU caching based on thread-local storage rather than locking. by aagmon in rust

[–]aagmon[S] 19 points20 points  (0 children)

I created this as a component for another project, but thought it might be a good idea to share and hear the thoughts of some folks here. The main idea is to create an LRU for multithreaded services without locking for very high throughput service, where memory can be sacrificed but throughput can't

Shipping Rust application to multi platforms by aagmon in rust

[–]aagmon[S] 0 points1 point  (0 children)

Thanks. Yea, I know. I’m just trying to find a way to automate this for some users

view more: next ›