Amazon’s Chips Threaten Intel • Hacker News Board

Re: Amazon’s Chips Threaten Intel

#301

Post by Koshkin » Tue, Dec 11, 2018, 5:46 PM UTC

reikonomusha wrote: post #195

Meai wrote: post #117

Earlier quoted context omitted.

You are speaking from inside the walled garden here, from the outside the effort of porting to macOS is monumental. The naive way is: I have to buy hardware, learn new Apple specific languages, learn a new OS, learn a new IDE, be compliant with their app store policies, distribution etc. (which applies to Windows now too I suppose).

I suppose I’m an outlier then. I just use normal UNIX tools. No Xcode, no IDE’s, no proprietary toolchains. Maybe my programs are too boring. :) There are some portability quirks for sure, though.

Why not Linux, then? Why pay "the Apple tax"?

Re: Amazon’s Chips Threaten Intel

#302

Post by Koshkin » Tue, Dec 11, 2018, 5:50 PM UTC

pjmlp wrote: post #235

rbanffy wrote: post #172

Earlier quoted context omitted.

The main difference would be in that, since Windows has no native Unix environment, all these tools are added functionality while on the Mac, it overrides built-in functionality and can make things go a bit weird.

Just like it doesn't have a native Win32 environment, rather different personalities built on top of a common layer. UNIX environment on Windows is just like how IBM and Unisys mainframes deal with it.

Indeed. (Except that "WSL" should be read as "Windows Substitute for Linux.")

Re: Amazon’s Chips Threaten Intel

#303

Post by jasonlotito » Tue, Dec 11, 2018, 5:52 PM UTC

e12e wrote: post #276

zaarn wrote: post #271

Earlier quoted context omitted.

Loadbalancers are useful for more than balancing load, you can distribute traffic to the different endpoints on them. They're fairly good at it. 80x is on traffic costs alone, I've detailed that above; 80$ for 1TB of traffic on AWS, not including incoming traffic costs, 1$ for 1TB of traffic on Hetzner, incoming traffic is free. A 16core/64GB instance (m5.4xlarge) on AWS costs 360$ monthly, a tiny bit cheaper if you…

