dmcq (dmcq.delete@this.fano.co.uk) on February 22, 2019 7:23 am wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on February 21, 2019 4:31 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 21, 2019 8:03 am wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on February 21, 2019 12:53 am wrote:
> > > >
> > > > Linus is the ultimate unixoid. I paid attention that even
> > > > less devoted unixoids are high on native development.
> > > > For me, as one that drinks and breaths cross-development all his professional
> > > > life, it sounds strange, but this mindset is not rare at all.
> > >
> > > I can pretty much guarantee that as long as everybody does
> > > cross-development, the platform won't be all that stable.
> > >
> > > Or successful.
> > >
> > > Some people think that "the cloud" means that the instruction
> > > set doesn't matter. Develop at home, deploy in the cloud.
> > >
> > > That's bullshit. If you develop on x86, then you're going to want to deploy
> > > on x86, because you'll be able to run what you test "at home" (and by "at home"
> > > I don't mean literally in your home, but in your work environment).
> > >
> > > Which means that you'll happily pay a bit more for x86 cloud hosting, simply because it matches
> > > what you can test on your own local setup, and the errors you get will translate better.
> > >
> > > This is true even if what you mostly do is something ostensibly cross-platform like just run perl
> > > scripts or whatever. Simply because you'll want to have as similar an environment as possible,
> > >
> > > Which in turn means that cloud providers will end up making more money from their x86 side, which
> > > means that they'll prioritize it, and any ARM offerings will be secondary and probably relegated
> > > to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff).
> > >
> > > Guys, do you really not understand why x86 took over the server market?
> > >
> > > It wasn't just all price. It was literally this "develop at home" issue. Thousands of small
> > > companies ended up having random small internal workloads where it was easy to just get a random
> > > whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it
> > > became a "real server". And then once that thing expanded, suddenly it made a whole lot of sense
> > > to let somebody else manage the hardware and hosting, and the cloud took over.
> > >
> > > Do you really not understand? This isn't rocket science. This isn't some made up story.
> > > This is literally what happened, and what killed all the RISC vendors, and made x86 be
> > > the undisputed king of the hill of servers, to the point where everybody else is just
> > > a rounding error. Something that sounded entirely fictional a couple of decades ago.
> > >
> > > Without a development platform, ARM in the server space is never going to make it. Trying to sell a
> > > 64-bit "hyperscaling" model is idiotic, when you don't have customers and you don't have workloads
> > > because you never sold the small cheap box that got the whole market started in the first place.
> > >
> > > The price advantage of ARM will never be there for ARM servers unless you get enough volume to make
> > > up for the absolutely huge advantage in server volume that Intel has right now. Being a smaller die
> > > with cheaper NRE doesn't matter one whit, when you can't make up for the development costs in volume.
> > > Look at every ARM server offering so far: they were not only slower, they were more expensive!
> > >
> > > And the power advantage is still largely theoretical and doesn't show very much on
> > > a system level anyway, and is also entirely irrelevant if people end up willing to
> > > pay more for an x86 box simply because it's what they developed their load on.
> > >
> > > Which leaves absolutely no real advantage to ARM.
> > >
> > > This is basic economics.
> > >
> > > And the only way that changes is if you end up saying "look, you can deploy more cheaply
> > > on an ARM box, and here's the development box you can do your work on".
> > >
> > > Actual hardware for developers is hugely important. I seriously claim
> > > that this is why the PC took over, and why everything else died.
> > >
> > > So you can pooh-pooh it all you want, and say "just cross-build", but as long as you do that, you're going
> > > to be a tiny minority, and you don't see the big picture, and you're ignoring actual real history.
> > >
> > > And btw, calling this an "unixoid" mindset is just showing what a total disconnect to reality
> > > you have, and how stupid your argument is. Unix lost. Yes, it lives on in the shape of Linux,
> > > but Unix lost not just to Linux, but to Windows. In fact, arguably it lost to windows first.
> > >
> > > Why? Same exact reason, just on the software side. In both cases. Where did you find developers?
> > > You found them on Windows and on Linux, because that's what developers had access to. When those
> > > workloads grew up to be "real" workloads, they continued to be run on Windows and Linux, they weren't
> > > moved over to Unix platforms even if that would have been fairly easy in the Linux case. No, that
> > > was just unnecessary and pointless work. Just continue to deploy on the same platform.
> > >
> > > Exact same issue on the software side as with the hardware. Cross-development is pointless
> > > and stupid when the alternative is to just develop and deploy on the same platform. Yes,
> > > you can do it, but you generally would like to avoid it if at all possible.
> > >
> > > End result: cross-development is mainly done for platforms that are so weak as to make it
> > > pointless to develop on them. Nobody does native development in the embedded space. But whenever
> > > the target is powerful enough to support native development, there's a huge pressure to
> > > do it that way, because the cross-development model is so relatively painful.
> > >
> > > The corollary to the above is that yes, cross-development is also done when the target environment
> > > is too expensive to do native development on. That was the case for the big iron and traditional
> > > big Unix boxes. But that seriously erodes support for the expensive platform, and makes the cheap
> > > development platform much more able and likely to grow up into that space.
> > >
> > > It's why x86 won. Do you really think the world has changed radically?
> > >
> > > Linus
> >
> > I think you are right in the main. However you have missed out a few things.
> >
> > Firstly back then it was not just a question of the machine architecture being different.
> > There was a different version of Unix or some other system running on every different
> > machine architecture. And this was far more visible and a problem than the machine architecture.
> > Linux is responsible for removing most of that problem, thanks very much
> >
> > Secondly the compilers and associated systems have become much better. Back then you had to stick in loads
> > of machine code to do things efficiently. Nowadays the need for such code is very much reduced.
> >
> > Thirdly the systems for running with remote storage and compiling and running were very primitive
> > and just a pain. Nowadays it is quite normal to run compilations and tests remotely.
> >
> > So yes it was very important then. but nowadays it is quite possible and even normal
> > to run remote Linux jobs via a Windows machine for instance. Nevertheless I agree it
> > would be far better to have local desktops or laptops with the target architecture, if
> > only to give people a feeling of ownership an affection. These things are important.
>
> Also on the bit about "Trying to sell a 64-bit "hyperscaling" model is idiotic, when
> you don't have customers and you don't have workloads because you never sold the small
> cheap box that got the whole market started in the first place." You may think that
> but the plan as far as I can see is to go top down rather than bottom up.
>
> There are very good reasons for going top down. At the bottom x86 is good enough and
> the costs of doing ones own thing will outweigh any benefits and isn't part of one's
> main business. In the past there just wasn't anything very much cheaper than the big
> Unix boxes and using an x86 desktop as a server was a liberation for small businesses.
>
> However at the top costs dominate and they can take a longer term view. They can afford to
> do their own thing and they want lots and lots of it. And doing their own thing rather than
> taking what somebody else gives them can give them an advantage. That's a potential market
> of many times the size of AMD's total sales. How much the actual market is going to be in
> the next few years I don't know but I think the essential enablers are now all there.

(a) ARM announces the high end of what’s possible bcs that is sexy. Doesn’t mean smaller isn’t possible. They talk of 16-core chiplets, and seems to me no obvious reason those chipsets can’t be released as individual units for 16core workstations or small servers.

(b) Many readers here (eg the SVE discussion) seem utterly incapable of understanding how LONG TERM planning works. ARM said they had a plan for servers 5 hrs ago, and were poo-poo’d. Now we see this. Do you think it just appeared yesterday?
Same with SVE. These things TAKE TIME. There will be a first use of SVE, and the compilers will still be somewhat ragged, and it will take a fair bit of area. And the usual moron crowd will project from that point forward to all time, and declare SVE a failure...
Five year plans TAKE FIVE YEARS. Ten year plans TAKE TEN YEARS. You’d think anyone more mature than a monkey on crack would understand this, and understand the corollary; that the important consequences will not be seen for five or ten years. But apparently many people cannot understand a time horizon longer than three months, no matter how often you explain this bizarre concept to them.