Posts by Roo

The IBM BlueGene processors looked to be better balanced than Cell processors to me - and they had FMA with direct pipes to memory (bypassing cache). Their power efficiency was exceptionally good, and they got much closer to hitting their theoretical peak performance than pretty much anything else at the time.

Re: Rolling rolling rolling ... rawhide

I had forgotten that the initial "Yamhills" shipped to consumers were crippled - although I'm pretty sure the Xeon versions were shipped 64bit from day 1.

Timeline wise AMD published the first specs of AMD64 back in 1999 and released their first Opteron in 2003. References to Intel's Yamhill seemed to pop up in early 2002 - at which time AMD were publicly calling out Intel to jump on to their AMD64 bandwagon (and Microsoft had announced they were developing for the AMD64 - so presumably they already had AMD silicon samples to use and Intel could have seen how much of a threat the AMD silicon was).

All that said there is evidence that there was a predecessor to Yamhill, corroborated by whispers on USENET and at least one statement from AMD pointing out that their proposed 64bit chips would support running of 32bit legacy code in early 2002.

Re: Rolling rolling rolling ... rawhide

I don't buy that story at all. What I do know is that, before EPIC was released, Intel's Andy Glew did reveal that Intel had done some fairly well advanced studies into a 64bit x86 but this avenue was shelved in favor of EPIC which was seen as having more growth potential. From what I recall from Glew's posts Intel were keeping the same kind of register count but widening them, AMD took a different route which allowed for more growth - increasing the register count and binning the 8087 shaped barnacle, thus we have monstrously quick AMD64 chips that can pretend to be a Pentium Pro on the rare occasion that they run 32bit code.

Re: Rolling rolling rolling ... rawhide

EPIC was doomed before it left the drawing board for three reasons - both of which were already apparent from the short life of Multiflow Computer Inc - and these reasons were (IIRC) articulated by a number of well-seasoned computer architects on USENET (which back then included folks who worked on the DEC Alpha, ARM, PA-RISC, MIPS, SPARC, POWER, x86 (incl x86-64) - see Andy Glew's posts on the topic in particular).

1) Dynamic Scheduling is always better than static scheduling because a) it adapts to what is actually happening in real time and b) it can work in conjunction with static scheduling.

2) Static scheduling requires large register files and wide datapaths in whatever fabrication process you choose. This means that a VLIW style design will inevitably have a lower clock rate in a given implementation technology relative to say it's RISC peers. The only way a VLIW machine can compensate for this is to widen the datapaths - which again forces the clock to be slower (to manage skew), thus compounding the problem.

3) Advances in hardware fabrication & implementation vastly outpaced any benefits attributable to VLIW.

Full disclosure - I liked the idea of VLIW, it's just that whenever it was implemented in hardware it ended up being slow and more complicated than whatever else was current.

On the plus side Multiflow's efforts were not totally wasted. They did have to write a very good compiler. Their compiler was very well regarded and licensed by competitors who promptly put it to work compiling code for RISC chips (during the peak period of the compiler wars)... The big register files are still with us, but they are implementation details - rather than architectural details, thus modern processors can (and do) take advantage of wide issue and huge register files when and where it suits the implementation...

I think the real point of EPIC was to sink the competitors but leave the x86 alive at the low end, which didn't pan out because AMD spoilt the party with AMD64.

IIRC Linus Torvalds spent some time working for Transmeta on a VLIW architecture - which also sank without (much) trace...

Re: Argh

The Manglement have been chugging the Redmond Koolaid for over 40 years solid, idiocy is one of their minor problems at this point. :)

Re: It's 2024

Fair play on your well thought out response, and apologies for the somewhat trite reply I offer by return (which does not directly invalidate the points you make):

Firstly there is absolutely nothing stating that you can't write Unit Tests that validate the boundaries between components.

Secondly if you are simply duplicating code you've written with your Unit Tests I would suspect that you should change your approach to writing them.

Re: It's 2024

Testing combined with coverage tools and good coverage shakes out the typing issues pretty quickly. I work with both C++ and Python on a daily basis - so I get to have my cake, eat it and blow my toes off type-safety wise. From my perspective (having cut my teeth on K&R C in the mid 80s) it seems that encapsulation, type-safety and inheritance aren't really worth the hoops you have to jump through over the long run. I would trade them all for good quality unit tests every time. :)

Re: Very Different

"It ran only 32 bit. Win9x killed the Pentium Pro because it had no simple switch back to native 8086 mode."

