5 ms·
I'm willing to credit this type of feature creep for some of the problem, but only some. Decades ago, we had hardware that was so much less capable than anythi
by amluto 4y ago
I'm willing to credit this type of feature creep for some of the problem, but only some.
Decades ago, we had hardware that was so much less capable than anything anyone has put in a car in ten years that the comparison is absurd. Nonetheless, those old systems were often very capable of doing useful things, and the UIs were often very, very fast by modern standards. And a lot of this was that the software stack was tuned for performance and latency and did not do things that hurt latency too much, and this came at a substantial modularity cost.
Back when a TI calculator with a whole OS running on a Z80 was an order of magnitude or so faster than your average new car, it didn't have a compositor (which still eats a good frame or so of latency, maybe more, and, as an industry we still don't know how to solve this). It ran an OS that was surely far harder to tweak than a modern car stack, but it had fewer layers and could be kept performant. An Apple ][ and its clones were, of course, much faster than a TI calculator, and we still can't match that level of performance.
A group of engineers that were willing to keep the managers away and make a simple, limited-purpose system, could surely get excellent performance out of any currently available car computer hardware, but it would come at a cost. Buzzwords would not happen :) Also, the software developers had access to full data sheets for the hardware, and when you told the hardware to put something in its framebuffer, it was there, and no blobs or firmware were in the middle.
I still remember when Windows 2000 launched with "layered windows": an application could opt in to being composited, and it would gain the ability to be translucent, but it came at a very obvious performance cost. Sadly, 23 years later, that performance cost is still there, but it's not opt-in any more.
- klodolph 4y agoThe kind of development you’re describing happens in aerospace. I know some people who work in aerospace. They’re not any smarter than the people who work in automotive, but the people in aerospace have a much higher tolerance for dealing with bureaucracy, and management is much happier to get something less impressive but reliable.
- DanielHB 4y agoautomative main problem is the constant push to cut costs which leads to worse SoC being shipped. Aerospace profit margins are much higher (or don't matter for gov programs) so they don't need to cut costs that much on computer hardware > management is much happier to get something less impressive but reliable. ^ this is accurate though. Management wants bells and whistles (animations) which are hard to build without abstraction layers
- nyanpasu64 4y agoEven as someone who believes in the indefensible bloat of modern software, I'd say TI-OS on my 84+ (from using it in high school and college several years ago) is not exactly the fastest to use: - Graphing a plot was slow due to slow CPU and high-precision math libraries (could take 3-10 seconds depending on function complexity and detail) - MathPrint mode slows down printing expressions to an extent, IIRC even moving the cursor through history felt sluggish. - The B&W LCD screen with slow color transitions adds more latency than a compositor does. - Garbage collecting the flash memory could take dozens (IIRC) of seconds, and would happen unannounced when manipulating saved programs (IIRC not in regular calculations).
- stonogo 4y agoI beat Doom on a TI-84. I'm not sure I buy this.
- onion2k 4y agoDoom does very little work to draw each frame. It does a handful of small calculations to update the game state, and then traverses a BSP tree and draws some vertical blocks for walls followed by a flood fill for the floor and ceiling (although I suspect that was missing on the TI-84 ports because filling is slow). Calculating and drawing a complex graph often requires far more operations.
- Lio 4y agoThat's what's wonderful about Doom. The simplicity of what it does belies the effort put into achieving that on limited hardware. When it come out it was mind blowing and I think it's a testament to what can be done when people actually care about the product. I suspect the issue with software for consumer goods in general is a stake holder/project management one and not software engineering. If the stake holder cares more about a tick list of features than how well the features work there's not much the engineer can do. In my experience stake holders are often much more interested in their burn down graphs and Gantt charts than in getting a really polished core which could later scale quickly with just config. You need a product owner with real vision and understanding of what good looks like. It's almost a cliche now to reference Steve Jobs but he really did get that a few really excellent features are better than a laundry list of stuff that sucks.
- airtonix 4y ago[dead]
- DanielHB 4y agoif you make the UI software more performant the sourcing team just picks a cheaper SoC in order to cut costs. There is little incentive to bend your ass backwards to make performant software when cutting SoC costs doesn't come up on your team's KPIs for upper management
- barrkel 4y agoI guess that's why you only remove the delay loop just before shipping.
- john_the_writer 4y agoFeature flag it :)
- hulitu 4y agoThe automotive's industry answer to safety and security is complexity. And it is only getting worse.