No? The conventional engineering wisdom has always been: pick two out of fast, cheap, or good.
And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.
> You can't load an integer from an unaligned address.
You can, and the results are machine specific, clearly defined and well-documented. Ancient ARM raises an exception, modern ARM and x86 can do it with a performance penalty. It's only the C or C++ layer that is allowed to translate the code into arbitrary garbage, not the CPU.
If some architecture traps on unaligned access, then the compiler can and should simply generate the correct code so that it loads the integer piece by piece instead. Load multiple integers and shift and mask away the irrelevant bits, done. This is exactly what modern architectures already do in hardware. Works, it's just a little slower.
This is exactly what the compilers do if you use a packed structure to access unaligned data. Works everywhere, as expected. Compilers have always known what to do, they just weren't doing it. C standard says no.
The fact is the standard is garbage and the first thing every C programmer should learn is that they can and should ignore it. There is never any reason to wonder what the standard is supposed to do. The only thing that matters is what compilers actually do.
Compilers could add support for an unaligned attribute that we can apply to pointers. I'd prefer that to wrapping everything in a packed structure which is quite unsightly.
Would have been better if correct behavior was the default while pointer alignment requirements were opt in, just like vector stuff. Nothing we can do about it now.
I would hope the compiler is smart enough to figure out which accesses are aligned and unaligned on its own.
> If some architecture traps on unaligned access, then the compiler can and should simply generate the correct code so that it loads the integer piece by piece instead.
Wouldn't the compiler have to assume that every pointer access might be unaligned and do the slow "piece by piece" access every time? It can hardly guess the runtime value of a pointer during compilation.
It should be able to make a lot of inferences. For example, taking the address of some value allocated by the compiler itself results in an aligned pointer unless the programmer overrides it. Compiler should be able to trace it from there. Pointers from malloc are also aligned.
If compiler is not doing it for some reason, __builtin_assume_aligned can be used to explicitly mark a pointer as aligned.
The pointer might be something you forced. The compiler needs to do the right thing but if you set the pointer to an unaligned address because you have information on the hardware you can get this undefined situation with nothing the compiler can do about it.
No reason at all, then. Because I am manually dealing with alignment in my code.
Wrote a lisp, its bytes type supports reading and writing integers at arbitrary locations within the buffer. Test suite exercises aligned and unaligned memory access for every C integer type. Also wrote my own mem* functions, dealing with alignment in those was certainly a fun exercise. It wasn't necessary, I just wanted the performance benefits.
however you certainly can do that. The point of unaligned is the hardware can't load it from a single memory location in one address. It needs two accesses. And in that time, the value of one of the two addresses that the hardware has to load can change.
I would hope you're not so stupid as to design hardware that relies on this, but the fact is it certainly is possible for someone to do that. And if you do that, there is nothing that the compiler or the standard can do. It can't be done correctly
Yeah, the unaligned accesses aren't going to be atomic unless the hardware supports it.
> And in that time, the value of one of the two addresses that the hardware has to load can change.
You mean volatile addresses that could spontaneously change in the middle of the reads? Like memory mapped I/O addresses?
I would expect these to have stricter access requirements than arbitrary general purpose memory locations.
> I would hope you're not so stupid as to design hardware that relies on this
You and me both.
> And if you do that, there is nothing that the compiler or the standard can do. It can't be done correctly
Anything that does that is broken and terrible anyway. It really shouldn't contaminate language design. It's the sort of thing that compilers should be adding attributes for, rather than constraining the language to the point nothing works correctly and making us use attributes on everything to restore some sane baseline behavior.
> Anything that does that is broken and terrible anyway
which is why it is undefined behaviour. the optimizer writers have told me consistently that if they can assume you're not doing this thing that's stupid anyway, they can make my code faster. And since I'm not doing that stupid thing anyway, I want my code to be faster.
Unaligned memory access isn't really stupid though. Not in the general case. Not to the point where it should give the compiler free reign to crash things or introduce security holes. It should just introduce a performance regression instead, which is a tractable problem. Just measure it and fix it by making things aligned.
Compilers can add some custom attributes that encode whatever semantics the badly designed hardware requires. This lets it freely break incorrect code in the small sections that are actually handling those special variables, while allowing the rest of the language to make sense.
> If some architecture traps on unaligned access, then the compiler can and should simply generate the correct code so that it loads the integer piece by piece instead.
LMAO what?!
The compiler should pessimize each and every memory access everywhere with an alignment check on the pointer and a branch, or forego the efficient memory access method of the platform entirely and just do bytewise loads only?!
Unaligned access. Not every access. Compiler should be able to analyze code, determine alignment invariants and optimize everything it can. If not, __builtin_assume_aligned could help whenever it needs to be made explicit. Alignment should have been part of the type itself to begin with but there's no fixing that now.
So yes, pessimize each and every access. No, that's not acceptable. And no, just because the compiler can get rid of some of the alignment checks where static analysis can prove that the pointer is aligned doesn't cut it.
Yes, making alignment part of the type system would be the correct fix. And yes, that's absolutely still possible since unaligned access is still UB. You're not breaking existing code. You could easily add new pointer types with (static) alignment information.
That's why we write C instead of assembly, isn't it?
You could also mandate that a compiler for architectures without unaligned access either has to prove that the access is going to be aligned or insert a wrapper to turn the unaligned access into two aligned ones.
Just pretending the issue doesn't exist at all and making it the programmer's problem by leaving it as UB in the spec is a choice.
Not really. Wait until the compiler starts vectorizing your code and using instructions requiring alignment (like the ones with A or NT in the mnemonic).
Why? Automatic vectorization is pretty bad and has been for years, but wouldn't it be nice if the compiler could unroll-loops and use SIMD instructions to make your code faster while also being correct?
You missed the point: the pointer existing as a value of that type at all is UB, even if you never try to access anything through it and no corresponding machine code is ever emitted.
Yes? I agree with that. I don't really see the issue there. The computer will allocate data in aligned addresses, so you would have to be doing something weird to begin with to access unaligned pointers. And aligned access is always better anyway. I guess packed structs are a thing if you're really byte golfing. Maybe compressed network data would also make sense.
But then I would assume you are aware of unaligned pointers, and have a sane way to parse that data, rather than read individual parts of it from a raw pointer.
I am curious, what would be a legitimate reason for an unaligned pointer to int?
That's true, and that's why your typical string vector code has a prelude and a postlude to do the incomplete chunks at the ends. Between the ends, it's processing larger self-aligned chunks.
You didn’t really say that, but feel free to share any reasons you might have to think so.
I don’t see any reason why it wouldn’t be perfectly fine on recent hardware, where unaligned loads are just as fast, and the cache pressure is identical for a linear search algorithm.
I asked where is the part about unaligned pointers in your string processing example. Saying that you want to load multiple bytes at a time does not imply at all that you have to do unaligned loads.
Doing unaligned loads using SSE or AVX might have been possible on Intel architectures for a long time, but it is still a little bit slower afaik. But anyway when you get into sub-architecture specific details like that, you've essentially left C-land, and you're essentially doing assembler level programming.
Every vectorized string search algorithm (including those treating an unsigned long as a "vector" of 8 bytes) currently needs a prelude that performs the search up to the first alignment boundary, and then performs the bulk of the search on well-aligned blocks, and then finally a postlude search in the tail of the string, where the tail is shorter than the block size/alignment.
Using unaligned loads, you can get rid of the prelude, including the associated branches and intptr arithmetic, and just have to deal with the tail.
If you're comparing short-ish strings, almost all of the time is spent in the prelude and postlude, even if the entire substring fits in a register. This is a silly language limitation when the hardware can actually easily just support the unaligned load.
In particular, it doesn't seem justified that what at most amounts to a tiny inefficiency in hardware turns into a very expensive class of bugs (UB).
Have you ever wanted to do this? I find the premise ridiculous.
But anyway, you're complaining that you have to work too hard to do unaligned loads (i.e. the wrong thing even if it should work on a particular machine) in C, when basically every other language makes you work more for basic systems programming tasks?
Whether unaligned loads can work on the machine level, it depends on the hardware. On some other architectures, you probably get anything from traps to unpredictable behaviour. It's totally fine that C does not define the behaviour for unaligned loads.
If you want to do some weird stuff like loading a single unaligned 16 byte quantity, where there was no "middle part" to begin with, just do memcpy then. The compiler might just do the appropriate thing on this architecture. Or if you need to closely control what's happened, write assembly then. But again, why would you even do this?
No it isn't. The implication is that pro-AI people can take revenge. He knows he is secure with his opinions. He even paraphrases Andreesen's title "software will eat the world". He has repeatedly appeared at a16z.
It is very secure to be pro-AI while the rest has to resort to unregistered typewriters like in the Soviet Union.
You are absolutely not a "random person on the internet", you are a very public figure with the wealth and influence available to you that could allow you to take revenge on someone who says something you don't like in real, life-altering ways. Now, I'm not saying that you would do that, but it is a shocking lack of self-awareness to think of yourself as a random person on the internet.
This is hilarious. What am I going to do? Hire a hitman? if you’re going be a dick on the Internet, you should be a dick using your real name. I don’t think that’s a threat.
One of the graphs has two series: net revenue for one company, gross revenue for another. Absolutely ridiculous.
And that's just one example. You also haven't adjusted for inflation in your graphs that span multiple decades. Not to mention that the graphs themselves are not related to what you're discussing most of the time. You're just pointing at random historical developments and seemingly claiming they imply something for AI. They don't.
Also you don't name your sources. You just say "Companies" for most of them. Or a single name. Ridiculous. Those are not sources. You should identify the documents.
This is incredibly low quality work. A college freshman would do better.
I charted the revenue reported by Anthropic and OpenAI as gross and net because those are the numbers they disclose. Anthropic does not report net revenue nor give us any way to calculate that, and the same in reverse for OpenAI. It would be great if we had GAAP revenue, but we don't. This is what we have, and it still tells an important story. What are we supposed to do - just not show the data?
All of the charts indicate whether they are adjusted for inflation. There is no rigid convention on this, but the general practice is that you don't adjust up to maybe 20 years and generally do convert for more than that, unless inflation itself is under discussion, which it is not here. Meanwhile, the text on each slide explains the purpose of the comparison. None of them are random.
Every chart is correctly sourced exactly as you will see it in any other piece of financial or industry research. It is not industry practice to cite specific documents or provide footnotes.
You've clearly just never seen any industry or financial analysis before, and are unfamiliar with basic and universal conventions that run back decades. That's fine. Being rude about it is not.
It is not industry practice to actually give the sources then? Just list vague names in a short "Sources:Companies" note? I now see the inflation indication as well. Which is not on the y-axis label, but in the "Sources:"-note. I will concede that. But what the hell my guy, why is it down there.
If "financial analysis" is less rigid in sourcing requirements than grade school, what are you guys even doing. If you have the source, it's not very difficult to make a bibliography (or even write the year/publication with the author/publisher), and not doing so only serves to hinder the reader. If this is industry standard it means your entire industry is terrible at sourcing, does not want the reader to verify claims, or both.
And I've also definitely seen financial slide decks with actual sources cited. So I'm inclined to hope there are people in your industry who actually respect the reader's time.
Here's some more picks (and some more reasons you should list your sources): Your graphs based on surveys don't report error margins. You never list what a 100% is very precisely (what's the sample/population). In one graph, you don't label the y-axis at all (except for a 0 at the bottom)!
And finally, I was rude, yes. But I was only matching your energy. And I did show constraint there. I didn't make a veiled threat, did I?
You are surprised to discover how an entire industry you know nothing about does things. You conclude that everyone in that industry must be an idiot doing bad work.
This says far more about you than it does about me.
Yes, it says I have bare-minimum standards for how to cite references.
I never said I thought financial analysts are idiots. That's not a conclusion I made.
I gave a very reasonable reason: they want it to be more difficult to replicate the analysis. That makes sense if your goal is to make sure your work is profitable, rather than quality reporting and knowledge dissemination.
That would imply the people who set the standards (not everyone) is cynical and/or greedy. Not an idiot.
And still, presumably you are still allowed to add actual sources to financial analysis? You still failed the regular standard of good reporting on this. Your graphs also fail just regular data analysis sanity checks. There is, e.g., no thought given to whether it's even valid to compare data from two sources in one graph. You just do it.
What IQ "means" is separable from what it is. IQ is a measure of performance on IQ tests. That's literally what it is. If a computer system can complete IQ tests, it has an IQ.
The issue is that IQ means less than you want it to.
I don't want IQ to mean anything. pkoird clearly wants it to mean something.
IQ is a terribly flawed measure of human intelligence. But it measures nothing when you apply an LLM that contains multiple IQ tests in its corpus. IQ is deeply flawed, but the point is not to "measure performance on IQ tests". If someone cheats on an IQ test and scores 200, no reasonable person would say they have 200 IQ.
The genesis mission is an attack on science and research.
The executive has slashed NSF grants and are now requiring almost every natural science research team to apply through this hastily prepared channel instead.
Review is done by "domain experts and AI experts", not traditional scientific boards or sytemic review. Everything has to be done with AI products in mind. Every project must include "industry partners" (big tech forma), and research teams have to share their research data with said industry partners. Oh, and half the money they get, of course.
And technological improvements don't remove these tradeoffs. You still have to balance tradeoffs. The best thing you could do is have a mix of technologies that choose different tradeoffs. A single technology (zig) won't do.
reply