FWIW I ran Win9x on a Pentium Pro just fine - the main gotcha with it was some games didn't run quite as quickly as a stock Pentium at the same clock frequency, it was rarely a deal breaker (for me) though. The flip side was doing actual *work* type stuff under Linux was a *lot* faster on the PPro than the Pentium boxes, because the code was optimized for the PPro rather than for a Pentium.

The Pentium Pro (P6) had a *huge* 256Kb L2 cache that ran at core speed, anything recompiled to take advantage of that cache absolutely blew the doors off P5s (plain old Pentiums). It wasn't much more expensive than the P5 at the time - and was a steal if you were in a position to run code optimized for it. The point of the Pro was to get Intel's snout into the troughs monopolized by the RISC vendors - and it succeeded in that - and also went on to have a long and productive life running Windows 9x & NT in the guise of the Pentium II and Pentium III...

Those were happy days coding for a processor with a fat, fast *and* low-latency cache. Back then I'd happily trade any P5 for any PPro that needed a home where it would be appreciated. :)

Re: Optane is basically ROM

SRAM didn't look like it "naturally formed out of ICs" in my day - it looked like it was generated by a script hooked into the CAD system, validated by the DRC engine, masks were then made from the design, and those masks used to fabricate some dies on 200mm wafers... About as natural as Trump's tan.

Re: Pentium IV

"The reasoning behind risc was that compilers couldn't, without becoming insanely complicated and huge, optimally use the clever cisc instructions and that compilers could translate higher level code in the much simpler risc instructions and effectively apply far more types optimisations with the actual compilers becoming simpler and smaller."

It's often presented that way - but if you follow John Cocke's work that explanation seems backwards and missing the most important bit...

The key driver behind RISC was to fit the processor architecture to what could be efficiently implemented in hardware. Moving the complexity into software to fill in the gaps was a necessary side-effect - I feel fairly safe in asserting that compilers really did not get any simpler. :)

With 20/20 hindsight you can see that as microchip technology advanced the hardware (RISC & CISC) got a lot more complex and the compilers also got a lot more complex too. The NVAX/NVAX+ -> Alpha 21064 -> 21164 -> 21264 -> 21364 illustrate the progression of hardware quite nicely over a short space of time (DEC introduced the GEM compiler with the Alpha line - see Digital Technical Journal Vol. 4).

Intel's Itanium was an interesting throwback to the "simple hardware"/"complex compiler" idea - they made exactly the wrong trade-offs resulting in relatively dumb + inefficient hardware tightly coupled to it's compilers - at a time when competitors were fielding smart + efficient hardware that could run any binary produced by any old compiler quickly & efficiently via the magic of Out-Of-Order execution.

Re: Optane is basically ROM

I can see how you would arrive at your position if you've only ever known EEPROM tech ... The old school *ROM technology was *very* different and should be occupying it's own category though:

ROM : Read Only Memory. Back in the day this might be implemented as a hardwired circuit of diodes, definitively not modifiable (by code) after it left the assembly line.

PROM : Programmable Read Only Memory... Can be programmed (once) - can be implemented as a circuit of fuses.

EPROM : Erasable Programmable Read Only Memory... Typically erased via UV light (those chips with windows covered by sitckers) - really don't know how the programmable bit was done for these...

I can see why you blur the lines with EEPROM, but it is fundamentally different from RAM in terms of how it is addressed and how it is overwritten (aka Selectively Erased then Written).

Just to add to the confusion : Core memory is non-volatile RAM - which also supports unlimited writes... Folks could power cycle a machine and skip the booting as the OS was already in memory... ;)

Re: "Late in Wirth's career, he became a passionate advocate of small software."

"unix was the necessary part of multix:" not quite *violently* disagreeing with you on this, but necessary really is in the eye of the beholder in this case. The MULTICS team had very different objectives to the AT&T UNIX crew, they weren't adding unnecessary stuff from their point of view. MULTICS looks pretty lean to me (see multicians.org), but not lean enough to run on an early PDP-11... I do like your characterization of C+UNIX as being "implemented as a kludge rather than as a design". :)

Re: When did Windows turn into Linux?

Adorable router. Tempted.

Re: Sorry Liam, Not Even Wrong... -- Dave Cutler

"I have done device driver work on RSX-11M - the kernel code that Dave Cutler wrote was very well written (and unusually even better commented!!)"

