Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pron
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
27 ms
·
331.
▲
by
pron
6mo ago
Feminism is not femininity and so is not to be contrasted with masculinity [1]. Feminism is originally about gender (power-) equality (and so is orthogonal to femininity and masculinity), but has been extended to other forms of power equali
332.
▲
by
pron
6mo ago
Sorry this is long, but you successfully nerd-sniped me :) > Other than C, Rust, Go, Swift? C# can use value types, Java cannot. So famously that Project Valhalla has been highly anticipated for a long time. Obviously the JVM team thinks
333.
▲
by
pron
6mo ago
> Using a language that doesn't box every single value is going to reduce RAM consumption AND be easier on the CPU. Which is what most people are talking about on this post. What popular language does that? I admit that rewriting th
334.
▲
by
pron
6mo ago
A C compiler is a 10-50KLOC job, which the agents bricked in 0 days despite a full spec and thousands of hand-written tests, tests that the software passed until it collapsed beyond saving. Yes, smaller products will survive longer, but how
335.
▲
by
pron
6mo ago
> There are (at least) two glaring issues with your analysis. First, the vast majority of workloads don't block on CPU (as I previously pointed out) and when they do they almost never do heap allocations in the hot path (again, as I
336.
▲
by
pron
6mo ago
POC, sure (although 10x-ing a POC doesn't actually get you 10x velocity). MVP, though? No way. Today's frontier models are nowhere near smart enough to write a non-trivial product (i.e. something that others are meant to use), min
337.
▲
by
pron
6mo ago
> From a model-checking point of view. This is about taking a proof-theoretic approach... No. In complexity theory we deal with problems , and the model-checking problem is that of determining whether a program satisfies some property o
338.
▲
by
pron
6mo ago
> We're also a neural network, are we any more clever than a simulated one? This is tangential, but it is highly unlikely that we are "a neural network". Neural networks are an architecture loosely inspired by some aspec
339.
▲
by
pron
6mo ago
The problem is that the search space is so large that correcting errors via guardrails is only effective if the original error rate is low (how many Integer -> Integer functions are there? There's ~1 way to get it right and ~∞ ways
340.
▲
by
pron
6mo ago
Their combined biomass [1] (which also gives them superior computational power; they sense more information, process more information, and they can actuate more change) Humans are very powerful compared to our biomass , but not enough to o
341.
▲
by
pron
6mo ago
I think there are entities here on earth more powerful than us already, but intelligence has nothing to do with their power. BTW, I'm not saying that (real) artificial intelligence couldn't hypothetically pose a serious threat, bu
342.
▲
by
pron
6mo ago
Love this! They may say that a superhuman intelligence would give you many Sheldon Cooper discoveries, and Sheldon did say that his theories need no validation and that science should just "take his word", but in the end he got hi
343.
▲
by
pron
6mo ago
> But in a general sense, I understand why he argues for it. Andrew is not wrong, but he's talking about optimisations with relatively little impact compared to others and is addressing people who already write software that's
344.
▲
by
pron
6mo ago
That's just not true. To give you a few pieces of the picture, moving collectors move little memory and do so rarely (relative to the allocation rate): In the young generation, few objects survive and so few are moved (the very few tha
345.
▲
by
pron
6mo ago
I don't think any of them do. Some organisms/viruses or groups of organisms could destroy humans more easily than humans could destroy them. There's no doubt humans possess some powers (though certainly not godlike) that othe
346.
▲
by
pron
6mo ago
I think there's another problem with AI doomerism, which is the belief that superhuman intelligence (even if such a thing could be defined and realised) results in godlike powers. Many if not most systems of interest in the world are n
347.
▲
by
pron
6mo ago
> GC burns far more CPU cycles Far less for moving collectors. That's why they're used: to reduce the overhead of malloc/free based memory management. The whole point of moving collectors is that they can make the CPU cost
348.
▲
by
pron
6mo ago
> increasing cache locality is orthogonal to how much RAM an app is using. It just lets the CPU get cache hits more often, so it only relates to throughout. Cache misses mean CPU stalls, which mean wasted CPU (i.e. the CPU accomplises le
349.
▲
by
pron
6mo ago
> Free lists aren't expensive for most usage patterns. Whatever little CPU they waste is often worth more than the RAM they save. > For cases where they are we've got stuff like arena allocators. ... that work by using more
350.
▲
by
pron
6mo ago
That's fine, but I was responding to a comment that said that RAM prices would put pressure to optimise footprint. Optimising footprint could often lead to wasting more CPU, even if your starting point was optimising for neither.
351.
▲
by
pron
6mo ago
Some of the algorithms are built deep into the runtime. E.g. languages that rely on malloc/free allocators (which require maintaining free lists) are making a pretty significnant tradoff of wasting CPU to save on RAM as opposed to lang
352.
▲
by
pron
6mo ago
Reducing your RAM consumption is not the best approach to reducing your RAM throughput is my point. It could be effective in some specific situations, but I would definitely not say that those situations are more common than the other ones.
353.
▲
by
pron
6mo ago
RAM throughput and RAM footprint are only weakly related. The throughput is governed by the cache locality of access patterns. A program with a 50MB footprint could put more pressure on the RAM bus than one with a 5GB footprint.
354.
▲
by
pron
6mo ago
Using a lot less RAM often implies using more CPU, so even with inflated RAM prices, it's not a good tradeoff (at least not in general).
355.
▲
How the JVM Optimizes Generic Code – A Deep Dive [video]
(youtube.com)
4 points
by
pron
6mo ago
|
0 comments
356.
▲
by
pron
6mo ago
Since Anthropic weren't able to make them work even for something as simple and familiar as a C compiler then I would guess that: 1. You're supervising the agents closely, or 2. Your projects are very simple - simpler even than a
357.
▲
by
pron
6mo ago
It's magical until you start going through the code carefully, line by line, and find yourself typing at the agent: YOU DID WHAT NOW? Then, when you read a few more lines and realise that neither AI nor human will be able to debug the
358.
▲
by
pron
6mo ago
Does Yegge really think that building production software this way is a good idea? Let's assume that managing context well is a problem and that this kind of orchestration solves it. But I see another problem with agents: When designin
359.
▲
by
pron
7mo ago
Sure, if you vigilantly review the agent's output and say no when it's wrong (which happens very frequently) then things work. I meant that without such ver close supervision things don't converge because agents make mistakes
360.
▲
by
pron
7mo ago
... and it still doesn't work. In the Anthropic experiement, the model was trained on a reference implementation and the agents still failed.
More ›