How much better was DEC Alpha than contemporary x86?
retrocomputing.stackexchange.com
retrocomputing.stackexchange.com
DEC had a winner with Alpha. It had speed, and most importantly, you could run Windows NT on it. NT mattered because most Unix vendors at the time wanted $1,000/CPU for their licenses, and NT was $cheap (the OEM version was around $300 if I recall correctly).
As other posters have said, DEC just could not get out of their own way and let Alpha succeed. Wierd sales policies, hostile partnerships, and intense competition all really stymied DEC. A lot of the weirdness came from trying to protect their legacy base of VAX and PDP midrange systems and a general hatred of IBM (who was pushing OS/2).
BTW as I recall, Windows NT supported x86, Alpha and MIPS (another RISC vendor) with the first commercially available version of NT. MS added a few other RISC architectures in the following years (ARM most notably). x86 closed the speed gap a few years later with the Pentium II (the Pentium Pro was largely used in servers) and the rest is history.
Can't say I understand very well what was going on in his mind, but somehow I got the impression that some of that was not totally specific to alpha in particular, but that alpha represented non-x86 at large, and he was excited and enthusiastic to tackle the technical problem of making the kernel portable. And certainly it paid dividends; eg. linux on ARM is running on billions of devices today, and that surely would have been more work had they not decided to make the kernel portable in the first few years of its history.
Windows NT never came to ARM. The work was rolled into Windows 8 with RT.
I much preferred my SGI boxen at the time. And when Linux hit Alpha, NT was little more than a plaything.
Oddly enough, its how I feel about the "NT on non-x86" rigs I occasionally run into, also being pitched as a port target for some of my modern projects.
The Pentium Pro, released in late 1995, was a 3-way design clocking up to 200 MHz. It was surprisingly competitive. It had all the modern requirements: out of order execution, out of order memory pipeline, on board L1 and L2 caches. It just had less resources in each dimension. Intel caught up to 500 MHz in 1999, with the PIII. That was still a 3-day design. Intel’s first four way design was the Core 2 in 2006. That could hold 96 instructions in flight. Intel didn’t release a CPU with two load store units until 2011 (Sandy Bridge could do two loads per cycle) or possibly 2019 (Sunny Cove was the first that could do two stores per cycle).
Obviously, Intel caught up based on a combination of features long before then. I’d guess around early 2000s, when clock speed hit 1 GHz+. Clock for clock, the Pentium Pro wasn’t actually that much slower than Alpha on integer code. It took much longer for intel to be competitive on floating point code.
(By the way, it blows my mind that we went from 200 MHz to 1 GHz in about 4 years. Meanwhile, it’s been 15 years since my first 2 GHz+ MacBook, and a new MacBook still has a base clock around that range. Maybe it’ll turbo boost to 4 GHz for 10 seconds before it exceeds its thermal envelope.)
A 33 MHz 486 to 200 MHz was about 5 years. A 8 MHz 286 was released 7 years before that, right at the start of the uptick. Before that a MOS IC was generally capped at about 5 MHz while people slowly figured out how to shrink them and developed EDA tools that allowed designed to scale quickly across processes.
Dennard scaling was a wild ride while it lasted, but it's been done for more than a decade now.
But I think it was not great on 16-bit code or something. The boost was not as impressive for DOS and Windows (still had lots of 16-bit code at the time).
I bought my Pentium Pro + motherboard and RAM at a computer show for ~$1000. This was a fairly good purchase. Around the same time I also bought an HP CD burner for around $1000- big mistake since it was slow and the prices soon plummeted.
We had a similar jump going from the 486 to the Pentium. I distinctly recall a Linux kernel compile being a 45-60 minute adventure on a 486DX2-66, but only 5 minutes on a Pentium 100. (I felt like a lot of elements of PC architecture improved together around that time as well.)
Pentium was not that much faster than 486 - 486DX4-133 was faster than Pentium 90. I guess it had more memory
This also describes VLIW architectures more generally, and even more so wrt. current speculative developments like Mill, which AIUI doesn't even have a single, standardized "machine-level" assembly; what the machine runs at its lowest level is only defined by your actual chip configuration. (It is understood that GPU compute works much the same way, with the GPU driver acting as a "compiler" of sorts.)
Actually that's on Apple, the manufacturer, for choosing to undercool these chips (probably thinking that most people won't care, which I tend to agree with, but it's problematic when the machine is sold as a "Pro" device).
Anecdotal comparison, my Thinkpad sustains its 4 GHz for hours on end no problem. There's no comparing the performance of these i7 / R7 with decade-old dual cores at 2 gigs, it's just unfair.
I’m so tired of this trope. Do you think there’s a single definition of Pro and it’s yours?
Having said that, my 15" MBP is sufficient for my needs, but I'd not recommend it for anyone doing heavy numeric lifting. Or compiling large volumes of code.
I expect to be able to compile moderately sized software, transcode an hour long video, render a scene in a ray tracer, etc without throttling.
I can do these things on my Dell XPS developer edition. If I'm going to spend more than $1000 on a machine, these capabilities are a minimum standard.
My $200 netbook hits thermal throttling and that's ok. It's not "pro" and it isn't meant to be.
The short version is that MacBook is not designed for speed/performance but looks. It overheats by default.
2700k could reach/overclock to 4.5Ghz w/o much trouble, given proper cooling - 2011. The reason for lower base clock is the Intel TDP definition.
Assume: p=&a, a=1, b=0
Thr. 1 | Thr. 2
b = 1 |
memory_barrier | i = *p
p = &b |
Even though p=&b happens after b=1 in Thread 1, it is seen as happening before it by Thread 2. This is basically because the b=1 part might get ignored by Thread 2 unless that thread also goes through a memory barrier of its own. When the i = \*p is executed, Thr. 2 might read p from main memory as written by Thr. 1, but then still rely on the old b=0 value sitting in its cache. It's hard to describe that as being "superior", but maybe it enabled some performance optimizations in the common case that made it worthwhile.
Where Alpha was weird was in its floating point implementation (two versions on chip! to support the crazy VAX formats that no one cared about even at the time) and its alignment requirements (the hardware, not really atypically, couldn't make a misaligned load, but actually "could" by trapping into a microcode handler that was 10x slower, leading to mysterious insane performance regressions).
This is a lesson that software folks have been pushing with tools like static typing and memory lifetime analysis. The same applies at the hardware level.
Probably yes, i.e., there was some hardware reason for it. You can find one explanation [1] floating about that explains the effect was due to the cache banking design, with separate invalidation queues for each bank. Presumably that was better in some respect than the alternative designs available to implementors.
That said, the difference is probably fairly small and if Alpha were around today they would almost certain want to abandon that particular reordering since they are the only one doing it and there would be a lot of pressure on them to make it fast (this comes up in all sorts of non-trivial scenarios like double checked locking, reads of final fields in Java, etc).
That's generally the pattern, I think: if you are the odd man out with the weakest model, and you aren't the dominant player, you will have a lot of pressure to at least offer fast ways of lining up with the stronger models. So even if a weak model is a better design point in a vacuum, it might not be true when real-world implementation pressures are considered.
---
[1] https://preshing.com/20120930/weak-vs-strong-memory-models/
[2] https://www.kernel.org/doc/Documentation/memory-barriers.txt
Suppose thread 1 executes the following code:
x = 1;
store_fence();
p = &x;
But you would be wrong on Alpha. Alpha has two cache banks, and there is no coordination between them (in the absence of memory barriers). So if p and x reside in different cache banks, it's possible for a thread to load the value of p (observing that it is &x), and then load the value of *p and fail to see the assignment of x = 1--if the cache bank that contains x is somewhat overloaded on processing the bus traffic, for example.
Incidentally, you can't actually take advantage of the opportunity to avoid the memory barrier in this scenario on everyone-but-Alpha in the C++11 memory model, because it turns out that figuring out how to specify the (hardware) data dependency matters for ordering purposes in a source language is a lot trickier than it might appear. memory_order_consume (added for this purpose) is lowered to memory_order_acquire in all compilers I'm aware of.
Note: without a memory barrier on BOTH sides, your code is factually wrong anyway and is open to memory-ordering issues.
With the modern "acquire-release" memory model, you need a release-barrier in Thread#1, and an acquire-barrier in Thread#2, for code to be fully correct. Acquire and Release barriers, also known as "half barriers", weren't invented in the time of DEC Alpha. But DEC Alpha's full barrier ("mb") would make the code correct.
Even on ARM and POWER, very weak models, an address dependency orders the reads. This is the 'MP+dmb/sync+addr′' litmus test in 4.1 in [1].
This type of dependency, which doesn't need a barrier to work, is why C++ invented the whole convoluted "consume" ordering in the memory model, pretty much doubling the size and complexity of the model.
---
[1] https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
Think about the C++ code and how the compiler could implement your code.
Thread 1:
b = 1;
memory_barrier();
p = &b;
*p = (whatever);
...
i = *p;
The memory barrier in thread2 is still needed so that the COMPILER knows that its register state is potentially stale. Even today, with half-barriers and a stronger memory model, the compiler can't read the mind of the programmer.
So I don't think I can usefully continue this branch of the conversation, sorry. That said, if you want some good reading on the topic I recommend Cambridge memory model group reference I linked above. In fact, all of the Cambridge stuff is good: they got the x86 memory model right (correctly described), even before Intel did!
FWIW, the OP was spot on: this is a canonical example of a reordering the Alpha does (did) that no one else does. It comes up over and over when you talk about memory models. It's almost a meme: "that's the one that Alpha did..."
I guess if you're working at the system / assembly level and only using C-like pseudocode for simplicity sake, there's a different set of expectations. But I know that I've been "burned" by the compiler before moving some stuff around.
Programmers have to work with not only the CPU, but also with their compiler's memory model. Its a fact that is often forgotten. Even if the CPU implements a particular memory model, the compiler has a (slightly) different one, and memory barriers or fences (or Java volatile) may still be required for proper memory ordering.
----------
I see your point that this "weakness" in DEC Alpha's memory model is probably hard for system programmers and compiler writers to figure out. But it should be noted that in C++11, the Thread2 code is still wrong without the presence of a memory barrier of some kind. (and once we add the memory barrier, mb, into Thread2, it fixes the problem at both the C++11 level AND at the DEC Alpha level)
For the code in thread 2 to need a barrier in C++, you’d need your modified version of it where *p is assigned earlier. And even then you only need a compiler fence (`asm volatile (“” ::: “memory”)`).
That’s a two part refutation but the first part is most important: the example only needs a barrier in C++ if you change the example as you did. If you don’t change it then from the C++ standpoint there is no earlier value that could have been cached. That arises naturally in C++ code since there’s bound to be a function boundary or lock-related fence nearby.
And if there isn’t one nearby then C++ programmers love compiler fences for that. You don’t need a CPU fence for this except on Alpha.
People sometimes think that the market caused the Alpha to fail. Really, it was Intel. They wanted Itanic to succeed so much that they made a deal with HP to end the Alpha prematurely, even though demand for Alpha systems was high.
Even after HP announced that the Alpha would stop being developed, Alphas were being sold as a high end systems for all sorts of uses and had many entries in the Top 500List of supercomputers - Alpha systems were four of the top ten on the planet in November, 2002, which was after HP announced they wanted to transition from Alpha to Itanic.
My AlphaServer DS25 is beautiful hardware. Everything in the machine is manufactured to a standard we just don't see any more.
Corporate infighting, incompetent sales, and misaligned vision pervaded the culture. It didn't help that PPro came out of left field and took everybody by surprise
When I interviewed at Intel in '95, they were absolutely giddy with how they stole Alpha's thunder. DEC was a better geographic choice for me, and, well...
HP didn't come into the picture until long after - DEC sold to Compaq in '98, Compaq to HP in '02. The race was over at least 7 years before that.
Edit: Not to mention the absolutely hostile stance DEC took to MS wrt NT. Due to Cutler's involvement with NT, DEC sued MSFT and somehow thought that would make MSFT become a loyal partner.
I remember Office 97 performing terribly on Alpha. We sent a compiler guy there to figure out why; turns out the Office team had a single Alpha in their pipeline, set to compile -O0, and pretty much said "this is there to check the lawsuit checkmark"
what does this mean? compile -O0? lawsuit checkmark?
Like Itanium, compiling for Alpha with -O3 would expose you to large amounts of bugs in your code and bugs in the compiler too.
They still performed well when they ended support and laid off everyone on the Alpha teams, including my dad.
This is misleading at best - "The Itanium architecture originated at Hewlett-Packard (HP), and was later jointly developed by HP and Intel." (https://en.wikipedia.org/wiki/Itanium)
A more realistic view would see it as a casualty of the DEC->Compaq->HP merger sequence, with HP long committed to Itanium as the successor to its own PA-Risc architecture.
https://devblogs.microsoft.com/oldnewthing/?p=94615
One of my now-retired colleagues worked on real-time compression, and he told me that the Alpha AXP processor was very weak on bit-twiddling instructions. For the algorithm that was ultimately chosen, the smallest unit of encoding in the compressed stream was the nibble; anything smaller would slow things down by too much. This severely hampers your ability to get good compression ratios.
More Alpha details from Raymond Chen:
https://devblogs.microsoft.com/oldnewthing/20170807-00/?p=96...
They never did show up on the resale market much; it took me years to find out why: Credit Unions. A big Credit Union software package was written for Alpha (and apparently not ported) and there's still some folks stuck on this hardware. Something to do with the CPU having a "how to treat roundoff" switch i gather, and the fact that they're great at chopping strings by bytes which old finance protocols do quite a lot of.
Except for memory barriers. The DEC Alpha command "mb".
x86 has a (relatively) strong memory model, but ARM and POWER9 both have weak memory models. Not quite as weak as DEC Alpha, but weak enough that you need to be very careful about memory-barrier placement in both ARM and POWER9.
XBox360, PS3, and ARM (cell phone) system programmers would know about the difficulties involved. Yeah, its hard to learn, but totally possible to write a mutex.
--------------
There's probably more code running on "weak memory models" today (ie ARM) than on "strong memory models" (aka: x86) today.
> without the ability to load or store anything but natively aligned and sized quads
Check out the assembly code generated with -O3 with GCC or LLVM. x86 has natively aligned quads for performance reasons, and compilers have also solved this problem. In fact, you'll see plenty of "nop" generated in compiler code, so that all of your assembly is aligned to the cache-line to maximize uop cache issues on modern x86 machines.
x86 doesn't have any REQUIREMENT for aligned assembly code or data. But x86 is far more efficient when reading/writing from cache-aligned locations. (In particular: reading across an 64-byte boundary naturally results in 2x L1 cache reads instead of 1x L1 cache read).
Both the alignment, and memory-barrier, issue are solved today. Arguably, they weren't solved back in the DEC Alpha days (I was too young to be programming at that time)... but modern compilers and toolchains can certainly work with memory barriers and "aligned only" memory.
In addition to being slow for e.g. text processing, you couldn't implement a modern memory model like Java's or C++ on it, without serious compromises, due to the inability to make non-interfering writes of adjacent elements.
But consider that the modern model accounts for 64-byte (aka: 512-bit) cachelines. Any reads or writes to a 64-byte cacheline is going to be false-shared between cores. From a performance point of view, you cannot make non-interfering writes of adjacent elements in the modern memory model!
If you're dealing with single-threaded code, then bit-mask instructions for registers should be sufficient to emulate the ability. I can see that bit-masking every character instruction would be slower, but it would certainly get the job done.
First you have to be able to implement the model correctly. That means non-interfering writes. 99.99% of those writes will never involve any sharing (false or otherwise) and will perform just fine.
Not being able to do byte-granular writes means you simply can't implement things like this at all unless you:
1) Decide that "char" will be 32 bits (i.e., make a byte on your system 4x larger than usual).
2) Do some locking around each narrow write (or perhaps a series of them) and ensure everyone does the same.
So I am not really following your argument with regard to false sharing.
I don't know what you mean by "the modern model accounts for 64-byte (aka: 512-bit) cachelines". I don't know of any (software) memory model that even mentions cache lines. Hardware memory models don't lean heavily on them either, although they do get mentioned (e.g., on x86, Intel provides additional guarantees for some misaligned reads that do not cross a cache line, and AMD provides different guarantees).
Or 3) Decide that for performance reasons, reads/writes to an array (even a char* array or string) would be locked in 64-byte chunks at a minimum.
My point with false-sharing is that "true" byte-granularity comes with severe performance penalties on modern x86 systems. Its a thing that you want to avoid.
If one thread is reading / writing to char myString[0], while a 2nd thread is reading/writing to myString[63], your memory will ping-pong between the two threads (because x86 shares 64-bytes at a time between caches).
--------
I guess your point is that the CPU will "do the right thing, even if they're forced to do it slowly" in this case. So I guess you're right about that. Your code CAN be written as multithreaded + byte granular, its just going to be slow in practice.
I guess my point is that the high-performance programmer needs to understand this situation anyway, and that high-performance programmers have developed methodologies to avoid false-sharing. Any high-performance data-structure needs to understand false-sharing. You really shouldn't be doing things like reading/writing to myString[0] and myString[63] in two separate threads.
First note that this doesn't have anything to do with arrays specifically: any type of adjacent elements (in a struct, loose on the stack, whatever) have this problem.
That said, I have no idea how you would implement this suggestion.
E.g., how would you compile the following very simple function?
void write1(char *c) {
*c = 1;
}
It obviously does not! x86 has true byte granularity and loads and stores are very fast, just as fast as any other size. Just because the possibility of false sharing exists, doesn't mean it somehow slows down byte writes. False sharing doesn't even have anything to do with byte writes: it affects any size of access. So I am really not following your argument.
To summarize my claim:
- Modern memory models generally require that writing some "object" (which could be a primitive value like a char, int, whatever) not interfere with adjacent objects.
- This applies to all writes, unless perhaps the compiler can prove the data never escaped and cannot be shared, so in practice it means that you can only efficiently write at the smallest granularity supported by hardware.
- This means that you pretty much need 32-bit char on platforms where the smallest hardware write is 32 bits, or just give up on supporting the memory model.
None of that has anything to do with false sharing really. Not even really performance: we are just trying to get it to be correct. Saying "well you don't want to concurrently read nearby elements anyways" doesn't mean much because it doesn't lead to a practical way to implement the language (unless I am missing something).
> I guess your point is that the CPU will "do the right thing, even if they're forced to do it slowly" in this case. So I guess you're right about that. Your code CAN be written as multithreaded + byte granular, its just going to be slow in practice.
Not at all. My point has nothing to do with false sharing. You brought up false sharing.
My point is that the memory model is defined not prohibit behavior X, and platforms that need to do a large-word RMW to modify smaller elements can't effectively prohibit X.
This is true if you have false sharing or no false sharing or a small amount of false sharing. This is true even if you don't start any threads. This is true also for scenarios of "true sharing", e.g., where the other thread wants to share data (i.e., after reading the adjacent element maybe it is going to read the other one too).
> I guess my point is that the high-performance programmer needs to understand this situation anyway
It has nothing to do with the (application) programmer or performance. It is more fundamental than that: how does the compiler writer write a compiler that produces correct code under the memory model?
Structs are usually 64-bit aligned in x86 though. You need #pragma pack to be no longer 64-bit aligned on modern compilers.
> E.g., how would you compile the following very simple function?
I don't know DEC Alpha assembly, but by my understanding:
mov R1, [c] ; 32-bit move into R1
and R1, 0xFFFFFF00
or R1, 0x00000001 ; Move 1 into the first byte of R1
mov [c], R1
If "c" was {4, 4, 4, 4}, after the store, it would be {1, 4, 4, 4}. If you are asking me where to place the memory barriers... note that C++ is Relaxed memory model and has undefined behavior unless you put the appropriate atomics<> in the correct location (which would generate a "mb" instruction for DEC Alpha).
I'm pretty sure DEC Alpha can implement C++11's memory model, albeit inefficiently with full-barriers... but it probably would work.
Totally false (just try it).
> I'm pretty sure DEC Alpha can implement C++11's memory model, albeit inefficiently with full-barriers... but it probably would work.
No, they can't (without widening char to 32 bits). The code you have shown modifies the adjacent elements. Anyone that write a nearby byte in the window between the load and the store will have their write silently clobbered.
You can't fix it with barriers. You need a lock or LL/SC loop.
The "int a" is definitely 32-bit aligned.
So you agree now that structures are not "usually 64-bit aligned on x86"?
ints will always be (at least) 32-bit aligned.
The rules are simple [1]:
1-byte primitives (e.g., chars) are 1-byte aligned
2-byte primitives (e.g., shorts) are 2-byte aligned
4-byte primitives (e.g., ints) are 4-byte aligned
8-byte primitives are 8-byte aligned
The rules for structures are also simple: they will have the alignment of their highest alignment member. That makes sense: the language rules (and ABI) are designed to make sure that primitives have (at least) the above alignment, regardless of where they are: putting them into a structure (or array, etc) can't violate that.
This is basically common across any modern platform too - not x86 specific, although some details may vary (e.g., size of primitives). There are weird cases too, like on some 32-bit platforms even (some) 64-bit values are only 32-bit aligned, and the whole 80-bit long double thing, etc: but the basic rules hold.
---
[1] Here I give some examples of data types that _commonly_ have the given size, but except for char this is not always true (e.g., some platforms have 8 byte ints, and some have 4 byte longs).
Agreed on this point.
> No, they can't (without widening char to 32 bits). The code you have shown modifies the adjacent elements. Anyone that write a nearby byte in the window between the load and the store will have their write silently clobbered.
I guess my misunderstanding was that C++11 gave this guarantee. That's pretty cool.
I guess I typically expected specific bitwise operators (ex: atomic_and or atomic_or) to be necessary in these cases. But if DEC Alpha is really the only processor in (somewhat) recent memory that doesn't allow 8-bit granularity, then it makes sense to just standardize upon 8-bit granular reads/writes.
Maybe you could try to formalize the idea of "keep private data away from data on other threads" or something, but this seems very difficult (in practice, private data is private as an emergent property of the whole application, so is not easily identifiable), and you'd have to give up on a lot of things the existing model offers in terms of write-independence.
1) doing the equivalent of CAS (or LL/SC in this case) for every single access less than 32 bits completely destroying performance.
2) declaring that a char (and a byte) is 32 bit sized, which implies no posix.
It was very bad. This was fixed in subsequent alphas though.
I knew POSIX required a lot of other things that are unspecified in C/C++ but usually have a single sane implementation, but not that particular one. I know I have static_assert(CHAR_BIT == 8, ...) sprinkled around in quite a few places.
One day I'm going to write a header that just checks a big list of things that are "obviously sane" but not actually specified in C/C++, and error out if any are not true. Then I can include this in every project and just code in this new sane world. Not strictly portable, but "portable to where it matters".
With the C++ memory model you can make std::atomic<char> larger than char. A lot of code assumes that this is not the case and that it is possible to cast between the two, but it's (surprise) undefined behavior.
If those writes are implemented by reading 4 bytes, and/oring in the byte to write and then writing 4 bytes back, they will interfere.
It’s not about just whether it’s possible to write a mutex but also whether you can write a really good one. The best concurrent algorithms - whether mutexes or lock-free data structures - benefit from a careful mix of strength and weakness in the memory model. I think Alpha is too weak. X86 may be too strong - so say smart people - but it still manages to be fast as fuck.
No idea what you’re talking about wrt alignment. On x86, you can load/store misaligned. On Alpha, you can’t. On ARM, you can on some but not on others. The CPUs where you can are easier to program.
No idea what you’re talking about wrt memory barriers. It’s not a solved problem. Memory barriers slow things down so it’s better not to have to use them. X86 and ARM64 give you tricks to avoid using barriers, or to use cheap barriers, in many important racy algorithms. Alpha gives you fewer tricks. (Specifically x86 gives you lots of ordering “for free” while arm64 let’s you use the self-xor dependency trick to cheaply order loads and has a generous buffet of half fences.) The memory model matters a lot - the weaker it is, the fewer tricks programmers have to avoid doing expensive things to request specific orderings.
At a performance penalty. Read or write across a 64-byte cacheline, and your CPU will be forced to perform 2x loads to implement your singular unaligned load. An unaligned load across a cacheline is literally 1/2 the speed of an aligned load, and is something the modern programmer (and compiler) is designed to avoid.
The compiler basically avoids all misaligned loads/stores, even on x86. (Aside from when the programmer really forces it: like reinterpret_cast<int>(0x800003f) or something)
-------
> The best concurrent algorithms - whether mutexes or lock-free data structures - benefit from a careful mix of strength and weakness in the memory model.
And all of those algorithms would run CORRECTLY, if those half-barriers were replaced with full barriers. Maybe slower, but they'd be correct.
That "generous buffet of half fences" can only exist on a weak memory-model system (like ARM), because x86 AUTOMATICALLY performs those half-fences after every load / before every store instruction. That's the thing about strong memory models: once you're "too strong", it doesn't even make sense to have those half-barrier instructions.
ARM and PowerPC were too weak 10-years ago. They've "strengthened" their memory model by adding new half-barriers to their instruction set. That's the real secret: to change your CPU over time to match programmer's preferences. ARM / PowerPC started off too weak, but are now approaching "just right", with the addition of new instructions.
DEC Alpha can't do that, because the DEC company died decades ago. Its only fair to consider the programming environment and expectations of the time period that the DEC Alpha existed in.
I think you’re glossing over a lot of details about the memory model. What the model says about the ordering of dependent loads isn’t a matter of just adding fences later - it’s more fundamental than that. Of Alpha achieved it’s perf advantage thanks to speculating loads then it would have to lose that advantage when it was modernized to current standards. Also, the original comment was about Alpha back then versus Intel—and-others back then, so it’s not interesting to say that Alpha could have just improved - that’s not really responding to the original comment about how hard Alpha was to program.
Yeah, this.
You might as well think of them as free in most scenarios involving small reads and writes. If there is some small advantage to misalignment (often, reduced memory use through better packing), do it!
The cross-line penalty would occur only for 3 out of 64 alignments for a 4-byte load: less than 5% of the time, and then the penalty is small.
That % is more or less worst case in well designed code [1]. Sometimes you can do misaligned loads that you guarantee will never cross. A common example is a misaligned LUT where the values overlap. E.g., given n, you want to load 8 bytes with:
[n, n+1, n+2, ..., n+7]
For large accesses, things become less clear. After all, a 512-bit AVX-512 access is guaranteed to cross if it is misaligned, and 256-bit access randomly distributed cross half the time, etc. Vectorized code is also the type of code that may be written to approach the 2/1 load/store per cycle limit, so it really pays to try to get alignment for any type of non trivial loop.
---
[1] Specifically, this is the crossing % you would get if you could assume nothing about the distribution of the accesses, i.e., they are uniformly randomly distributed. If you know something about the expected alignment, then you can shift everything to make crossing less likely.
You make it sound like a compiler choice (that possibly only occurs when certain optimization levels are used). In fact, it is part of the language spec: everything has to be properly aligned based on the C and C++ rules. This leaks into the ABI too when it comes to structure packing, etc. So alignment is pervasive because those are the rules, and the rules were made for performance, e.g., to support platforms like Alpha which couldn't even _do_ an unaligned read but would have to construct the value from two aligned reads.
> x86 doesn't have any REQUIREMENT for aligned assembly code or data. But x86 is far more efficient when reading/writing from cache-aligned locations. (In particular: reading across an 64-byte boundary naturally results in 2x L1 cache reads instead of 1x L1 cache read).
x86 is not far more efficient when reading/writing aligned locations, in most cases! One of the performance secrets is that unaligned access is really fast in modern x86. There is no penalty at all if the load doesn't cross a cache line, and especially for the 4 and 8 byte reads we are talking about, that would be the usual case. Even when they cross, they are just half as fast: so "only" 1 load/cycle, rather than 2. Yes, 1 unaligned load every cycle. A lot of code is doing less than 1 load/cycle anyways, so you may not bump up against this limit. So average those types of reads might be a few % slower in a theoretical sense (due to the occasional line crossing), and often close to zero in reality.
Of course you could design pathological cases, like page crossing every load...
> x86 doesn't have any REQUIREMENT for aligned assembly code or data
For data, it does, e.g., any SSE instruction with a memory operand, or any of the "aligned" load variants like vmovdqa. People who say "x86 doesn't need alignment" and create unaligned data will eventually get bitten when a compiler inserts one of those instructions for you. So even x86 compilation relies on the language-level alignment rules.
He supported the alpha build well into the 2000s.
"We used to also provide executables for Windows for the Alpha processor, but stopped after 0.58 due to lack of interest"
0.68 was released in 2005-04-05.
https://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#...
It is sad to see that this company and its products were brought down by pure political maneuvers and hostile takeovers instead of competition or merit.
There were lots of portability issues, for instance GNU Emacs wasn't 64-bit clean whereas Lucid Emacs was, so for two decades I ran Lucid/XEmacs instead.
Alpha was the first microprocessor to hit the billion instructions per second mark (BIPS-0) and was used to build oa 50Gbps router in 1998 using Alphas 21164 with routing code running entirely in L1 cache:
https://www.cs.princeton.edu/courses/archive/fall12/cos561/p...
----------------------------------------- John Carmack's .plan for Jun 25, 1997 -----------------------------------------
We got the new processors running in our big compute server today.
We are now running 16 180mhz r10000 processors in an origin2000. Six months ago, that would have been on the list of the top 500 supercomputing systems in the world. I bet they weren't expecting many game companies. :)
Some comparative timings (in seconds):
mips = 180 mhz R10000, 1meg secondary cache
intel = 200 mhz ppro, 512k secondary cache
alpha = 433 mhz 21164a, 2meg secondary cache
qvis3 on cashspace:
cpus mips intel alpha
---- ---- ---- ----
1 608 905 470
2 309 459
3 208 308
4 158 233
8 81
12 57
16 43
The timings vary somewhat on other tools - qrad3 stresses the main memory a lot harder, and the intel system doesn't scale as well, but I have found these times to be fairly representative. Alpha is almost twice as fast as intel, and mips is in between.
None of these processors are absolutely top of the line - you can get 195 mhz r10k with 4meg L2, 300 mhz PII, and 600 mhz 21164a. Because my codes are highly scalable, we were better off buing more processors at a lower price, rather than the absolute fastest available.
Some comments on the cost of speed:
A 4 cpu pentium pro with plenty of memory can be had for around $20k from bargain integrators. Most of our Quake licensees have one of these.
For about $60k you can get a 4 cpu, 466 mhz alphaserver 4100. Ion Storm has one of these, and it is twice as fast as a quad intel, and a bit faster than six of our mips processors.
That level of performance is where you run into a wall in terms of cost.
To go beyond that with intel processors, you need to go to one of the "enterprise" systems from sequent, data general, ncr, tandem, etc. There are several 8 and 16 processor systems available, and the NUMA systems from sequent and DG theoretically scale to very large numbers of CPUS (32+). The prices are totally fucked. Up to $40k PER CPU! Absolutely stupid.
The only larger alpha systems are the 8200/8400 series from dec, which go up to 12 processors at around $30k per cpu. We almost bought an 8400 over a year ago when there was talk of being able to run NT on it.
Other options are the high end sun servers (but sparc's aren't much faster than intel) and the convex/hp systems (which wasn't shipping when we purchased).
We settled on the SGI origin systems because it ran my codes well, is scalable to very large numbers of processors (128), and the cost was only about $20k per cpu. We can also add Infinite Reality graphics systems if we want to.
They were expensive. We paid for CPU seconds. Not conducive to experimentation .
The OS sucked. (From an end-user perspective, that is). It was both verbose and unfriendly. At least Unix was succinct.
Most of the people using the system were engineers, mathematicians, and comp-sci students, who all preferred either Unix or Windows.
The computer itself was fairly poorly designed, and I remember the memory bus (and g77 compiler) in the thing kept it only about as fast as a contemporary intel chip; it eventually suicided itself during one of Berkeley's frequent power outages.
The biggest practical drawback for me was that Netscape wasn't available as an Alpha binary. Running it with the open source FX32 x86 emulator was too slow. It performed about as well as a Python-based browser at the time. I ended up using ethernet to run Netscape and other x86-focused software on a 486DX4-100 with remote X display back to the Alpha which had my nice monitor.
I brought that Multia with me to my first job, and used it to do 64-bit portability work (on Linux) for an middleware/communication project that we were busy porting to many obscure 64-bit HPC platforms. It was fun to have a 64-bit Linux at home, long before x86_64 came onto the scene.
I do remember playing Quake on the thing; that was pretty cool.
I had one Customer in the late 90's w/ an Alpha-based application (based on SQL Server under Windows NT on an Alpha Server 5305). As a tech who had only used x86-based servers up to that point I found the machine to be very easy to setup and use. It just felt like a strange PC. (I knew it was different-- one look inside was enough to tell that-- but it didn't feel tremendously different than, say, a fat and heavy dual Pentium Pro-based system from Intel in a similar chassis.)
Later on, I worked at a healthcare company that used a cluster of Alphas running OpenVMS or whatever the hell that OS is called. This was circa 2011-2014. It was DEFINITELY NOT COOL ANYMORE. That hardware was really old and the software on it was subject to frequent restarts due to memory leaks. The company used it to try and operate order intake for a multi-site online pharmacy. The system was impossible to interact with, it had a bizarre TCP socket based API, one awful, buggy, SOAP service, and otherwise data could come out via reports generated in a binary file format. Not strictly DEC's fault as the Alpha hardware did last a long time, but it was generally an awful experience for me to have to deal with that particular system. The company tried and failed to replace it so they doubled down, bought the source code for a ridiculous sum in the millions of dollars, and proceeded to try and maintain it themselves by hiring crusty old timers whose people skills were either way out of date or never existed in the first place.
Oh, and the repairs to the hardware were through a local computer salvage firm that basically bought boards and other bits off of EBay. This is a major player in the online pharmacy space, mind you.