2 ms·

Well this is just outright confusing. The scale that Intel operates at means this product is going to be a drop in the bucket in terms of revenue which makes th

Well this is just outright confusing. The scale that Intel operates at means this product is going to be a drop in the bucket in terms of revenue which makes their enormous investments in dGPUs look a little silly. It fits in this really weird place where you want a little bit of extra GPU power for co-processing, but really very little extra power. I literally can't understand how this product justified the engineering effort. Which leaves us with the fact that this must be a first release of something much more significant, which means that they've been forced to rush it out the door because their main effort is behind (well 'technically' we did ship the first series of chips in this project in Q42020). However, if you watch what happens a lot in Intel - they release a compromised first version of something, that ties them to a concrete failure (this isn't going to make any money) which then allows the executive team to can the project.

purplecats 6y ago
how often are you correct about your chain of reasonings as such? if it's non-negligible, would you mind sharing where I could read more of your ponderings? thanks.
- Traster 6y ago
  Well, on this particular topic, I used to work for Intel so a lot of it comes from knowledge of how the company works institutionally. It's difficult to explain to an outsider but Intel has this weird combination of making enormous bets but with an incredibly ossified corporate culture. So some project will get kicked off - they'll buy a company like Nervana or they'll hire in someone like Jim Keller and give them a mandate to go off and do something huge. The problem is how this intersects with the dynamics with the Intel organisation. Firstly, there's already five teams that already do whatever you want to do, so you go up the chain saying "I need 5 engineers to do X" and the answer comes back down the chain "Team Y already has 20 people, they do X, you should get them to do it". But so now rather than doing X, you're paying Team Y to do X, oh and Team Y doesn't give a shit about X, they care about Z, so about half your budget for X is now being subtly shifted to work on Z. So the cost of your project massively inflates. Oh, and because when your project was approved they canned something else, some senior executive is saying that half your headcount should be "internal transfers" so suddenly your project has to find work for 50 software engineers at Folsom who just finished working on Intel's Modem team (before that they worked on Intel's previous GPU team too before that got canned). Now comes the real issues, because you've got all these different teams that you rely on for your project and they don't answer to you, they answer to random different org structures, it's practically impossible to hold them accountable. Which leads to hilarious dynamics where team A will fall behind on their tasks, but they already know team B has fallen behind, so team A will lie about being able to deliver, because they know they'll never have to. So the critical path on your project isn't the team that's fallen behind, it's the team that's fallen behind and all the other teams that have made the calculated judgement your work can be deprioritized because team B will sink your project anyway. Finally comes the release. All of these internal fights don't change the fact that you're responsible for delivering a product to market, and almost certainly if it's an important project it'll be part of some Group's goals (like the Datacentre group or networking group). Now, the General Manager of the group isn't going to miss her/his goals. So you'll "ship" a product, by which we mean you'll send a handful of sample products to a partner. They probably wont work, they'll be a tiny subset of the functionality you originally promised. So anyway, that's the point at which someone realises we've just spent 10,000 years of engineering effort to deliver a discrete Graphics chip that is marginally less powerful than the integrated one. But the product is out there, so you've got sales data now and revenue. So you need to agree your roadmap for the future! But the first product was shit, and getting it into any sort of state to be competitive would be an enormous amount of work because it was compromised at every point, so no one will sign off on throwing good money after bad and so what happens? Nervana? Fuck you! We're betting on Habana Labs now!

purplecats 6y ago

how often are you correct about your chain of reasonings as such? if it's non-negligible, would you mind sharing where I could read more of your ponderings? thanks.

Traster 6y ago
Well, on this particular topic, I used to work for Intel so a lot of it comes from knowledge of how the company works institutionally. It's difficult to explain to an outsider but Intel has this weird combination of making enormous bets but with an incredibly ossified corporate culture. So some project will get kicked off - they'll buy a company like Nervana or they'll hire in someone like Jim Keller and give them a mandate to go off and do something huge. The problem is how this intersects with the dynamics with the Intel organisation. Firstly, there's already five teams that already do whatever you want to do, so you go up the chain saying "I need 5 engineers to do X" and the answer comes back down the chain "Team Y already has 20 people, they do X, you should get them to do it". But so now rather than doing X, you're paying Team Y to do X, oh and Team Y doesn't give a shit about X, they care about Z, so about half your budget for X is now being subtly shifted to work on Z. So the cost of your project massively inflates. Oh, and because when your project was approved they canned something else, some senior executive is saying that half your headcount should be "internal transfers" so suddenly your project has to find work for 50 software engineers at Folsom who just finished working on Intel's Modem team (before that they worked on Intel's previous GPU team too before that got canned). Now comes the real issues, because you've got all these different teams that you rely on for your project and they don't answer to you, they answer to random different org structures, it's practically impossible to hold them accountable. Which leads to hilarious dynamics where team A will fall behind on their tasks, but they already know team B has fallen behind, so team A will lie about being able to deliver, because they know they'll never have to. So the critical path on your project isn't the team that's fallen behind, it's the team that's fallen behind and all the other teams that have made the calculated judgement your work can be deprioritized because team B will sink your project anyway. Finally comes the release. All of these internal fights don't change the fact that you're responsible for delivering a product to market, and almost certainly if it's an important project it'll be part of some Group's goals (like the Datacentre group or networking group). Now, the General Manager of the group isn't going to miss her/his goals. So you'll "ship" a product, by which we mean you'll send a handful of sample products to a partner. They probably wont work, they'll be a tiny subset of the functionality you originally promised. So anyway, that's the point at which someone realises we've just spent 10,000 years of engineering effort to deliver a discrete Graphics chip that is marginally less powerful than the integrated one. But the product is out there, so you've got sales data now and revenue. So you need to agree your roadmap for the future! But the first product was shit, and getting it into any sort of state to be competitive would be an enormous amount of work because it was compromised at every point, so no one will sign off on throwing good money after bad and so what happens? Nervana? Fuck you! We're betting on Habana Labs now!