To be fair, you should probably account for one or two mirror servers on hetzner for easier, lower latency fail over in case of hw failure (assuming you're talking about dedicated servers, not hetzner cloud). Of course with eg three servers, you might load balance acccross most of those during normal load, just make sure to have enough capacity left over to run with N less servers while you spin up a replacement and/…

We are heavily invested in AWS. AWS is not cheaper, but it doesn't mean it's prohibitively expensive when you consider everything it offers. What people tend to ignore are the other things it offers. For example, the parent talks about data transfer costs, but that's just one aspect of cost.

The real big cost in any organization is head count. And while a load balancer is not difficult to setup and maintain the first time, managing it becomes time consuming in a large enough organization. Couple that with everything else...

If someone can replicate what AWS is doing at a lower cost, people would move to them. But there are few companies out there that come close. Bandwidth cost is generally not your biggest expense.

Re: Amazon’s Chips Threaten Intel

#304

Post by Symmetry » Tue, Dec 11, 2018, 5:53 PM UTC

bogomipz wrote: post #297

Symmetry wrote: post #255

Earlier quoted context omitted.

In theory, yes. In practice x86-64, while it was the right solution for the market, isn't a very efficient encoding and doesn't fit any more code in cache than pragmatic RISC designs like ARM. It still beats more purist RISC designs like MIPS but not by as much as pure x86 did. It would be easy to design a variable length encoding scheme that was self-synchronizing and played nicely with decoding multiple instruction…

>"It would be easy to design a variable length encoding scheme that was self-synchronizing and played nicely with decoding multiple instructions per clock." How might a self-synchronizing encoding scheme work? How could a decoder be divorced from the clock pulse? I am intrigued by this idea.

What I mean is self-synchronizing like UTF-8. For example the first bit of a byte being 1 if its the start of an instruction and 0 otherwise. Just enough to know where the instruction starts are without having to decode the instructions up to that point and so that a jump to an address that's the middle of an instruction can raise a fault. Checking the security of x86 executables can be hard sometimes because reading a string of instructions started from address FOO will give you a stream of innocuous instructions whereas reading starting at address FOO+1 will give you a different stream of instructions that does something malicious.

Re: Amazon’s Chips Threaten Intel

#305

Post by ryacko » Tue, Dec 11, 2018, 6:55 PM UTC

rbanffy wrote: post #154

ryacko wrote: post #137

Earlier quoted context omitted.

Performance competitive technology requires paying for its development. Electronics manufacturing is inherently heavy industry, nothing short of mandating FPGAs would tilt it any other way. The world we live in is built upon a series of choices, the most important of which is whether you take a higher paying job or building what you desire. There will always be a lag between the latest product, or in the case of Linu…

> nothing short of mandating FPGAs would tilt it any other way. I can think of multiple alternatives that could be taken in isolation or combined. - Regulating the market and splitting foundries from their IP developers (this may not even be necessary at this point) - Funding development of a rich set of public-domain IP that could be used to build a common standard platform - Direct all government purchases to be of…

The nature of competition requires an advantage of some kind, or advancement won’t be very fast. The limit to what I think the free market would allow would be the government splitting funding for research and for production, and for any contractor to fulfill production orders without paying for licenses.

It seems more likely that splitting foundries would be successful, with some sort of anti-trust mechanism to prevent a foundry and an IP developer from having too much favoritism (or advantage from scale).

Re: Amazon’s Chips Threaten Intel

#306

Post by Rafuino » Tue, Dec 11, 2018, 7:38 PM UTC

rbanffy wrote: post #162

Brybry wrote: post #96

Earlier quoted context omitted.

How is Intel dying? Losing a near monopoly is a far cry from dying. And Amazon's Graviton/armv8 chips aren't going to be competitive for many workloads. If you look up benchmarks you'll see they generally aren't competitive in terms of performance[1]. They'll only be competitive in terms of cost (and, generally, not even performance/cost). I'm personally pleased that there is more competition but I find that saying I…

And it sure doesn't help that Amazon won't be selling desktop PCs or on-prem servers anytime soon.

Well, they did announce Amazon Outpost as well...

Re: Amazon’s Chips Threaten Intel

#307

Post by stdplaceholder » Tue, Dec 11, 2018, 7:42 PM UTC

evancox100 wrote: post #280

stdplaceholder wrote: post #79

Earlier quoted context omitted.

I have not met anyone who deployed the new AMD stuff at scale and is happy with the outcome. The new architecture shines on small codes like SPEC and then falls apart in large, branchy, pointer-chasing codes that everyone runs in production. I would not say AMD is “in a great place” with their current product. They are putting slight pressure on Intel on the very low end and filling some very specialized niches but t…

Any public sources? Just curious

I don't think anyone has an incentive to release findings because that will just sour their future work with AMD and counteract any pricing concessions they are getting for waving the AMD platform around under Intel's noses. Same for POWER, for what that's worth.

Re: Amazon’s Chips Threaten Intel

#308

Post by zjaffee » Tue, Dec 11, 2018, 7:48 PM UTC

maddyboo wrote: post #94

Just yesterday, I was trying to explain to my partner (who isn't a programmer) why I think open source software and hardware is so important. My argument is that without enough core components in the industry standard tech stack being open source, the more likely companies who develop solutions will restrict user freedom. For example, Apple has been able to own nearly their entire iDevice stack from manufacturing to…

I have to disagree here, because the breakup of vertically integrated monopolies has been something that has been done by governments before. Entire components being open source certainly reduce the barrier for further closed source components, but we can develop open standards regulations that require certain middleware to be open and interoperable to prevent monopolization.

Re: Amazon’s Chips Threaten Intel

#309

Post by evancox100 » Tue, Dec 11, 2018, 7:51 PM UTC

erikpukinskis wrote: post #85

Apologies in advance for the layperson question: It's my understanding that a lot of CPU gains come from caching. That suggests to me that there is potential performance to be gained by caching across a larger number of machines. Is that something Amazon could do here? Somehow connect all their machines and cache in a huge space? Maybe individual physical machines would be more like a front end for a cache space, and…

Your idea is impractical from a "caching for performance" perspective, for the reasons other have pointed out.

However, there is work to enable multi-machine coherent memory. I just saw [1] today. This is kind of similar, you're giving a single, unified view to memory across multiple machines. But you do this to easily share data as part of a new programming paradigm, not to speed up your code.

https://www.westerndigital.com/company/newsroom/press-releas...

Re: Amazon’s Chips Threaten Intel

#310

Post by zjaffee » Tue, Dec 11, 2018, 7:55 PM UTC

rjzzleep wrote: post #180

greyskull wrote: post #149

Earlier quoted context omitted.

I started my professional career in AWS so I have zero experience in non-cloud businesses (i.e the vast majority of software jobs), but I always wonder about the cost argument people make against AWS (or any major cloud provider). It's very easy to overspend, sure. But say we're considering how well you execute in terms of picking the right tools for your case and utilizing the right cost saving measures. In the opti…

You can buy a 16-32 core machine with 64GB Ram for less than a hundred bucks on Hetzner. You can run SmartOS, proxmox, danubecloud or whatever other solution there, and for some of them you should be able to use terraform. There is a little extra upfront cost to set these things up, but once you have it, it's fine. You can do your zfs snapshots to hetzners backup infrastructure. A lot of people try to throw all their…

I have to say, you're completely overlooking why AWS/GCP/Azure are good services in your answer. The value add from using these services is that you don't have to know how to run any of these things, building an SRE/devops/sysadmin organization is non trivial for a team of developers with a background in application development. Spending an extra 100k a year on AWS is likely cheaper than the cost of building out a team to do all of these things for you, including as things scale.

If you're going to have a team of people deploying all of your own middleware software anyways on VMs, that completely defeats the cost savings from using cloud these days. It's much more of a PaaS business than a pure IaaS one.