HackerTrans
トップ新着トレンドコメント過去質問紹介求人

ayende

no profile record

投稿

"Optimizing" Concurrent Regexes

ayende.com
2 ポイント·投稿者 ayende·22 日前·0 コメント

The 'Million AI Monkeys' Hypothesis and Real-World Projects

ayende.com
1 ポイント·投稿者 ayende·4 か月前·0 コメント

AI Agents Security: The on-behalf-of concept

ayende.com
2 ポイント·投稿者 ayende·10 か月前·0 コメント

コメント

ayende
·2 か月前·議論
Nevertheless, you are still talking about 15B / year - when the initial investment was < 30B. That investment also probably covers things like power, salaries, etc.

So you are still covering all of that.
ayende
·7 か月前·議論
All financial systems don't care about time.

Prety much all financial transactions are settled with a given date, not instantly. Go sell some stocks, it takes 2 days to actually settle. (May be hidden by your provider, but that how it works).

For that matter, the ultimate in BASE for financial transactions is the humble check.

That is a great example of "money out" that will only be settled at some time in the future.

There is a reason there is this notion of a "business day" and re-processing transactions that arrived out of order.
ayende
·7 か月前·議論
Committing to NVMe drive properly is really costly. I'm talking using O_DIRECT | OSYNC or fsync here. Can be in the order of whole milliseconds, easily. And it is much worse if you are using cloud systems.
ayende
·7 か月前·議論
Isn't that very much intentional on the part of GCC?
ayende
·7 か月前·議論
That suffer from a serious issue

You must have the data upfront, you cannot build this in an incremental fashion

There is also bo mention on how this would handle updates, and from the description, even if updates are possible, this will degrade over time, requiring new indexing batch
ayende
·8 か月前·議論
Not this is explicitly marked as Not Planned
ayende
·8 か月前·議論
> maintenance_work_mem

That kills the indexing process, you cannot let it run with limited amount of memory.

> How do you think a B+tree gets updated?

In a B+Tree, you need to touch log H of the pages. In HNSW graph - you need to touch literally thousands of vectors once your graph gets big enough.
ayende
·9 か月前·議論
Probably avoid zero write optimizations. This force actual allocation of disk space for the data, instead of pretending to do so.
ayende
·9 か月前·議論
Amazon Glacier on the list is a pretty big surprise to me.
ayende
·9 か月前·議論
That isn't spying. That is called doing code review on a shared depenendcy
ayende
·10 か月前·議論
OpenAI, Ollama, DeepSeek all do that.

And wanting to programmatically work with the result + allow tool calls is super common.
ayende
·10 か月前·議論
Even with very small number of requests - what happens when you have two concurrent ones?
ayende
·10 か月前·議論
This is wrong, because your mmap code is being stalled for page faults (including soft page faults that you have when the data is in memory, but not mapped to your process).

The io_uring code looks like it is doing all the fetch work in the background (with 6 threads), then just handing the completed buffers to the counter.

Do the same with 6 threads that would first read the first byte on each page and then hand that page section to the counter, you'll find similar performance.

And you can use both madvice / huge pages to control the mmap behavior
ayende
·6 年前·議論
With RavenDB, you cannot setup a unsecured server unless you are _really_ trying. And we worked on getting secured setup to be a click through process with under 10 minutes to setup a whole cluster.

You can see it here: https://www.youtube.com/watch?v=K-2iZ_lJVag

That was done explicitly because of issues like that. Security isn't a feature, and the fact that your product keep leaking details is not the fault of the user the 100th time this happens.