That adds weight to my assertion that Cutler should have spent more time writing code and less time writing books / whatever it was he was doing that wasn't writing code. The history of RSX-11 is actually quite interesting as it turns out with multiple (independent ?) strands of development and it originating as a port from a PDP-15 OS (RSX-15). It's incredible how many OSes DEC produced - they were developing & supporting TOPS-10, TOPS-20, Ultrix, RSX-11* (several distinct variants) and VMS at one point - so they must have had a *lot* of decent system programmers working at t'Mill.

FWIW I used VMS for a decade or so and found it to be a reliable if eccentric friend. That said I really don't want to see DCL & TPU again. VAX MACRO was kinda fun though - especially having come from 6502 machine code & assembler. :)

Re: Sorry Liam, Not Even Wrong...really?..again?

Here in Blighty the PC was pretty expensive relative to the competition - and was primarily bought & sold as a business computer to run business software. MDA was the cheapest option - and the most common in the early 80s (at least where I lived). Most *business* software was written for that baseline too - you know the stuff: text entry, word processing, spreadsheets, dBase II, etc. I still remember the feeling of acute disappointment on encountering my first PC: the graphics and sound were piss poor relative to a BBC Micro or a C64, and you actually had to spend *extra* money to get sound and graphics that were usuable... :)

Re: Sorry Liam, Not Even Wrong...

I haven't worked with Dave Cutler, but I have spent a fair amount of time using judging him by his works - or at least the stuff he is credited for. The words that come to mind for the products attributed to DC are "baroque", "half-baked", "flakey", "obtuse" and "sophisticated". This might be unfair on Dave Cutler, because he was part of a team of people that produced these products. My guess is that no one else in the teams wanted to "own it" having seen the result of their labours - so they were only to happy for their work attributed to the man.

"Inside Windows NT" by Helen Custer & David N Cutler illustrated the *massive* gulf between DC's "vision" for NT vs what it actually was. I was probably the only person to actually read that book, and then actually measure it up to the grim reality of mid-late 90s vintage Windows NT. Suffice to say Windows NT 3.51 fell some way short of the "vision". The common narrative is that Microsoft somehow double crossed DC so he took his ball home, leaving the product as a half-baked pile of not very good OS. Having compared the "vision" presented in the book vs the grim reality of mid-late 90s Windows NT that story sounds plausible, but the take away point remains that Dave Cutler was given a stratospheric budget & timescale (compared to say RSX or VMS) and still delivered a half-baked pile of not very good OS.

TL;DR : I think DC should have taken a leaf out of Linus' book and spent more time writing his OS instead of writing books about his OS. Case in point: an early cut of Redhat Linux (ie: $0 budget, amateur developers) beat NT 3.51 hands down in every department: hardware support, technical support (Microsoft's support amounted to "pay us $128 to file a bug report that we will ignore"), networking, reliability, performance and scalability.

Re: Someone Else's Computer certification

I think the biggest win w.r.t to (a big) Cloud provider is the ability to serve content globally - and provide some redundancy in the case of an entire region going down. That said there is nothing stopping you from developing your system to be capable of being run in the cloud or on your own host(s), it's not rocket science (IMO).

Re: pile it high, sell it cheap

"Selling it entirely is akin to selling your home because the neighbourhood has deteriorated to the point where you no longer feel safe even going out to buy groceries."

That's a pretty decent analogy, the thing is this is not a new phenomenon. Case in point Maggie Thatcher's government tried to arrange for the sale of INMOS to American investors at a knock down price before brokering a sale to Thorn EMI (yeah, the fire extinguisher folks). INMOS was the company that built the fab in Newport. Total government investmernt in INMOS was £50m (£235m in today's money going by BoE's inflation calculator) which is peanuts really when you compare it to HS2 which comes in at £247m per km.

Re: 'semi' conductor strategy.

You left you coat. :)

Re: Anybody remember Intel StrongARM?

StrongARM was actually developed and produced by Digital Equipment Corporation. StrongARM was a big deal at the time, it was clocked a lot higher than the contemporary ARM cores and opened up a lot of new applications for ARM cores. Compaq bought out DEC, HP bought out Compaq - and at some point in that kerfuffle Intel paid whoever owned DEC at the time a huge wedge of cash to license some big chunks of DEC IP - which included StrongARM. Intel carried on producing StrongARM for a while, got bored and dumped it.

"Linux has failed to fix DLL Hell, which MS fixed by 1997"

As someone who has coded for DOS, Win 3.x, Win 95, Win NT (3.51, 4, ... and so on), no they really didn't sort it out.

These days we have Java, Spring and Node on top of that DLL hell. To compound it we "solve" the problem with VMs, Containers and Flatpack etc to work around the inherent packaging problems...