thomasmg

> borrow is never tasked with cleaning up data

And the reason for this is that there is no branch needed at the end of the borrow, to check for refCount=0? (Or, is this at least one of the reasons?) I'm wondering about the performance impact for this... There's also the code size impact.

> EB trees heavily rely on bit-addressable data (typically integers)

That seems like a disavantage, but actually most data is bit-addressable in one way or the other; even strings, if you look at the UTF-8 representation.

What I'm a bit worried is the number of levels: it seems to be 1 level per bit in the key. And "a tree node is typically 20-bytes long on a 32-bit system". So that is 20 bytes per bit in the key. I wonder if the memory usage could be reduced in a simple way. For example using larger "pages" that contain arrays.

Improving BWT is great!

In my view, improving "long range" compression has the biggest potential. There are many, many algorithms and implementations for very short range (huffman, arithmetic, ANS) and short range (LZ, BWT), but not that much research has gone into "long range" yet. There's deduplication, and large-window LZ / BWT.. but not much more yet. What is missing is efficietly (and with little memory) finding similarities on multi-GB data sets. I think sorting by similarity would help there. Or did I miss research in this area?

The probability that any person would give Brad Pitt money is nearly zero. But obviously it is not zero! We already know that some people believe weird things.

The problem (for the scammer) is to find out, efficiently, _who_ would give (a lot of) money. In the past, they sent email that had typos - I think on purpose: the probability that someone would send money is higher if he doesn't detect that.

With AI, this got _much_ easier, and scales much better: you can generate very convincing text, images, videos and interact with many, many potential victims. The story itself, it seems, doesn't need to be too convincing.

There are alternatives. I usually use a mix of: (a) what might be the motivation of the person / group to say something. (b) what are the risks of lying, and the consequences. (c) are there other voices and the possible motivation of those etc. (d) can someone verify this at least partially.

Unless if the spent battery calls are released during the flight, via parachute, to be recharched later.

We currently call spent batteries "empty" but in this case spent = "full" (of oxygen).

I think people want is Rust, but simpler. At least by default.

I could imagine people want a programming language that is: memory safe, without GC pauses. A bit slower by default than C / Rust, but with the _option_ to make it as fast. Then easier to learn, less vendor lock-in than Swift, and a modern syntax (no null pointers etc).

I don't think such a language exists currently.

It could be this, or it could be:

He experimenting hours and was proud of what he did. He wanted to show it to as many as possible, so he ignored what the teacher said. He was interrogated. Why more than one hour? It could have taken less then 10 minutes if you ask the teacher. Why was he handcuffed later? The police clearly wanted to make a statement or show.

OK, interesting! If I understand correctly, that means even within the arena, lifetime is tracked. That makes sense - it is Rust after all.

If each arena maintains a counter of live objects, then the arena can be dropped if it reaches zero.

I wonder how to mix multiple allocators in a safe way. Say an arena allocator and the default one. How to prevent the non-arena object points to the arena one? (The problem is: the arena could get wiped, so this pointer would be invalid.) The post is about Rust, so I was hoping this is adressed...

I'm working on my own programming language and want to support multiple allocators. Usually languages just support one OR the other, safely.

No, it's not the L1. It's the L2/L3/LLC. With a regular Bloom filter (not blocked one), each of the k memory accesses results in a L2/L3/LLC cache miss, if the Bloom filter doesn't fit in the cache. And here, it doesn't. With a blocked Bloom filter, there is still a cache miss, but only one, and not k. So that's 8 times fewer cache misses.

But yes, buffering the entries and then sorting them does make sense. That way, each cache line is only accessed once, and prefetch works well. We have used radix sorting for the binary fuse filter https://arxiv.org/abs/2201.01174 . For the blocked Bloom filter I'm not sure if it will help however, due to the added complexity. In my tests, it didn't help. There is the "prefetch" operation but we had mixed results with that (buffering and sorting was faster).

The Bloom filter he uses has k=8, that is 8 cache line misses per entry. (k=8 is in the command line output). A "blocked Bloom fiter" requires only one cache line miss per entry, with a slightly worse false positive rate.

With a good implementation it would be roughly 10 times faster, eg a SIMD implementation. For example here https://github.com/FastFilter/fastfilter_cpp/blob/master/src... (there are others)

In Switzerland, we have yogurt with and without sugar, with and without sweeteners, with and without lactose, etc. You can buy 319 different yogurts in the supermarket: https://www.coop.ch/de/search/?text=yogurt

I remember when I lived in the United States, you basically had "fat free" (with lots of sugar) and "greek" (with a little bit of fat, in addition to the sugar). That was 20 years ago, so it might have changed since then.

> Hand-rolling has a bunch of pitfalls

I'm arguing that this is not the case in reality, and asked for concrete examples... So again I ask for a concrete example... For memory corruption, there are plenty of examples.

