> a new architecture that could in one fell swoop kill off the general purpose processor as a concept and the X86 instruction set as the foundation of modern computing.
Do you want me to think you're a credulous idiot? Because this is how you acheive that.
Okay, so laying aside the bizarrely stereotypical tech journalism. From what I understand there are a number of problems with this that need addressing:
If you create a custom compute unit layout for a specific data flow diagram it's very difficult to identify which layout is most efficient, and then when you want to optimize for higher performance it's almost impossible - because you don't know what you're targetting. It may be your optimization pushes your design to a different layout completely and all the cost functions are impossible to know. You end up with too many free variables to optimize for. We're very good at taking a fixed design like a CPU and then taking a program and jamming it in to that paradigm.
The second problem is that either you need 1 architecture that will dynamically reconfigure to different graphs or you needs lots of architectures. They seem to be going for the 'Spin 100 designs' path -so firstly, how is a customer meant to know which of those designs to actually buy, what happens if their design evolves from 1 design to another? Secondly, how is this cost effective? There's a good reason why Intel only spins a handful of designs per CPU generation.
The third problem is that if you have a custom compute unit layout and your program doesn't fit to it well it's not like a CPU. You can't re-order operations to maximally use the units, the bits that aren't useful are just dead silicon - and from history it seems like the killer is that dead silicon tends to be a LOT of silicon for any given program.
To be honest, this is a very well understood problem, and there are good reasons why it hasn't worked so far, and this article doesn't really give us any information on why it would work this time.
> it's very difficult to identify which layout is most efficient
Don't worry. The compiler will figure it out. And this time the compiler will have AI™.
> the killer is that dead silicon tends to be a LOT of silicon for any given program
Part of the idea here is that the cost dynamic has changed. Silicon is cheap compared to power so even if you have lots of chips not being used at any given time as long as they can be fully powered off total system cost (capex+opex) is still better.
> why it would work this time
The difference is scale. If you are running millions of CPUs and adding 100k's per month then something like this could work, assuming the AI™ magic that figures out which new chips to build.
The physical technology is real and probably coming soon but it will be limited to incremental improvements to the existing CPU/GPU compute architecture from increasing bandwidth and decreasing latency until the magic compilers arrive.
If I'm understanding you right, what you're suggesting is that the individual silicon modules will be fixed, but they will be contected in a single package in lot's of different ways.
If that's correct I'd love to see the cost of making the trip between the modules. I've got to imagine the cost of that is just huge. The interconnect is also crazy - it's easy to do complex routing tasks on silicon at high performance. I don't know how you acheive that in a scalable fashion between silicon.
I use iTerm2 all the term and I can honestly say I've never given a second thought to responsiveness. What are you noticing specifically? Are you typing super fast?
I think if you look at the incentives in that situation it's very understandable to not speak out. If you're a good employee working at Riot and you have a problem with the culture you have two options: Speak out or leave. If you speak out it can be incredibly damaging, you'll almost certainly destroy your career at riot because you'll be actively attacking people you work with. You stand a good chance of getting a reputation in the industry. The likelihood of changing the culture is microscopic - especially if you find out it's the CEO providing the lead in this behaviour. And if you succeed? Your career at Riot is still probably damaged, Riot's culture will be like any of the many other companies you could work at. During the time you're fighting for that change it's likely to be incredibly emotionally draining and you're bound to lose some friends.
If you leave, you have literally none of those downsides, you've still got a good career and you can go off to one of the many other companies that are just as successful without those downsides.
So to speak up you need to be incredibly principled AND you have to have some very deep stake in making THIS particular multinational corporation better. I think it makes perfect sense not to speak out for the vast majority of people.
While I think it's understandable when people don't speak out, I don't agree that those are the only two options. The small stuff Barry did is meaningful:
"My personal preference was to respond with clarifying language while addressing them by their first name, and convey 'can we just get through the conversation we need to have' non-verbally with my facial expressions and gestures..."
Not everyone has to be a leader like Barry, and not everyone feels the same degree of urgency about these issues. But to feel at peace with yourself, it's worth it to at least not actively participate and perhaps to push (however gently) in the right direction.
Well let's be clear - Barry is a product manager. It's not really his area of expertise to change an entire culture, and arguably it shouldn't have been his problem. So it's hard to criticize him for his attempts to improve their culture. At the end of the day though - once he found out the culture was taking its lead from the founder & CEO you kind of know you just have to get out of there. There's nothing a product manager is going to be able to do to improve the culture whilst there are senior people in the organisation propagating it.
Part of the point here is that you can run a secure store with quality controlled apps by charging companies to appear in the App Store.
That charge cannot POSSIBLY be 30% of sales. Not least because the cost of checking the apps that go into the App store is not in any way related to the revenue the app generates.
The charges for appearing in the store come from Google (a monopoly in the smartphone market in most places) rent-seeking.
> Sure, it provides extra security, but at a heavy cost.
There is nothing stopping Google and Apple charging a fixed fee for the cost of verifying the quality of submissions to the App store. The 30% is just pure rent-seeking, and frankly now it's monopolistic on Google's side.
You don't just get rid of the founder and CEO for shits and giggles. I'd love to know what it was that prompted this, although I'm not sure if we'll ever find out.
Since he doesn't claim to know why, by far the most likely reason is that they don't believe he has what it takes to take the company further, whether technically or in terms of management or industry experience.
Well he says he doesn't know why, but that seems disingenuous. If they had said they don't have confidence in his abilities to take the company forward that would be a reason - he could disagree but he would absolutely know why. So either they genuinely didn't tell him - which indicates it's something they think would cause trouble, or he does know why but won't tell us.
The key is that if your design goals are ambitious but achievable then you end up with a killer product. If your design goals are unrealistic or unachievable you tank what's achievable chasing a dream. Being frank the difference is probably that Steve Jobs had 30 years being a hands on expert in his field, and this guy was just some bloke who fancied building a self driving car.
All too often I've seen people set design goals when they don't understand the underlying problem. If jobs had targeted building an iPod that was physically smaller than the current smallest hard disk available he'd have been in this position.
It's remarkable how little we've seen from that acquisition. It's perfectly possible that Intel has butchered the acquisition the same way they have with many others.
The two huge companies being merged is more often considered fail than otherwise.
> a 2004 study by Bain & Company found that 70 percent of mergers failed to increase shareholder value. More recently, a 2007 study by Hay Group and the Sorbonne found that more than 90 percent of mergers in Europe fail to reach financial goals.
Especially when the merge should be deep and involve engineering teams with different cultures to join and work together on the product. So I'd consider the release of first Xeon+FPGA after 3 years past acquisition as a somewhat success.
Computer hardware has a very long lead time between product concept and metal-in-your-hand. Combined with the pains and huge initial slowdown of a megacorp purchasing a medium-corp, I think the real fruits of that acquisition are yet to be seen. I bet it took at least a year just for management to get their bearings on straight.
I would have guessed additional lead time for Altera to move their designs from TSMC to Intel process, but it looks like Altera has been planning to fab on Intels 14nm since 2013[0].
The first is that self-driving is super difficult, they don't really have the expertise, and a lot of their progress seems to have come from being able disregard proper safety procedures. So to move forward with it they'd need to fess up to investors that it'll take much longer than anticipated and it'll be much more expensive. That'll damage the company value significantly, and it's not really relevant to what the core of the business is doing right now. I actually find it fascinating - Uber has built an app that disrupts the traditional taxi marketplace. Separate to that they've got a division working on a produce to disrupt Uber's current market place.
The second problem is that if they choose not to do autonomous driving their entire business proposition needs re-establishing. Can they actually make money doing what they're currently doing? Or are they doomed to sink huge venture capital sums into acquiring market shares, only to fail to reach a dominant enough position to actually raise prices and make bank. And part two to that question: Can they achieve that profitability and a good enough return to be worthwhile for investors before someone who does succeed in disrupting the taxi business with self-driving cars.
>> Uber first made its interest in self-driving cars public when it hired about 40 researchers and scientists from the National Robotics Engineering Center at Carnegie Mellon University in 2015.
It doesn't sound like "they don't really have the expertise" (per your comment).
Perhaps autonomous driving is even harder than press releases from other, more cautious companies, have led us to believe?
One problem I can see is that they're trying to implement autonomous cars too fast, and secondarily they're trying to replace Uber X with them. If they treated auto-cars the same way they treated Uber Black, and make it a more luxury choice with a higher price, they could slowly implement this into their business over time, one car at a time. I personally would pay more for an auto-car. But the big crux is your first point, and the solution in my mind is for them to just be way way slower and ensure full safety precautions. I don't think they have to dismantle the division nor do I think autonomous cars are out of the realm of possibility.
I mean if the data says they're safer on average, I'd pay a bit more? And it'd do away with loud blasting of the driver's favorite genre in the car, turning off the AC and rolling down the windows when I'd prefer it on, aggressive acceleration, etc. that you see with some UberX drivers.
They've allowed (or even actively encouraged) this narrative to develop around how they'll make money as soon as they have self-driving cars. This requires not just the availability of self-driving on some small scale in specific places or along part of a driving route but broad availability in urban areas where a lot of people live (i.e. where self-driving is especially difficult).
Admitting the tech is a ways out means either 1.) Admitting that they have no idea how they're going to make money or 2.) Admitting that they're going to have to significantly raise prices to both improve per-mile profitability and cover the inevitable associated volume dropoff.
The only real explanation I have for why Uber hasn't accepted the inevitable and jacked up rates is that so many people are feeding at the trough no one wants to be the one to admit that the emperor has no clothes and there's no magic fix for making money at the current rate structure.
Do you want me to think you're a credulous idiot? Because this is how you acheive that.
Okay, so laying aside the bizarrely stereotypical tech journalism. From what I understand there are a number of problems with this that need addressing:
If you create a custom compute unit layout for a specific data flow diagram it's very difficult to identify which layout is most efficient, and then when you want to optimize for higher performance it's almost impossible - because you don't know what you're targetting. It may be your optimization pushes your design to a different layout completely and all the cost functions are impossible to know. You end up with too many free variables to optimize for. We're very good at taking a fixed design like a CPU and then taking a program and jamming it in to that paradigm.
The second problem is that either you need 1 architecture that will dynamically reconfigure to different graphs or you needs lots of architectures. They seem to be going for the 'Spin 100 designs' path -so firstly, how is a customer meant to know which of those designs to actually buy, what happens if their design evolves from 1 design to another? Secondly, how is this cost effective? There's a good reason why Intel only spins a handful of designs per CPU generation.
The third problem is that if you have a custom compute unit layout and your program doesn't fit to it well it's not like a CPU. You can't re-order operations to maximally use the units, the bits that aren't useful are just dead silicon - and from history it seems like the killer is that dead silicon tends to be a LOT of silicon for any given program.
To be honest, this is a very well understood problem, and there are good reasons why it hasn't worked so far, and this article doesn't really give us any information on why it would work this time.