A lot of good stuff in there
A lot of good stuff in there
Posted Feb 14, 2025 3:04 UTC (Fri) by butlerm (subscriber, #13312)In reply to: A lot of good stuff in there by khim
Parent article: New leadership for Asahi Linux
As far as progress goes, I believe Google is your friend. Articles on the subject have appeared here and on a couple of other sites within the past month or two. As far as Modula-3's memory safety is concerned, same answer as with C - specify exact implementation defined behavior so code that is memory safe can be written and demonstrated to be memory safe. As far as all the suggested languages are concerned I suggested that they would be worth trying as experiments - or even research projects. I can't quite see the great harm that would come from that.
As far as languages that normally use a tracing garbage collector are concerned, I am not sure where you get the idea that they must use a tracing garbage collection instead of something like an internal implementation of reference counting with extensions to break cycles, or why they would require embarassing pauses, or have performance characteristics worse than RCU or a slab allocator for that matter.
The languages I mentioned are just the beginning. With a little bit of software engineering you could translate the entire Linux code base into an appropriate dialect of Python and with appropriate compiler technology compile it to have performance greater than that exhibited by the C code base right now. I am pretty sure that would also be possible with languages like Fortran, Java, and Eiffel with the appropriate extensions.
Not to mention assembly language with automated translation from of assembly code from one CPU architecture to another. With a little creativity one could write and maintain the entire kernel in a close derivative of 68000 assembly language and automatically cross-assemble it into every target architecture the Linux kernel supports - *and* check for and maintain all the safety guarantees expected of a modern system level programming language. That is probably not the best way to maintain a kernel, but it would be hard to beat a kernel written in assembly language for performance. Netware 386 was written in assembly language for a reason.
None of this stuff is impossible or has been shown to be impossible. Anyone who thinks it is simply lacks imagination or is too dedicated to one possible solution to carefully consider any of the others.
Posted Feb 14, 2025 4:12 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Erm... What?
Posted Feb 14, 2025 8:30 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
???
Forth, anyone?
Cheers,
Posted Feb 14, 2025 11:51 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Every layer of abstraction adds overhead. Forth is not an exception. It's slower and less efficient than assembler… but also more compact! That's remarkable, but not unique, quality. Microsoft have allegedly used some variant of p-Code in their early software for the same reason.
Posted Feb 14, 2025 8:54 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
Posted Feb 14, 2025 10:33 UTC (Fri)
by khim (subscriber, #9252)
[Link] (20 responses)
Who told you I'm here “to win friends and influence people”? I'm here to learn… if others have anything worthwhile to teach me. It happens. This phrase just means that you are an idiot or you think I'm an idiot… is it an insult? You can treat it as one, if you want, but that's just the fact. Rice's Theorem result couldn't be “fixed” in an idiotic way that you propose because it, fundamentally, means that it's impossible to transform the program in any way, except purely syntactical) and then ask “does this program still performs in the exact same way or not”. Question of “how big the program have to be for that question not to be unanswerable” is interesting, but only in a purely theoretical sense: in practice verifiers start to require more power and time than we may ever have very quickly, before size of the program reaches anything resembling the OS kernel, even primitive OS kernel (like MS-DOS). Because “internal implementation of reference counting with extensions to break cycles” is simply one way to implement tracing GC? The fundamental property of tracing GC is that it insists that it should know everything about all references from and to all objects anywhere in the system. “Extensions to break cycles” share that property and thus split the whole world in two: the one handled by GC and the one that's not handled by GC. And then we are back to the square one because someone, somehow, have to write and support that “world that's not handled by GC”. I would rather they say they are the end. Of the discussion, not the Rust or Rust for Linux, of course. They show that you don't understand why Rust exists, why Rust for Linux exist and what problem they are solving. Because they are not trying to solve any actual technical problem, but rather their existence and popularity have shown us that we hit something that's impossible to solve by technical means and it's time to “redefine the task”. In parcticular it's impossible to create a language for the “we code for hardware” guys which would both produce optimal (or close to optimal) result and not turn the program into a pile of goo when certain, hard to test and detect, conditions are violated. The solution to that social problem is social and very-well known, too: one funeral at time approach works reliably… others… not so much. Rust for Linux is an interesting experiment to see if that problem can be solved without throwing out the work of thousands of people and starting from scratch. It's very interesting and it would be cool to see if Linus could pull of the third revolution (after Linux itself and then Git), but for all his successes in the years past I wouldn't expect him to mass-change Sauls to Pauls… that's not how humans work. Some people would be converted… but most wouldn't. Would that be enough to save Rust for Linux (and, by extension, Linux)? I have no idea really. But I know that expecting technical solutions to social problems is foolish and expecting to change social problem by a decree of top guys simply wouldn't work. Yet another idiotic proclamation not justified by anything. I guess if you would define “appropriate dialect of Python” as “something that looks like a Python program from the outside but can be syntactically translated to C” (because purely syntactical change sidesteps the Rice theorem) then it may even be true, but I doubt you have meant it like that. These things exist but you lose anywhere between 50% and 90% of performance. Precisely because you have to spend a lot of resources emulating behavior that's not needed at all – but it's not possible to detect that and not emulate it (back to the Rice's theorem, again). The more efficient and tricky your assembler program the larger the slowdown. To faithfully emulate all aspects of 3.58 MHz SNES and make all assembler programs with all nasty tricks their authors have invented work one needs a 3GHz CPU. Hardly a way to produce an OS that real people would use for real work. Another iAPX 432? It would work exactly as “efficiently” (that is: very inefficiently) and would achieve exactly the same level as success as original. Possible? Maybe. Feasible? Most likely no. The majority of the Linux kernel code is in drivers and this 3x-10x slowdown and drivers don't play well: hardware loses patience and state, then nothing works. Transpiled from one CPU architecture and thus at least 3x to 10x slower? Easy. Not all languages would be able to beat it, but many are enough for that. Sure. And that reason was: it had no need to support anything by 386 and had no need anything by file and printer sharing. When people started demanding more things from their network OSes it died extremely quickly. There are lots of OSes that are written in assembler language still in use. You never hear about them because, these days, they need emulators and thus are much slower than anything else. And anyone who tells tales that are not justified by history, experience or even math is just a buffoon. And you sound like a someone who have never done any work in any relevant area, be it binary translation, language development or kernel OS development… what makes you sure you can teach anything worthwhile to anyone who have done such work?
Posted Feb 14, 2025 14:32 UTC (Fri)
by james (subscriber, #1325)
[Link] (19 responses)
Incidentally, on Netware performance, he visited them in "1992 or so" and reported:
Posted Feb 14, 2025 16:41 UTC (Fri)
by branden (guest, #7029)
[Link] (18 responses)
I found this part to be a major takeaway:
"...if some human mind created something then your human mind can understand it. You should always assume that, because if you assume it, it throws away all the doubts that are otherwise going to bother you, and it's going to free you to just concentrate on 'what am I seeing, how is it working, what should I do about it, what am I trying to learn from this'. Never, ever think that you're not smart enough; that's all nonsense." -- Robert P. Colwell
Fortunately for cowboys and rock stars in kernel programming as elsewhere--and the managers who enable them--too few people hear or heed this advice. In these circles, it is believed that one's odds of professional advancement improve as one more convincingly illustrates that one's colleagues are intellectually hamstrung. To put it nicely.
I'm no fan of Intel as a firm but have found much to admire architecturally in their failed experiments, like the 432, the i960, and, yes, the notorious IA64 (Itanium)--I gather that much of what what the last demanded of compilers, drawing furious opposition that labeled the machine dead on arrival, is now done by compilers as a matter of routine. If that's correct, it's not too different from the Ada/i432 situation.
Observing the tenor of LKML's most heated disputes, we might say that only a second-rate hacker learns from his own mistakes, let alone draws a lesson from anyone else's. A consensus that certain mistakes didn't happen, or won't be aired before an unvetted audience, may be a defining trait of broligarchy.
Posted Feb 14, 2025 17:20 UTC (Fri)
by khim (subscriber, #9252)
[Link] (6 responses)
Nope. Not even remotely close. VLIW was built on the premise that scheduling could be done in the compiler. In advance. Before anything is known about actual availability of data. That's what crashed and burned Pentium 4, Itanic and even for GPUs it proved out not to be feasible, after pipelines there have become diverse enough. And no, compilers couldn't do that. They can kinda-sorta-maybe a tiny bit simulate that with PGO and other tricks (used by BOLT, etc), but these are still very far from precision needed to make VLIW viable. It's only marginally different. i432 have created an architecture which couldn't be fast and compiler was supposed to, somehow, make it fast. And Ada team just completely bombed that and haven't even tried. With Itanic compiler team actually tried. And they even had some achievements… but they could never approach efficiency of hardware scheduler because hardware scheduler is much more primitive but it has much more precise data. When access to memory (main RAM, not L2 or L3 cache) takes 500 cpu cycles… mistakes in scheduling are extremely costly and compilers couldn't prevent them. Yet you apply it entirely wrongly. Instead of trying to understand how things work (and yes, everything that human invented could be understood by another human) you just look on things, pat yourself on the back telling yourself that you can understand things… and then, without actually taking time and effort to understand them (hey, that's long and complicated process. let' skip it)… you produce the output “as if” you actually understood them. That's, essentially, what LLMs are doing: they couldn't understand what they are saying and their goal is not to understand anything but to create sequence of words that human reader would perceive as having some meaning… the same means produce the same results, only in case of LLMs we are permitted to call that sequence of worlds “hallucinations”, but if human does the same then it's “opinion”… and we have to respect it — but why?
Posted Feb 14, 2025 18:21 UTC (Fri)
by branden (guest, #7029)
[Link] (5 responses)
>> I found this part to be a major takeaway
> Yet you apply it entirely wrongly.
Uhh, thanks for the insult. The earlier part of your response had utility, though you offer more than baseline reasons to not swallow your claims uncritically. In practically every comment you post to LWN, you wear your motivated reasoning on your sleeve.
> Instead of trying to understand how things work (and yes, everything that human invented could be understood by another human) you just look on things, pat yourself on the back telling yourself that you can understand things… and then, without actually taking time and effort to understand them (hey, that's long and complicated process. let' skip it)… you produce the output “as if” you actually understood them.
Yup, you got me, that's what I do all the time, in every case. You've discovered a completely general truth!
Fortunately it's one that applies only to other people (or maybe just me)--not to you.
> That's, essentially, what LLMs are doing: they couldn't understand what they are saying and their goal is not to understand anything but to create sequence of words that human reader would perceive as having some meaning… the same means produce the same results, only in case of LLMs we are permitted to call that sequence of worlds “hallucinations”, but if human does the same then it's “opinion”… and we have to respect it — but why?
I'm disinclined to think that LLMs are equivalent to what is (or used to be?) called "general intelligence". Perhaps inadvertently, you've supplied a reason to reconsider my presupposition. We can be confident that even if an LLM proves equivalent to a general intelligence (however defined), your own personal state of evolution will prove so advanced that it can't simulate you. You've got the spotlight--keep shreddin', bro!
Posted Feb 14, 2025 18:58 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
If that was an attempt to sarcasm then you failed. Of course it doesn't apply “only to other people”… the human brain is hard-wired to skip thinking as much as it can (it's costly, very power-consuming, process, after all) and I'm not an exception. But I make conscious effort to double check what I write by looking at the various sources (including, but not limited, to Wikipedia) and don't demand “respect to my opinion”. My “opinions”, like everyone's are worth nothing. And if my facts or my reasoning are incorrect then they can be shown to be wrong by referencing to the appropriate contradiction in them. But please don't tell tales about how I should tolerate nonsense because… what would it give me? Friends? Why would I need friends on some remote forum, be it LWN or Reddit ? I have them in “real life”™. LLM would never be able to “prove equivalent to a general intelligence”. What they have achieved, at this point, is the ability to regurgitate things that were told by others. And it's fascinatig (and a tiny bit scary) how often people are doing the same. But it's unclear when and if LLMs would get something that would teach them to do something more. Most likely that moment is still far away, most likely decade or more away… and when it would come they wouldn't be called LLMs. Yes. That's the whole point: you may see it and you may challenge it. If you can. The whole idea is not to convince someone to “respect my opinion”, but to either accept my reasoning or show me where they are wrong.
Posted Feb 14, 2025 20:17 UTC (Fri)
by branden (guest, #7029)
[Link] (3 responses)
> If that was an attempt to sarcasm then you failed.
More like a transparent attempt to flatter your gargantuan ego, since the tenor of your remarks over several years on LWN is that this is a concession you demand in conversation--albeit one that you would seem to prefer not to be gauchely and overtly labelled as such.
> Of course it doesn't apply “only to other people”… the human brain is hard-wired to skip thinking as much as it can (it's costly, very power-consuming, process, after all) and I'm not an exception.
This sounds like the sort of trivial observation one might find at LessWrong, where the admission of universal limitations is a form of currency accepted as a proxy for personal humility. I don't buy it.
> But I make conscious effort to double check what I write by looking at the various sources (including, but not limited, to Wikipedia)
Good for you.
> and don't demand “respect to my opinion”. My “opinions”, like everyone's are worth nothing.
Your model of opinion utility is useless. You might as well call opinions "noise" in the information-theoretic sense; that would make your epistemology more clear to your interlocutors.
I offer, without expecting you to accept, an alternative model. Opinions are a form of knowledge the strength of which derives from the expertise and reliability of the authority uttering them. Expert opinions are valued as evidence in courtrooms because a vetting process is applied to experts. For academic expert witnesses, that process involves verification (well, recitation, at least) of their credentialing by accredited authorities on top of personally authored, peer-reviewed, topically applicable research. That is not the standard we apply to Internet discussion forums or chat around the water cooler in the office; nevertheless we similarly apply weight to a person's claims depending on what is known about their relevant expertise and their past record of reliability.
For example, I found myself reading Robert P. Colwell's oral history interview closely and attentively despite an active disinterest in x86 architecture because (1) he had evident, relevant expertise in the field of computer architecture generally, in which I'm intensely interested and professionally adjacent; and (2) he reached conclusions that seemed consistent with my own <mumble> years of experience in software engineering; and that, bluntly, I was inclined (or biased) to believe already.
I've had numerous encounters with people like you who punk on others for not knowing things. You might concede, in a LessWrong sense, that we are all creatures that wallow constantly in ignorance. Nevertheless when correcting others you do it with an excess of derogation, awarding to yourself the privilege of expressing contempt based solely (or sufficiently) on your "conscious effort to double check what you write by looking at the various sources (including, but not limited, to Wikipedia". Well, bully for you. You checked Wikipedia. Maybe something else.
The contemptible thing about your comment was that you took the statement from Colwell that I quoted, claimed to agree with it, applied it with ludicrous specificity to a tentative claim I made about computer architecture and the history of compiler development, then proffered your (purportedly) superior and conflicting knowledge. Thus, rather than upholding Colwell's perspective as you claimed to do, you undermined it, by counseling others that their minds are inferior to yours--the opposite of Colwell's lesson.
> [I] don't demand “respect to my opinion” ... please don't tell tales about how I should tolerate nonsense
Who said you should? And incorrect statements are not always "nonsense". As noted above, your model confuses simple ignorance with carelessness, both of these with malicious deception, and all of the foregoing with noise in an information channel.
It's not the world's responsibility to give you a raw, noise-free information channel to inerrant truth. (Beware those offering one: they're building a cult.) It's your responsibility to identify imperfect paths to truths that will suffice. Your policy of nondiscrimination among the varieties of imperfect paths to knowledge lead you, apparently, to an intolerant tone and arrogant modes of expression. Alternatively, you already preferred that tone and mode, and developed (or borrowed) an epistemology to justify them.
> what would it give me? Friends? Why would I need friends on some remote forum, be it LWN or Reddit ? I have them in “real life”™.
Good for you for having friends in real life. The classes of relationship for which you seem to have no use, and yet which a forum like LWN comments (which has a narrowly focused audience, demographically and topically) depends, are known as "peers" or "colleagues". (That in turn doesn't mean people have to sickly sweet to each other--first, mandating such encourages belittling rhetoric to take on more baroque forms, crafted carefully to express contempt yet escape censure; second, engineers argue, sometimes passionately, about things all the time. Sometimes we learn new facts that sprout only from contested ground.)
Among peers and colleagues, just as among friends, it is okay to be mistaken or ignorant. What is valuable is to be able to offer, and accept, correction gracefully. Another valuable skill is the capacity to argue an issue, even a contentious one, without unnecessarily involving one's ego.
Some people will be unable or unwilling to associate with you on those bases; sometimes, it will be due to their own prejudices or defects. Other times, it will be solely down to you being supercilious and overbearing. One of these, you can control.
> That's the whole point: you may see it and you may challenge it. If you can. ... The whole idea is not to convince someone to “respect my opinion”, but to either accept my reasoning or show me where they are wrong.
Your point, and idea, need to be larger wholes to make communication with you more than minimally productive.
I concede that minimal productivity might be your objective.
(Meanwhile I'll count down to a scolding by one of the editors. :-/ )
Posted Feb 14, 2025 20:32 UTC (Fri)
by corbet (editor, #1)
[Link] (1 responses)
It's sad, honestly, that we have to keep asking this.
Posted Feb 14, 2025 21:14 UTC (Fri)
by khim (subscriber, #9252)
[Link]
I posted my answer before I saw this request. Sorry about that. I'll stop here.
Posted Feb 14, 2025 21:13 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Means instead of trying to fight the confirmation bias you are embracing it. That's also normal for humans and hard to fight, but that's also what we are supposed to fight if we want to create predictions that are even remotely close to what would actually happen. One simple, yet efficient way to combat it is to compare your past predictions to what have actually happened. This approach have revealed that my picture of the world have few definitely bad spots — one example is Apple. Probably because my view of that company is similar to RMS's view (Remember? Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died), while the majority of Apple users are feeling themselves comfortably in that jail — and there are enough of them to ensure that Apple would be able to do things that any other company couldn't. That's an interesting phenomenon, but it's, thankfully, limited: while Apple continue to be able to squeeze a lot of money from Apple users and force them to do things that human beings are not supposed to acquiescence too… this world is still limited and looks like it would be dismantled at some point, anyway. There are some other blind spots where my predictions are not performing well, but these are mostly related to timings and these are quite hard to predict (e.g. Google killed ChromeOS development, to finally, make sure it only have one platform across laptops, tablets and phone — but that happened in 2024… not decade before that, as was my expectation… Why was Google pouring money into something that would never fly? I have no idea, the move was obvious… but something made it hard to do when it made sense to do). But can you present similar predictions that have been justified or not justified? Do you even look on what you have predicted 10 or 20 years before? I think we are seeing two entirely different lessons there. You look on the Never, ever think that you're not smart enough; that's all nonsense, self-pat yourself on the back and tell yourself “hey, I shouldn't think I'm not smart enough and they all should respect me because I'm smart enough”! And I look on the part that you also cited, yet ignored: it throws away all the doubts that are otherwise going to bother you, and it's going to free you to just concentrate on “what am I seeing, how is it working, what should I do about it, what am I trying to learn from this”… these are important things, respect is earned, not given — but you have the capability to earn it! And then he continues to part where he gives that respect to others: He's still better at it than I'll ever be. I mean, I watched him do what I consider near miracles, like walking up to a refrigerator and telling you that the bearings and the compressor are bad, walking up to a car, telling you that there's something wrong with the carburetor just by listening to it.. And I'm ready to do the same if you are actually better at doing such things: take a look on something where you are an expert and tell me what's wrong and what's going to happen… and then you can be respected for your abilities and knowledge. But… where is that area? Where have you “walked up to something” and amazed someone with your ability to do the correct conclusion from what little you may observe there?
Posted Feb 14, 2025 17:25 UTC (Fri)
by jem (subscriber, #24231)
[Link] (1 responses)
What was wrong with the i960? Wikipedia says it was a "best-selling CPU" in its segment and calls it a "success". Maybe you are confusing it with the i860, which "never achieved commercial success."
Posted Feb 14, 2025 17:38 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Please read the Wikipedia article more carefully: i960 was essentially RISC with added pieces of iAPX432 on top (in the “object oriented” BiiN version). The “base” version (without BiiN silliness) was a success, while all that “object oriented” crazyness was only used in some government-related projects (and while details are classified we can assume that it was mostly for buzzword-compliance because there was no successor).
Posted Feb 14, 2025 17:29 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (8 responses)
But compiler developers aren't drooling idiots, and used the analyses they did that were required to make Itanium perform adequately to help non-Itanium CPUs. As a result, instead of Itanium outperforming Pentium III, as analyses of compiler output from the early 1990s would suggest, Pentium III tended to outperform Itanium because the compiler improvements needed to make Itanium perform well also improved P6's performance.
Posted Feb 14, 2025 18:27 UTC (Fri)
by branden (guest, #7029)
[Link] (7 responses)
That summary is consistent with other accounts I've read. But then that would make the Itanium, rather than a stupid folly, more like the right mistake to make at the right time. Yet that is a far more generous characterization than it normally gets.
I suggest that redemptive readings of architectures that "failed in the market" are more instructive to engineers than x86 (or even ARM) partisanship.
Posted Feb 14, 2025 18:45 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (6 responses)
What Itanium demanded was that you regress compilers for x86, PowerPC etc so that they were back at the level that they were in 1993 or so when the project that became Itanium showed that hand-written EPIC code could compete with compiled output for OoOE machines.
Combine that with the 1998 chip releasing in 2001, having had to be ported forwards a process and cut down to size because it was (quite literally) too big to fit on the maximum possible chip size for 180 nm, let alone the 250 nm it was supposed to come out on, and it was clearly a folly - they literally couldn't build the thing they promised for 1998, it never performed acceptably compared to other CPU designs, HP had to continue PA-RISC for several years because Itanium wasn't good enough to replace it, and the x86-32 compatibility never performed as well as promised.
Posted Feb 14, 2025 19:24 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Note that Itanium wasn't designed by idiots. Like Transputer they were designing the CPU for the wold where development of single-thread core have “hit the wall” near 100MHz and thus new ways of faster execution were needed. In that imaginary world of slow CPUs and fast memory access VLIW made perfect sense and was, in fact, one of the most promising designs. But after Athlon hit 1GHz, at the end of XX century… it became obvious that Itanic just simply make no sense in the world of fast CPUs and slow memory… but Intel had to push it, for marketing reasons, even if it was doomed to fail and it was obvious that it has no future.
Posted Feb 15, 2025 16:37 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (1 responses)
Itanium was a bet that it would be hard to scale clock frequency, but that it would be trivial to go wider (both on external buses and internally). As a bet to take in 1994, that wasn't a bad choice; the failure at Intel was not cancelling Itanium in 1998 when it became clear that Merced would not fit into 250 nm, that process scaling wasn't going to allow it to fit into the next couple of nodes either, and that once you'd trimmed it down to fit the next node, it wasn't going to perform well.
Then, Pentium 4 was a bet that it would be hard to scale logic density, but that clock frequency would scale to at least 10 GHz. Again, wrong with hindsight, but at least this time the early P4 releases were reasonable CPUs; it's just that it didn't scale out as far as intended.
Posted Feb 15, 2025 17:40 UTC (Sat)
by khim (subscriber, #9252)
[Link]
What's notable is that both times bets sounded perfectly reasonable. Cray-1 reached 80Mhz is a year 1975 and PA-7100 and Pentium, POWER2, SuperSPARC… all fastest CPUs for almost two decades topped at around that clock speed! Assuming that trend would continue was natural. Then, suddenly, during Itanium fiasco, 100Mhz barrier was broken and clock speeds skyrocketed… assuming that this trend would continue wasn't too crazy, either! More importantly: when Intel realized that P4 story is bust, too – it quickly turned around and went with P6 descendants… Tejas was cancelled… but for some reason Intel kept Itanium on life support for years.
Posted Feb 14, 2025 20:21 UTC (Fri)
by branden (guest, #7029)
[Link] (2 responses)
> No, it doesn't, because the compiler changes were made before Itanium needed them, precisely because they helped other architectures, too.
I'll confess to being the sort of inferior mind that khim frequently laments, because I'm having a hard time inferring a coherent chronology from the foregoing.
This drooling idiot's going to need a good resource for the struggles of ISA and compiler development in the '90s. Anyone got any references to recommend?
Posted Feb 14, 2025 22:16 UTC (Fri)
by malmedal (subscriber, #56172)
[Link]
Search for EPIC. It's a frequently recurring topic on Usenet's comp.arch, you can try reading the archives or asking.
I don't think the compilers ever scheduled Itanium's instruction-bundles very well. Itanium had superior floating point performance, but I believe this was because the FPU was register-based. x87 used a stack-based instruction set, which did not play very well with superscalar scheduling.
Posted Feb 15, 2025 16:46 UTC (Sat)
by farnz (subscriber, #17727)
[Link]
You'll need a good understanding, also, of out-of-order execution (e.g. Tomasulo's algorithm) and register renaming, to understand why compiler developers were doing more instruction scheduling for IBM POWER CPUs even without Itanium's deep need for explicit scheduling.
The core, though, was that EPIC relied on the instruction stream being pre-scheduled in software with explicit dependency chains and speculation, making the core simpler. Out-of-order execution (OoOE) infers the dependency chains and speculation based on the instructions in the "instruction window"; being able to schedule instructions the way EPIC requires allows OoOE to see more opportunities for parallel execution, since it can execution instructions in parallel wherever there isn't a dependency chain.
A lot of good stuff in there
A lot of good stuff in there
Wol
A lot of good stuff in there
A lot of good stuff in there
> Not sure what happened to two or three replies I posted here, but generally speaking insulting others is not the best way to win friends and influence people.
A lot of good stuff in there
Intel 432
Another iAPX 432? It would work exactly as “efficiently” (that is: very inefficiently) and would achieve exactly the same level as success as original.
Bob Colwell, later to be senior architect on the P6 (= Pentium Pro) and Pentium 4, published postgrad research on why the 432 failed. He was insistent that a lot of people had taken the wrong lessons:
Bob said that nearly all the performance problems were due to the space limitations of the existing manufacturing processes (leading to no memory caches and no general-purpose registers, for example), "part of the problem with the 432 was these guys just weren't paying attention to performance", and this anecdote:
Eventually, I said "Okay, who are you? You know way too much about this technology." He
tells me "I'm the leader of the compiler team." And I said "In that case I probably just fatally
offended you." He said "No, not at all because I know we generate bad code and I don't
care." He said "We don't like the 432 hardware team." And I thought "Oh my God, there is
no hope that this project is going to work when you have the two main casts killing each
other." He said "That hardware team never listened to us compiler folks. At some point we
decided that we'd live up to the letter of the contract but beyond that? No."
Bob thought that 90+% of the performance issues were down to Intel mis-steps, and with a newer manufacturing process, more attention to performance, a redesigned ISA, and a competent compiler, there could be a competitive part.
And the answer came back, "We don't care
what it is, doesn't have to go faster. We're satisfied with the 486." And I thought okay, you're
doomed.
Intel 432
> I gather that much of what what the last demanded of compilers, drawing furious opposition that labeled the machine dead on arrival, is now done by compilers as a matter of routine
Intel 432
Intel 432
> Fortunately it's one that applies only to other people (or maybe just me)--not to you.
Intel 432
To bro or not to bro
As you can imagine, we will indeed ask that the folks involved in this subthread put an end to it.
Countdown reached
Countdown reached
> (2) he reached conclusions that seemed consistent with my own <mumble> years of experience in software engineering; and that, bluntly, I was inclined (or biased) to believe already.
To bro or not to bro
Intel 432
Intel 432
Itanium and compiler changes
the notorious IA64 (Itanium)--I gather that much of what what the last demanded of compilers, drawing furious opposition that labeled the machine dead on arrival, is now done by compilers as a matter of routine.
What made the Itanium dead on arrival is not what it demanded of compilers, but that to succeed it required the compilers to do things for Itanium but not for other architectures. Itanium could not perform adequately unless the compiler scheduled code - but to perform better than Pentium Pro, POWER3 and other out-of-order machines, you needed to ensure that the compiler did not use the scheduling information to do a better job of codegen for those systems.
Itanium and compiler changes
No, it doesn't, because the compiler changes were made before Itanium needed them, precisely because they helped other architectures, too.
Itanium and compiler changes
Itanium and compiler changes
It's notable that Intel bet twice in a row on technology futures that didn't happen.
Itanium and compiler changes
> It's notable that Intel bet twice in a row on technology futures that didn't happen.
Itanium and compiler changes
Itanium and compiler changes
> > But compiler developers aren't drooling idiots, and used the analyses they did that were required to make Itanium perform adequately to help non-Itanium CPUs.
Itanium and compiler changes
I'd suggest looking at the things that came out of IBM research - Single Static Assignment and so on - along with looking deep into how EPIC was supposed to work.
Itanium and compiler changes