For parsing, I know one example that lead to problems. Interestingly, it was about using a state machine that was then modified (manually) and the result was broken. Here I argue that using a handwritten parser, instead of a state machine that is then manually modified, would not have resulted in this problem. Also, there was no randomized testing / fuzz testing, which is also a problem. This issue is still open: https://issues.apache.org/jira/browse/OAK-5367

> Hand-rolled recursive descent parsers as well as parser combinators can easily obscure implicit resolution of grammar ambiguities.

Could you give a concrete, real-life example of this? I have written many recursive-descent parsers and never ran into this problem (Apache Jackrabbit Oak SQL and XPath parser, H2 database engine, PointBase Micro database engine, HypersonicSQL, NewSQL, Regex parsers, GraphQL parsers, and currently the Bau programming language).

I have often heard that Bison / Yacc / ANTLR etc are "superior", but mostly from people that didn't actually have to write and maintain production-quality parsers. I do have experience with the above parser generators, eg. for university projects, and Apache Jackrabbit (2.x). I remember that in each case, the parser generators had some "limitations" that caused problems down the line. Then I had to spend more time trying to work around the parser generator limitations than actually doing productive work.

This may sound harsh, but well that's my experience... I would love to hear from people that had a different experience for non-trivial projects...

I wonder if using the same constant for both multiplications would reduce code size and so could (slightly) speed up computation?

I have updated my StackOverflow answer at https://stackoverflow.com/questions/664014/what-integer-hash...

My guess is: the problem is not the price of the land or the price of the structure, but the permits. In Switzerland, you can put solar panels on existing buildings without requiring a permit.

As the article says, there are many "large" solar panel projects planned in Switzerland, specially in the mountains, where the snow will reflect the light and increase electricity production in winter (where electricity is the most expensive). But it takes a very long time (sometimes many, many years) until those projects are approved, if they are approved at all. This is known to be a problem, and government did try to speed this up, but it still is far too slow. (I'm Swiss.)

The paper is available, so feel free to check yourself. BMI was taken into account. Fast food I do not see, but where did you read about this association?

The index itself is also a b-tree (unless if it is fully in memory). You also have to consider writes and reads in this index. There, locality also matters. Sure, not as much as with the data itself. But I have seen cases where the index lookup (with randomly distributed UUIDs) was the bottleneck, and not reading the rows. Even thought the row where 1 KB on average.

UUIDs are globally unique (unique with such a high probability that in practise there are no collisions, if you follow the spec). But they are not cryptographically safe. So the time part is not a "leak" in this sense. If you need something cryptographically safe, then you would need to encrypt the UUID.

I was skiing last week, where ski goggles are the norm... So yes, currently it might be weird, but things change. Did you watch or read "Ready Player One"? There it is the norm.

The problem is not "UUID" but "random UUID". The randomness makes it hard to index and query, due to missing locality. UUIDv7 is time-sortable, and so has locality. For details, see for example https://uuid7.com/ - the main reason (for me) is this part: "Since UUIDv7 is time-sortable, database indexing mechanisms can better optimize the storage and retrieval processes...".

A garage is not needed, and you don't need to plug it in overnight. (My electric car is in a carport, and I only plug it in charge is below 50%.)

Yes, it is inconvenient (and likely more expensive) if you can't charge the car at home, or at work. Cities have electric street lights, but curb-side EV charging is rare so far. I guess that will change.

Heating the battery does need some energy, but heating the interior of the car (for the passengers) needs more. But driving needs most energy, of course. Electric cars typically have a heat pump by the way. Gas cars don't need that because they can use the waste heat of the engine, which is otherwise lost.

Better managed is not necessarily more expensive in the long run, specially when tanking into account secondary benefits such as improved economy because companies that care about stable grids build factories there. But yes, short term it is more expensive.

From what I know, EVs have lower cost of maintenance and car insurance, and same cost for repairs.

Yes, I also prefer the beautiful oil rigs, and the nice smell of coal in the air. Anyway, all the buildings made by humans are so nice to look at, except for the really really ugly solar and wind installations!

Why "without replacement"? The question doesn't seem to refer to multiple events. For just one event, it doesn't matter if you do with or without replacement, because there is nothing that can be replaced.

The RR diagrams are images, while the SQLite diagrams are SVG. In my view, SVG is better: it allows copy & paste. SVG would also allow adding links directly in the diagrams, but SQLite doesn't have that (so far).

The diagrams for the H2 database [1], and Apache Jackrabbit Oak [2], do have links. (I wrote the generator for those.)

[1] https://h2database.com/html/grammar.html [2] https://jackrabbit.apache.org/oak/docs/query/grammar-sql2.ht...

Elon Musk used an image of a farting unicorn to promote Tesla.

Me too. Reading the article, there seems to be no attempt to replace the two remaining "if" statements, and so, avoid branches. It doesn't even need to be CMOV: possibly introducing tmppar1 and tmppar2 = tmppar & (an operation that is either 0 or -1). And then always rp12 ^= tmppar1; rp14 ^= tmppar2; -- it might not be faster, but that's what I would try at least.