shriver

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.

> 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.

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.

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.

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.

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.

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.

Uber seem to have two really key problems:

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.

That's impressive, but I don't really have any use for a 5 Watt CPU. I've literally just pulled the trigger on moving to a 15inch MBP because of the 47 watt TDP of the parts. The challenge for ARM is crawling up to 45W, 65W, 90W, 150W performance. Hitting performance targets at the 5W is great for Mobile CPUs, but it sort of belies the fact that they're not ready to play in the real laptop market yet. Looks like it'll be chromebooks for the foreseeable future. I certainly don't see Apple being able to offer anything compelling with this.

I think when you look back at the pedo comments, and the market manipulation tweets you can easily see him as being in the middle of the breakdown. The question isn't whether he'll break down, but what his next outlandish fuck up will be and how far it'll go before someone steps in.

> Efforts are underway to find a No. 2 executive to help take some of the pressure off Mr. Musk, people briefed on the search said.

I don't know how anyone could read this and not realise that's a direct search for a replacement CEO. With the best will in the world, Musk has a dozen people at Tesla who COULD pick up some of the slack, the issue isn't not having the right people, the issue is that he won't hand anything off. I don't see that changing.

That's actually incredibly complex - generally the way the revenue model works is that the Movie company will negotiate a certain percentage that depends on how old the movie is. So in opening weekend 100% of the revenue is probably going to the movie, but 4 weeks in the theater is probably taking 90% of the revenue. So yes, if you can fill those empty seats in the 4 week old showing you can make bank. But MoviePass has no mechanism for increasing sales of 4 week old movies particularly, they're just as likely to canabalize your existing week 1 sales.

Now I don't know what the Australian system is like but in the UK we have an insurance company from whom you can get 2-4-1 vouchers every tuesday if you're a subscriber. Well that solves the exact problem you're talking about - it incentivizes people to buy the tickets that don't normally get filled, whilst not providing any discount during premium times.

Well last time I looked, the answer to question 1 for the Intel OpenCL SDK is actually no.

And while yes, it's expected to be slow compared to the native functions, that's not the problem. It's slow compared to simulation.

Again though - these aren't things imposed by the markets. Time and again these impositions are imposed by Musk himself. He set the 5,000 car per week target, he missed it. The markets reacted when he set it, and they reacted every time he missed it. He also made the public statements about being cash flow positive and about taking on more debt.

If you look at the real market the trend is clear: There has never in the history of the stock market ever been a time when investors were more willing to invest in money-losing companies to gamble on them hitting it big. Tesla is valued by the stock market as twice as valuable as the Ford Motor Company.

While I agree with you that software projects aren't unique in having difficulty trying to estimate things, I think that emotionally it's different. If you're digging a tunnel and hit a seam of unobtanium you can go to your boss and point at the seam and say 'Look at this big rock - this big rock is very hard, we had no way of knowing it was here but now we know we have a problem". That is very different from going to your boss and saying "You know I was working on X, well X is harder than I thought, it's going to take longer". Well - is X harder? Or are you just slacking off? Or maybe you just took a stupid approach?

It's much more difficult to actually confirm that the cause of the delay is an external factor, rather than a reflection of the person doing the work since most likely the only person with a real understanding of exactly why something is difficult is the person doing the work. So there's a stigma attached that isn't present in other professions.

Actually it's not as clear cut as you'd expect. Obviously you can't represent every number in floating point, so you have to choose a way to round numbers - and for simple operations like add you can correctly round the results. For transcendental operations like x^y it's actually unknown how many resources you'd need to correctly calculate x^y for every valid value of x and y[1]. So since you can't calculate these numbers to correct rounding, you have to choose a level of rounding for your approximation - like 3 units of least precision rounding at the output. Of course we all need to know how accurate these are - so the OpenCL standard specifies it[2] - exp requires being correct to 3ULPs for single/double and 2ULPs for half.

Now if you have 3 ULP to play with, the maker of an Intel CPU is going to design an exp instruction to best make use of the existing Intel functional units. But an Intel FPGA dev is going to design an exp instruction to best make use of Lookup Tables and 18x18 multiplies - because that's what they have on the FPGA.

So whilst you'll get the same answer for x^y on Intel CPU and Intel FPGA within 3 ULPs those rounding errors are going to be different between the two architectures. So now, if you want to compute a normal distribution on Intel FPGA vs CPU you'll get 3 ULPs in your exponent, but that'll carry forward into the rest of the equation.

So now you have a choice - do you use the built-in function for exp on the Intel CPU - which is OpenCL compliant just like the FPGA, and get unknown rounding errors in what is probably a mathematically sensitive task, or do you emulate the actual sub-operations the FPGA does? In which case your hardy RTL designer who wrote that exponent function RTL is going to have to write an implementation in C that emulates the hardware. Oh and they don't only have to do that for exp - they have to do that for 100s of mathematical functions, and it'll run dog slow on the CPU compared to using the native functions.

[1]https://en.wikipedia.org/wiki/Rounding#Table-maker's_dilemma

[2]https://www.khronos.org/registry/OpenCL/specs/opencl-2.1-env...

There are a number of real issues with the emulation approach even now. Firstly, emulation isn't accurate - if you do floating point math in your application it will give you different results (within the tolerances of the OpenCL spec) on FPGA vs. CPU. So you can't test for correctness in the emulator.

A second more serious issue is that getting performance that justifies using an FPGA requires tuning very carefully to the architecture. This may mean adopting pipeline architectures that destroy emulator performance (there's still issues with the emulator identifying that the design patterns for shift registers in FPGA look like pointer fun on CPU rather than mammoth memcpys). So for a huge part of the design stage the emulator is basically useless- because it tells you nothing about what you care about, since the performance of the emulator is often negatively correlated with performance on FPGA. This is made worse if you're doing hardcore FPGA tricks like mixed precision arithmetic.

As you say though - the fact that timing is lost in the emulator also means you don't get a true idea of whether you have buffer overflows etc or lock-up. Adding debug into the actual design impacts the implementation on FPGA in a way that it doesn't for software - and is sometimes unintuitive.

> To be clear, when I made the public announcement, just as with this blog post and all other discussions I have had on this topic, I am speaking for myself as a potential bidder for Tesla.

Elon Musk sent an e-mail to all his employees on August 7th, and published the e-mail to the world. In the e-mail he made a number of quite worrying statements as the CEO of the company and some outlandish claims. One week later on August 13th, Elon Musk rips off his mask and cackles manically: Behold! It was me all along! Not the mild mannered CEO of your heart, but I have been secretly talking as a potential bidder for your company! Moohahaha.

I wish I were as optimistic about Musk as you are. This seems a lot like a convenient re-imagining of the conversations he had to try and persuade people that he wasn't deliberately manipulating a short-squeeze. He's just some country bumpkin who don't understand these fancy contracts those city types insist on, he had a conversation and a hand shake and that's all he needs.

That's not the endorsement. The endorsement is that it's okay for a single product to be suboptimal as long as the system is optimal. It's more optimal to prevent or slow down a number of innovations in order to protect the vast majority of people from the sort of mistakes and scams that other industries accept as standard.