This sounds like a subjective assessment. I counter with the opinion that most LLMs write technically correct, but bad code. When I read it, it makes me want to gag or poke my eyes out. I spend a lot of time wondering about what kind of person would write it like that, then I realize it’s an LLM
The tool is important but then so it's the way you use it. I've seen small LLMs produce good code and frontier LLMs produce poor quality code. Depending on context..
As a fan of Algol 68, I'm pretty excited for this.
For people who aren't familiar with the language, pretty much all modern languages are descended from Algol 60 or Algol 68. C descends from Algol 60, so pretty much every popular modern language derives from Algol in some way [1].
Yes, massively influential, but was it ever used or popular?, I always think of it as sort of the poster child for the danger of "design by committee".
Sure it's ideas spawned many of today's languages, But wasn't that because at the time nobody could afford to actually implement the spec. So we ended up with a ton of "algols buts" (like algol but can actually be implemented and runs on real hardware).
Wow, The Burroughs large system had special instructions explicitly for efficient algol use. You could almost say it was algol hardware. but algol 60 not 68.
There is a large system emulator that runs in a browser, I did not get any algol written but I did have way to much fun going through the boot sequence.
ESPOL was (is?) simply a version of the standard Algol compiler that let you do 'system' sorts of things.
The Burroughs large systems architecture didn't really protect you from yourself, system security/integrity depended on only letting code from vetted compilers run (only a compiler could make a code file, and only a privileged person could make a program a compiler) - so the Algol 60 compiler made code that was safe, Espol could make code that wasn't, could do things a normal user couldn't - you kept the espol compiler somewhere safe away from the students ....
(there was a well known hole in this whole thing involving mag tapes)
As mentioned it evolved into NEWP, and you can get all the manuals from Unisys, as they keep selling it.
Given its architecture, it is sold for batch processing systems where security is paramount.
Yes, ESPOL and NEWP, being one of the first systems languages with UNSAFE code blocks, a binary that is compiled having unsafe is tainted and requires administrator configuration before being allowed to execute by the system.
One cannot just compile such code and execute it right away.
C had 3 major sources, B (derived from BCPL, which had been derived from CPL, which had been derived from ALGOL 60), IBM PL/I and ALGOL 68.
Structs come from PL/I, not from ALGOL 68, together with the postfix operators "." and "->". The term "pointer" also comes from PL/I, the corresponding term in ALGOL 68 was "reference". The prefix operator "*" is a mistake peculiar to C, acknowledged later by the C language designers, it should have been a postfix operator, like in Euler and Pascal.
Examples of things that come from ALGOL 68 are unions (unfortunately C unions lack most useful features of the ALGOL 68 unions. which are implicitly tagged unions) and the combined operation-assignment operators, e.g. "+=" or "*=".
The Bourne shell scripting language, inherited by ksh, bash, zsh etc., also has many features taken from ALGOL 68.
The explicit "malloc" and "free" also come from PL/I. ALGOL 68 is normally implemented with a garbage collector.
C originally had =+ and =- (upto and including Unix V6) - they were ambiguous (a=-b means a= -b? or a = a-b?) and replaced by +=/-=
The original structs were pretty bad too - field names had their own address space and could sort of be used with any pointer which sort of allowed you to make tacky unions) we didn't get a real type system until the late 80s
ALGOL 68 had "=" for equality and ":=" for assignment, like ALGOL 60.
Therefore the operation with assignment operators were like "+:=".
The initial syntax of C was indeed weird and it was caused by the way how their original parser in their first C compiler happened to be written and rewritten, the later form of the assignment operators was closer to their source from ALGOL 68.
Yeah if you ever wondered why the fields in a lot of Posix APIs have names with prefixes like tm_sec and tm_usec it's because of this misfeature of early C.
> it should have been a postfix operator, like in Euler and Pascal.
I never liked Pascal style Pointer^. As the postfix starts to get visually cumbersome with more than one layer of Indirection^^. Especially when combined with other postfix Operators^^.AndMethods. Or even just Operator^ := Assignment.
I also think it's the natural inverse of the "address-of" prefix operator. So we have "take the address of this value" and "look through the address to retreive the value."
The "natural inverse" relationship between "address-of" and indirect addressing is only partial.
You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless.
Moreover, in complex expressions it is common to mix the indirection operator with array indexing and with structure member selection, and all these 3 postfix operators can appear an unlimited number of times in an expression.
Writing such addressing expressions in C is extremely cumbersome, because they require a great number of parentheses levels and it is still difficult to see which is the order in which they are applied.
With a postfix indirection operator no parentheses are needed and all addressing operators are executed in the order in which they are written.
So it is beyond reasonable doubt that a prefix "*" is a mistake.
The only reason why they have chosen "*" as prefix in C, which they later regretted, was because it seemed easier to define the expressions "*++p" and "*p++" to have the desired order of evaluation.
There is no other use case where a prefix "*" simplifies anything and for the postfix and prefix increment and decrement it would have been possible to find other ways to avoid parentheses and even if they were used with parentheses that would still have been simpler than when you have to mix "*" with array indexing and with structure member selection. Moreover, the use of "++" and "--" with pointers was only a workaround for a dumb compiler, which could not determine by itself whether it should access an array using indices or pointers. Normally there should be no need to expose such an implementation detail in a high-level language, the compiler should choose the addressing modes that are optimal for the target CPU, not the programmer. On some CPUs, including the Intel/AMD CPUs, accessing arrays by incrementing pointers, like in the old C programs, is usually worse than accessing the arrays through indices (because on such CPUs the loop counter can be reused as an index register, regardless of the order in which the array is accessed, including for accessing multiple arrays, avoiding the use of extra registers and reducing the number of executed instructions).
With a postfix "*", the operator "->" would have been superfluous. It has been added to C only to avoid some of the most frequent cases when a prefix "*" leads to ugly syntax.
> You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless.
This is due to the nature of lvalue and rvalue expressions. You can only get an object where * is meaningful twice if you've applied & meaningfully twice before.
int a = 42;
int *b = &a;
int **c = &b;
I've applied & twice. I merely had to negotiate with the language instead of the parser to do so.
> and all these 3 postfix operators can appear an unlimited number of times in an expression.
In those cases the operator is immediately followed by a non-operator token. I cannot meaningfully write a[][1], or b..field.
> The only reason why they have chosen "*" as prefix in C, which they later regretted, was because it seemed easier to define the expressions "++p" and "p++" to have the desired order of evaluation.
It not only seems easier it is easier. What you sacrifice is complications is defining function pointers. One is far more common than the other. I think they got it right.
> With a postfix "*", the operator "->" would have been superfluous.
Precisely the reason I dislike the Pascal**.Style. Go offers a better mechanism anyways. Just use "." and let the language work out what that means based on types.
I'm offering a subjective point of view. I don't like the way that looks or reads or mentally parses. I'm much happier to occasionally struggle with function pointers.
Some languages do define &&b, like Rust, where its effect is similar to the parent post's C example: it creates a temporary stack allocation initialized with &b, and then takes the address of that.
You could argue this is inconsistent or confusing. It is certainly useful though.
Incidentally, C99 lets you do something similar with compound literal syntax; this is a valid expression:
> The only reason why they have chosen "" as prefix in C, which they later regretted, was because it seemed easier to define the expressions "++p" and "*p++" to have the desired order of evaluation.
There has been no shortage of speculation, much of it needlessly elaborate. The reality, however, appears far simpler – the prefix pointer notation had already been present in B and its predecessor, BCPL[0]. It was not invented anew, merely borrowed – or, more accurately, inherited.
The common lore often attributes this syntactic feature to the influence of the PDP-11 ISA. That claim, whilst not entirely baseless, is at best a partial truth. The PDP-11 did support pre-increment and post-increment indirect address manipulation – but notably lacked their symmetrical complements: pre-increment and post-decrement addressing modes[1]. In other words, it exhibited asymmetry – a gap that undermines the argument for direct PDP-11 ISA inheritance, i.e.
[1] PDP-11 ISA allocates 3 bits for the addressing mode (register / Rn, indirect register (Rn), auto post-increment indirect / (Rn)+ , auto post-increment deferred / @(Rn)+, auto pre-decrement indirect / -(Rn), auto pre-increment deferred / @-(Rn), index / idx(Rn) and index deferred / @idx(Rn) ), and whether it was actually «let's choose these eight modes» or «we also wanted pre-increment and post-decrement but ran out of bits» is a matter of historical debate.
The prefix "*" and the increment/decrement operators have been indeed introduced in the B language (in 1969, before the launch of PDP-11 in 1970, but earlier computers had some autoincrement/autodecrement facilities, though not as complete as in the B language), where "*" has been made prefix for the reason that I have already explained.
The prefix "*" WAS NOT inherited from BCPL, it was purely a B invention due to Ken Thompson.
In BCPL, "*" was actually a postfix operator that was used for array indexing. It was not the operator for indirection.
In CPL, the predecessor of BCPL, there was no indirection operator, because indirection through a pointer was implicit, based on the type of the variable. Instead of an indirection operator, there were different kinds of assignment operators, to enable the assignment of a value to the pointer, instead of assigning to the variable pointed by the pointer, which was the default meaning.
BCPL has made many changes in the syntax of CPL, whose main reason was the necessity of adapting the language to the impoverished character set available on American computers, which lacked many of the characters that had been available in Europe before IBM and a few other US vendors have succeeded to replace the local vendors, also imposing thus the EBCDIC and later the ASCII character sets.
Several of the changes done between BCPL and B had the same kind of reason, i.e. they were needed to transition the language from an older character set to the then new ASCII character set. For instance the use of braces as block delimiters was prompted by their addition into ASCII, as they were not available in the previous character set.
The link that you have provided to a manual of the B language is not useful for historical discussions, as the manual is for a modernized version of B, which contains some features back-ported from C.
There is a manual of the B language dated 1972-01-07, which predates the C language, and which can be found on the Web. Even that version might have already included some changes from the original B language of 1969.
* was the usual infix multiplication operator in BCPL, and it was not used for pointer arithmetic.
The BCPL manual[0] explains the «monadic !» operator (section 2.11.3) as:
2.11.3 MONADIC !
The value or a monadic ! expression is the value of the storage cell whose address is the operand of the !. Thus @!E = !@E = E, (providing E is an expression of the class described in 2.11.2).
Examples.
!X := Y Stores the value of Y into the storage cell whose address is the value of X.
P := !P Stores the value of the cell whose address is the value of P, as the new value of P.
The array indexing used the «V ! idx» syntax (section 2.13, «Vector application»).
So, the ! was a prefix operator for pointers, and it was an infix operator for array indexing.
In Richard's account of BCPL's evolution, he noted that on early hardware the exlamation mark was not easily available, and, therefore, he used a composite *( (i.e. a diagraph):
«The star in *( was chosen because it was available … and it seemed appropriate for subscription since it was used as the indirection operator in the FAP assembly language on CTSS. Later, when the exclamation mark became available, *( was replaced by !( and exclamation mark became both a dyadic and monadic indirection operator».
So, in all likelihood, !X := Y became *(X := Y, eventually becoming *X = Y (in B and C) whilst retaining the exact and original semantics of the !.
The BCPL manual linked by you is not useful, as it describes a recent version of the language, which is irrelevant for the evolution of the B and C languages. A manual of BCPL from July 1967, predating B, can be found on the Web.
The use of the character "!" in BCPL is much later than the development of the B language from BCPL, in 1969.
The asterisk had 3 uses in BCPL, as the multiplication operator, as a marker for the opening bracket in array indexing, to compensate for the lack of different kinds of brackets for function evaluation and for array indexing, and as the escape character in character strings. For the last use the asterisk has been replaced by the backslash in C.
There was indeed a prefix indirection operator in BCPL, but it did not use any special character, because the available character set did not have any unused characters.
The BCPL parser was separate from the lexer, and it was possible for the end users to modify the lexer, in order to assign any locally available characters to the syntactic tokens.
So if a user had appropriate characters, they could have been assigned to indirection and address-of, but otherwise they were just written RV and LV, for right-hand-side value and left-hand-side value.
It is not known whether Ken Thompson had modified the BCPL lexer for his PDP computer, to use some special characters for operators like RV and LV.
In any case, he could not have used asterisk for indirection, because that would have conflicted with its other uses.
The use of asterisk for indirection in B became possible only after Ken Thompson has made many other changes and simplifications in comparison with BCPL, removing any parsing conflicts.
You are right that BCPL already had prefix operators for indirection and address-of, which was different from how this had been handled in CPL, but Martin Richards did not seem to have any reason for this choice and in BCPL this was a less obvious mistake, because it did not have structures.
On the other hand, Ken Thompson did want to have "*" as prefix, after introducing his increment and decrement operators, in order to need no parentheses for pre- and post-incrementation or decrementation of pointers, in the context where postfix operators were defined as having higher precedence than prefix.
Also in his case this was not yet an obvious mistake, because he had no structures and the programs written in B at that time did not use any complex data structures that would need correspondingly complex addressing expressions.
Only years later it became apparent that this was a bad choice, while the earlier choice of N. Wirth in Euler (January 1966; the first high-level language that handled pointers explicitly, with indirection and address-of operators) had been the right one. The high-level languages that had "references" before 1966 (the term "pointer" has been introduced in IBM PL/I, in July 1966), e.g. CPL and FORTRAN IV, handled them only implicitly.
Decades later, complex data structures became common while the manual optimization of incrementing/decrementing explicitly pointers for addressing arrays became a way of writing inefficient programs, which prevent the compiler from optimizing correctly the array accessing for the target CPU.
So the choice of Ken Thompson can be justified in its context from 1969, but in hindsight it has definitely been a very bad choice.
I take no issue with the acknowledgment of being on the losing side of a technical argument – provided evidence compels.
However, to be entirely candid, I have submitted two references and a direct quotation throughout the discourse in support of the position – each of which has been summarily dismissed with an appeal to some ostensibly «older, truer origin», presented without citation, without substantiation, and, most tellingly, without the rigour such a claim demands.
It is important to recall that during the formative years of programming language development, there were no formal standards, no governing design committees. Each compiled copy of a language – often passed around on a tape and locally altered, sometimes severely – became its own dialect, occasionally diverging to the point of incompatibility with its progenitor.
Therefore, may I ask that you provide specific and credible sources – ones that not only support your historical assertion, but also clarify the particular lineage, or flavour, of the language in question? Intellectual honesty demands no less – and rhetorical flourish is no substitute for evidence.
What you say is right, and it would have been less lazy for me to provide links to the documents that I have quoted.
On the other hand, I have provided all the information that is needed for anyone to find those documents through a Web search, in a few seconds.
I have the quoted documents, but it is not helpful to know from where they were downloaded a long time ago, because, unfortunately, the Internet URLs are not stable. So for links, I just have to search them again, like anyone else.
These documents can be found in many places.
For instance, searching "b language manual 1972" finds as the first link:
There exists an earlier internal report about Euler from April 1965 at Stanford, before the publication of the language in CACM, where both indirection and address-of were prefix, like later in BCPL. However, before the publication in January 1966, indirection has been changed to be a postfix operator, choice that has been retained in the later languages of Wirth.
A dash instead of a dot would be so much more congruent with the way Latin script generally render compounded terms. And a reference/pointer (or even pin for short) is really nothing that much different compared to any other function/operator/method.
some·object-pin-pin-pin-transform is not harder to parse nor to interpret as human than (***some_object)->transform().
C's «static» and «auto» also come from PL/I. Even though «auto» has never been used in C, it has found its place in C++.
C also had a reserved keyword, «entry», which had never been used before eventually being relinquished from its keyword status when the standardisation of C began.
Personally, I think the whole C tangent was a misstep and would love to see Algo 68 turn into Algo 26 or 27. I sort of like C and C++ and many other languages which came, but they have issues. I think Algo 68 could develop into something better than C++, it has some of the pieces already in place.
Admittedly, every language I really enjoy and get along with is one of those languages that produced little compared to the likes of C (APL, Tcl/Tk, Forth), and as a hobbyist I have no real stake in the game.
Using gcc (and similarly clang) removing the '15' from 'array', and allowing it to allocate it as 14 chars will result in warnings for both function calls.
One can hide that ptr to array behind a typedef to make it more readable:
There isn't really much difference between "ignoring warnings" in C and careless use of "unsafe" or "unwrap" in Rust. Once you entered the realm of sloppiness, the programming language will not safe you.
The point is to what extend the tools for safe programming are available. C certainly has gaps, but not having proper arrays is not one of them.
I think what C is missing is everything that people fall back onto clever use of pointers and macros to implement. Not that I think C should have all those things, Zig does a decent job of showing alternatives.
I don't think C is missing anything from Algol 68, but, FLEX and slices would be nice, although Algol's slices are fairly limited but even its limited slices are better than what C offers. Algol 68 operators are amazing but I don't see them playing well with C.
Whilst I think that C has its place, my personal choice of Algol 26 or 27 would be CLU – a highly influential, yet little known and underrated Algol inspired language. CLU is also very approachable and pretty compact.
Consider exploring Ada 2022 as a capable successor to Algol. Its well supported in GCC and scales well from very small to very large projects. Some information is at https://learn.adacore.com/ and https://alire.ada.dev/
That task would be beyond my skills, as I said, I am just a hobbyist. I think it would be interesting to see what would result from going back to one of those early foundational languages and developing a modern language from it. With a language like Algol we don't have the decades of evolution (baggage) which are a big part of languages like C and C++ and trickle into the languages they inspired even if they are trying to remove that baggage. So, what would we get if we went back to the start and built a modern language off of Algol? What would that look like?
I've actually been toying with writing an Algol 68 compiler myself for a while.
While I doubt I'll do any major development in it, I'll definitely have a play with it, just to revisit old memories and remind myself of its many innovations.
If PL/I was like a C++ of the time, Algol-68 was probably comparable to a Scala of the time. A number of mind-boggling ideas (for the time), complexity, an array of kitchen sinks.
It certainly has quite a reputation, but I suspect it has more to do with dense formalism that was quite unlike everything else. The language itself is actually surprisingly nice for its time, very orthogonal and composable.
In 55 years I've never managed to do that, nor has anyone else I know. Plugs normally stay in the wall socket because they have a switch - each wall socket for general use must have a switch. The switch is quite hefty and very obviously off or on, with a red stripe. You get a satisfying audible and tactile click feedback when it is switched.
Recently a person brought in a laptop that had apparently been accidentally brushed off a desk, whilst closed, and had apparently fallen on an upturned plug. The plug had managed to hit the back of the screen, left quite a dent and spider cracking on the screen. The centre of the cracking did not match the dent ...
I'll have to do some trials but even if a plug is left on the ground, will it actually lie prongs upwards? I'll have to investigate lead torsion and all sorts of effects. Its on the to do list but not very high.
Don't leave them unplugged. The standard requires all modern sockets to have switches, so there is no reason to have the plugs lying around on the floor.
I've never had an experience in any house or office where anything has ever been unplugged other than to put it away (a kitchen appliance that doesn't need to live on a counter, or a hair dryer, for example).
Buy a fused extension cord with more plugs, you have now turned one socket into 4, 6, or 8 sockets. You can even get some that have USB built-in, so you don't use a socket up for a phone or tablet charger. They're not even very expensive.
And in an office, I'm pretty sure all equipment (computers, lights, controls for adjustable desks if you have them), are meant to remain permanently plugged in anyway in a properly installed desk setup. What is going on in your office where you're choosing what is plugged in and what isn't, constantly? And why can't your office manager spring £20 for an extension cord with multiple sockets?
I've never stepped on a plug myself, so I agree it's not a major problem.
However, some older houses in the UK have far fewer sockets than more modern properties - sometimes only one or two per room.
And sure, if you need to use a hairdryer and a hair straightener a person with an orderly lifestyle might return them both to a cupboard afterwards - but some people don't mind clutter and just leave them wherever.
When it comes to multiway extension leads - people in the UK are sometimes told it's bad to "overload" sockets but have only a vague understanding of what that means, so some people are reluctant to use them.
"When it comes to multiway extension leads - people in the UK are sometimes told it's bad to "overload" sockets but have only a vague understanding of what that means, so some people are reluctant to use them."
To be fair, most people work on the assumption that if the consumer unit doesn't complain, then it is fair game. They are relying on modern standards, which nowadays is quite reasonable. I suppose it is good that we can nowadays rely on standards.
However, I have lived in a couple of houses with fuse wire boards, one of which the previous occupants put in a nail for a circuit that kept burning out.
Good practice is to put a low rated fuse - eg 5A (red) into extension leads for most devices. A tuppence part is easy and cheap to replace but if a few devices not involved with room heating/cooling blow a 5A fuse, you need to investigate. A hair dryer, for example, should not blow a 5A fuse.
because sometimes you unplug it and leave it around. unless you live like a king sometimes there is 2 sockets and you have 5 devices to plug at different times. european and other ones will be on the side so stepping on it is no problem but uk ones will be the pointy end up
I have one too! 3 out of 6 plugs stopped working! I have 2 plugs outside of mini kitchen area and I have laptop, phone charger, camera charger, 2 ikea lamps, .......
there are no uk plugs here so I'm not complaining:)
if keeping everything plugged works for you, awesome!
The NT kernel dates back to 1993. Computers didn’t exceed 64 logical processors per system until around 2014. And doing it back then required a ridiculously expensive server with 8 Intel CPUs.
The technical decision Microsoft made initially worked well for over two decades. I don’t think it was lame; I believe it was a solid choice back then.
Linux had many similar restrictions in its lifetime; it just has a different compatibility philosophy that allowed it to break all the relevant ABIs. Most recently, dual-socket 192-core Ampere systems were running into a hardcoded 256-processor limit. https://www.tomshardware.com/pc-components/cpus/yes-you-can-...
Tom's hardware is mistaken in their reporting. That's raisng the limit without using CPUMASK_OFFSTACK. The kernel already supported thousands of cores with CPUMASK_OFFSTACK and has at least since the 2.6.x days.
> Computers didn’t exceed 64 logical processors per system until around 2014.
Server systems were available with that since at least the late 90s. Server systems with >10 CPUs were already available in the mid-90s. By the early-to-mid 90s it was pretty obvious that was only going to increase and that the 64-CPU limit was going to be a problem down the line.
That said, development of NT started in 1988, and it may have been less obvious then.
"Server systems" but not server systems that Microsoft targeted. NT4 Enterprise Server (1996) only supported up to 8 sockets (some companies wrote their own HAL to exceed that limit). And 8 sockets was 8 threads with no NUMA back then, not something that would have been an issue for the purposes of this discussion.
That was what stuck, but supporting the big servers was also part of their multifaceted strategy. That's why the alpha, itanium, powerpc, and mips ports existed.
> And x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it.
If that were the case the above system wouldn't have needed 8 sockets. With NUMA systems the app needs to be scheduling group aware anyways. The difference here really appears when you have a single socket with more than 64 hardware threads, which took until ~2019 for x86.
The same reasons it would on macOS or Windows, most people just aren't writing software which needs to worry about having a single process running many hundreds of threads across 8 sockets efficiently so it's fine to not be NUMA aware. It's not that it won't run at all, a multi-socket system is still a superset of a single socket system, just it will run much more poorly than it could in such scenarios.
The only difference with Windows is a single processor group cannot contain more than 64 cores. This is why 7-Zip needed to add processor group support - even though a 96 core Threadripper represents as a single NUMA node the software has to request assignment to 2x48 processor groups, the same as if it were 2 NUMA nodes with 48 cores each, because of the KAFFINITY limitation.
Examples of common NUMA aware Linux applications are SAP Hana and Oracle RDBMS. On multi-socket systems it can often be helpful to run postgres and such via https://linux.die.net/man/8/numactl too, even if you're not quite the scale you need full NUMA awareness in the DB. You generally also want hypervisors to pass the correct NUMA topologies to guests as well. E.g. if you have a KVM guest with 80 cores assigned on a 2x64 Epyc host setup then you want to set the guest topology to something like 2x40 cores or it'll run like crap because the guest is sees it can schedule one way but reality is another.
There were single image systems with hundreds of cores in the late 90s and thousands of cores in the early 2000s.
I absolutely stand by the fact that Intel and AMD didn't pursue high core count systems until that point because they were so focused on single core perf, in part because Windows didn't support high core counts. The end of Denmark scing forced their hand and Microsoft's processor group hack.
Do you have anything to say regarding NUMA for the 90s core counts though? As I said, it's not enough that there were a lot of cores - they have to be monolithically scheduled to matter. The largest UMA design I can recall was the CS6400 in 1993, to go past that they started to introduce NUMA designs.
Windows didn't handle numa either until they created processor groups, and there's all sorts reasons why you'd want to run a process (particularly on Windows which encourages single process high thread count software archs) that spans numa nodes. It's really not that big if a deal for a lot of workloads where your working set fits just fine in cache, or you take the high hatdware thread count approach of just having enough contexts in flight that you can absorb the extra memory latency in exchange for higher throughput.
6.1 (2009) - Processor Groups to have the KAFFINITY limit be per NUMA node
Xeon E7-8800 (2011) - An x86 system exceeding 64 total cores is possible (10x8 -> requires Processor Groups)
Epyc 9004 (2022) - KAFFINITY has created an artificial limit for x86 where you need to split groups more granular than NUMA
If x86 had actually hit a KAFFINITY wall then the E7-8800 even would have occured years before processor groups because >8 core CPUs are desirable regardless if you can stick 8 in a single box.
The story is really a bit reverse from the claim: NT in the 90s supported architectures which could scale past the KAFFINITY limit. NT in the late 2000s supported scaling x86 but it wouldn't have mattered until the 2010s. Ultimately KAFFINITY wasn't an annoyance until the 2020s.
> other systems had been exceeding 64 cores since the late 90s.
Windows didn’t run on these other systems, why would Microsoft care about them?
> x86 arguably didn't ship >64 hardware thread systems until then because NT didn't support it
For publicly accessible web servers, Linux overtook Windows around 2005. Then in 2006 Amazon launched EC2, and the industry started that massive transition to the clouds. Linux is better suited for clouds, due to OS licensing and other reasons.
> Windows didn’t run on these other systems, why would Microsoft care about them?
Because it was clear that high core count, single system image platforms were a viable server architecture, and NT was vying for the entire server space, intending to kill off the vendor Unices.
. For publicly accessible web servers, Linux overtook Windows around 2005. Then in 2006 Amazon launched EC2, and the industry started that massive transition to the clouds. Linux is better suited for clouds, due to OS licensing and other reasons.
Linux wasn't the only OS. Solaris and AIX were NT's competitors too back then, and supported higher core counts.
That doesn't mean every platform was or would have been profitable. x86 became 'good enough' to run your mail or web server, it doomed other architectures (and commonly OSes) as the cost of x86 was vastly lower than the Alphas, PowerPCs, and so on.
Cockies are the pranksters of the bird world. They're smart and they think it's hilarious to mess with each other and anyone else. They also tear everything to pieces. So it's no surprise really that if any bird worked out how to operate a drinking fountain it'd be these hilarious little jerks.
I was visiting a place that takes in rescue animals, in this case they had a lot of birds.
In their typical speech to people about NOT keeping birds as pets they described some of the birds as "highly curious, the maturity of a human 5 year old, with an intense desire to be destructive".
My wife always joke about how parrots sound like a fun pet until you consider the phrase "Flying eternal toddlers, that cannot be diapered or potty-trained, with can-opener mouths."
On top of that, they have one tool, and it's a pair of boltcutters you can't take away. And the most clever of them have a good chance to outlive their owners.
There's one at a wildlife sanctuary in Tasmania reported to be 110 or so ("Fred", Bonorong Wildlife Sanctuary). Original owner is long dead, obviously.
I aspire to one day befriend a local murder of crows. Not to keep as pets or to make dependent on me, but maybe to bribe to clean up trash or steal quarters for me... or to defend my honor should the need arise.
We had a galah chewing our hosepipe the other day. I pointed and said "oi!" and the little scamp stopped, straightened up, looked me right in the eye and ... did it again.
Oh and not to forget the kookas. I heard a pop and noise like water a few weeks ago, and ran into our living room. Outside the main window there's that hose reel mounted on the wall that was spraying freely against the glass. A kookaburra had somehow pulled the hozelock end off and was taking a shower.
I will never forget watching a kookaburra swoop down as my grandmother went to take a bite out of a bacon sandwich, and stealing a piece of bacon out of it without touching her or the bread. It then sat on a branch whacking the bacon against it to "kill it" before eating it.
Same with me, but I was camping as a kid. One took the snag out of my mates bread just as he was about to bite it. It made sure it was dead by hitting it on the tree it landed in.
It seems a standard childhood memory! I had a chicken and salad sandwich downgraded to a salad sandwich while I held it my hands as a child. Couple of decades later, almost identical thing happened to my own kid.
The most accurate representation of "Chaotic Neutral" - the cheeky bastards love stealing ANYTHING, and when there's nothing to steal they'll start ripping the rubber off your car door seals (or windshield wipers).
They are amazing birds, very deserving of the name "Clown of the Mountains".
Seagulls, magpie and ibis (im not being fun or joking here) have evolved to exhibit cooperative traits and behaviours to get food, including tricking, diverting, cooperating and most annoying literally staunching people.
I was having a burrito on manly wharf a long while back, a seagull just lands on the table and death stares me...i felt uncomfortable and moved, because i know they will try and take my food off me!
I saw an ibis and magpie work on opening a macdonalds bin, take out the black rubbish bag, tear it, splay its contents and fish for paper macdonalds bags!
When I lived in Australia we had a wooden full length porch (elevated), and where we lived in the hills outside Melbourne we could easily have 20-30 cockatoos hang out on it in the morning. They were mercifully not loud, but they absolutely destroyed the deck rails, and we had to replace them with heavier duty industrial plastic deck.
Or gangsters. We had a bird feeder, which we occasionally let run dry. A cockatoo got pissed with this, and concocted a scheme. When the feeder was empty he sat on the outside fridge and screeched. Once he got your attention, he made sure he was in full view and started destroying things . He only stopped when you put out more feed.
Amused by this I mentioned it at a neighborhood BBQ, and was greeted by a chorus of "oh yes, that happens at my place too". The guy holding the BBQ held up his BBQ tools and said: "See, brand new, this is the 3rd set". It was a neighborhood wide protection racket run by one bird.
Indeed. My father spent a lot of time bellowing at cockatoos that’d land in his fruit trees and tear them to pieces. He’d storm about and wave a broom at them until they took off. Classic old man yelling at clouds.
When he was on the other side of the house in the garage, they’d take fruit from the trees and drop them on the sloping driveway so they rolled down into the garage. Come play old fella.
reply