rwallace

No. The Chinese have already developed frontier models. And we would be fools to assume that's a permanent end to the list. North Korea has nuclear weapons. Iran has ballistic missiles and leading edge military drones. There is no fundamental reason why both countries shouldn't be able to train frontier AI models.

Trying to protect ourselves by putting restrictions on the technology would be like trying to hide from a tiger by wrapping a towel around our heads on the basis that if we can't see it then it can't see us. That trick only works on imaginary monsters, not real ones.

I haven't used Proton, but based on my experience with other cloud storage products and seeing other people's reports thereon, it looks to me like you are running into the problem that there are two different use cases for them with opposite requirements:

1. Local storage is cheap, I have lots of it. I want multiple copies of my data so that they will serve as backups. I want everything in the cloud to be copied locally. (I'm in this category.)

2. Local storage is cheap if you look at the price of external hard disks, but my phone or tablet only has a limited amount of it, and no way to upgrade without buying a whole new device, so it is scarce for me. I want nothing in the cloud to be copied locally, unless I am specifically using it on this device. (Sounds like you're in this category.)

Half the people think the first use case is the obvious one. Half the people think the second is the obvious one. And that includes developers, who will design the product accordingly without giving it much thought. So either half the users get a nasty surprise in the form of running out of disk space, or the other half risk an even nastier surprise in the form of data loss.

Obviously, computers pester us with too many questions these days, but I think this is one case where the software really does need to ask the user which behavior they want. Perhaps with a hint based on how much local disk space seems to be available.

Yes, I think that's what the paper is saying. The validation is the hard part, but the part that provides the value, because it's what makes the result actually useful.

Eh.

There are certainly things wrong with today's economy, starting with housing being treated as a financial asset, which encourages laws that create an artificial scarcity of it. I'm not saying there is nothing to complain about.

But the fact that not everyone is working purely to create necessities, that some of our economic output consists of luxuries? I don't really see that as a problem to be solved. If anything, I think it's a good sign. Let's not fall into the trap of just randomly complaining about everything.

Ah! So let me paraphrase to make sure I understand. In your experience, the real use case of denormals is not that you want to compute with them. It's that they are a useful error signal, because they typically indicate that the equations are badly conditioned, which means the results cannot be trusted. So in that scenario, silently flushing them to zero is bad, but so is silently computing with them. What you really want is for denormals to raise an exception?

The one way I know of for denormals to arise in real calculations is when you have a process that converges on zero. In which case, values will pass through the denormal range on the way from the normal range down to zero. And converting denormals to zero is obviously correct.

What other cases have you seen of denormals arising in real calculations?

Because they believed only a small fraction of customers would care a lot about a better Basic interpreter, whereas the vast majority would care about price. As for giving things away for free, Commodore was already engaged in a cutthroat price war with Texas Instruments that almost sank the company. They could not afford to give anything else away for free.

I didn't know about that event. What did he say to get booed that time?

I looked into that, concluded the spoiler is Specter.

Basically, you have to have out of order/speculative execution if you ultimately want the best performance on general/integer workloads. And once you have that, timing information is going to leak from one process into another, and that timing information can be used to infer the contents of memory. As far as I can see, there is no way to block this in software. No substitute for the CPU knowing 'that page should not be accessible to this process, activate timing leak mitigation'.

Happy new year from Ireland!

Sure. If you feel the need to write "this is shitty code", fair enough, I'm fine with making allowances for that kind of language. But please leave it at that, instead of also insulting the people who wrote it. There are, unfortunately, plenty of ways for bad incentives to result in competent people creating bad products.

In general, if a program is not a Web browser, I do not want that program getting clever with displaying a URL as an active link. Just show it as the URL, https prefix and all, so I can see where it will be taking me if I copy it into the browser. (This is one of my very few gripes with Google docs.)

Fair enough! If you ever have the time and inclination to write it up as a blog post or such, I would love to read it.

I disagree with your second sentence above. I think it is shallow dismissals that are inappropriate here. Conversely, I have upvoted a number of long explanations of interesting topics.

If you don't have time to write a detailed refutation, that's entirely understandable! But if you do, I would love to read it.

I did appreciate your paragraph length comment on the matter elsewhere in this thread.

Or unless delete is a rare operation. So yeah, to make the best decisions here, you need to know expected numbers as well as expected access patterns.

As far as I can see, you are indeed going to incur one extra memory access apart from the object itself, for any design other than just 'Temporarily flag the object deleted, sweep deleted objects in bulk later' (which would only be good if deleted objects are uncommon). It still matters how many extra memory accesses; deleting an object from a doubly linked list accesses two other objects.

It also matters somewhat how many cache lines each object takes up. I say 'somewhat' because even if an object is bulky, you might be able to arrange it so that the most commonly accessed fields fit in one or two cache lines at the beginning.

No problem!

As to what would be better - this is also a reply to your sibling comments above - I don't have a single across-the-board solution; the equivalent of std::vector everywhere is fine for some kinds of application code, but not necessarily for system code. Instead, I would start by asking questions.

What kinds of entities are you dealing with, what kinds of collections, and, critically, how many entities along each dimension, to an order of magnitude, p50 and p99? What are your typical access patterns? What are your use cases, so that you can figure out what figures of merit to optimize for? How unpredictable will be the adding of more use cases in the future?

In most kinds of application code, it's okay to just go for big-O, but for performance critical system code, you also need to care about constant factors. As an intuition primer, how many bytes can you memcpy in the time it takes for one cache miss? If your intuition for performance was trained in the eighties and nineties, as mine initially was, the answer may be larger than you expect.

To clarify a couple of things:

I'm aware of the reasons Linux uses doubly linked lists. I'm still of the opinion this design decision made a lot of sense in the 1990s, and would make less sense in a new project today. You may disagree, and that's fine! Engineering is constrained by hard truths, but within those constraints, is full of judgment calls.

I'm not a member of the evangelical Rust community. I'm not proclaiming 'thou shalt rewrite it all in Rust'. Maybe you have good reasons to use something else. That's fine.

But if you are considering Rust, and are concerned about its ability to handle cyclic data structures, there are ways to do it, that don't involve throwing out all the benefits the language offers.

Yes, that was exactly the reason. CJK unification happened during the few years when we were all trying to convince ourselves that 16 bits would be enough. By the time we acknowledged otherwise, it was too late.

I read that paragraph, but my reading of it was different from yours. As far as I can see, it only discusses training time and experience. No mention of time for sleep.

Though yes, I do give it credit for going at least a little of the way - not far enough, but a little - in pushing back on the 'human error' scapegoating, in favor of asking questions about procedures and policies.

In several similar incidents, it was clear that the, or at least a major, cause of the accidents, was that the officers on watch had been forced to work overtime and deprived of sleep to the point of cognitive impairment.

How many hours had the officer on watch in this case worked that week? How many hours of sleep did he have?

And why is no one except me asking those questions?

I predict that it will never make sense for artificial neural networks to directly generate machine code, for most of the same reasons it doesn't make sense for biological neural networks to do so.

That's an interesting question about the number of levels of address translation. Does anyone have numbers for that, and how much latency and energy an extra layer costs?

I'm not aware of any CPU invented since the late eighties that doesn't have paged virtual memory. Am I misunderstanding what you mean? Can you expand on where you are getting the 4x number from?

As I understand it, the philosophy dates from centuries before that, and was inspired at least in large part by the frequency of earthquakes there.

I'd like to apply, but the job pages just offer 'see open positions' in a loop, no clear way to get to an application form, and the 'contact us' page doesn't accept a Gmail address. Am I missing something?

I'm seeing quite a few people on this site recently talking about their Kagi subscriptions, claiming it is sufficiently better than Google to be worth the money.

I leave a handful of actually important notifications on, like the one that says 'someone just made a purchase using your bank account, making sure it was you', but most of them, I do indeed turn off.

Beware of concentrated benefit and diffuse cost. Sure, let a seconds clock be available to call up the 0.1% of the time when you want it. But it shouldn't be in the system tray presenting a small but ongoing attention drain the other 99.9% of the time.