So NDP is essentially what Commodore did with their 1541 disk drive. That disk drive had a 6502 in there to complement the 6502 in the actual VIC-20.
From what I remember, the IBM System Z mainframes also do this sort of thing and have dedicated IO processors that can decode XML on the fly for you and other fun things like that.
I worked a compiler backend for 5 years. Despite the insane amount of testing, fuzzing, standards tests, etc that we did, there were always bugs coming in, and not always in code that looked dodgy. Sometimes an optimization interacts with another in JUST the right way to cause incorrect code to get generated.
Honestly, I'm surprised that I haven't run into more of them in the wild.
Opel is owned by GM (well, until March 2017). You're actually driving an American car. Assuming the 2015 and up model year it's platform sharing with the Buick Verano. The big difference here is that your engine is a diesel, and that makes a big difference in city driving when you're idling a lot.
If memory usage matters to you, have you tried telling the JVM not to use all the memory? Have you tried any of the tuning options? Can't say I've ever used app engine, but the pure java applications I've worked on did in fact use a fair bit of memory, much like windows and OSX will aggressively use spare memory for caching. Then I use -Xmx to tell it not to use all the memory and now it's much better. For a server, I'd say that this is both expected and the correct behaviour.
While I really do like this article and the really interesting techniques it showed me, I'm bothered by the fact that they constantly mention performance but there's not a single benchmark on that page. It's not that I don't believe that these are huge theoretical gains, it's just that I'd like to see how these perform in practice compared to other approaches.
I agree, it would be interesting to see. I'd also like to see it handle driving in both a heavy snow winter, like Calgary, and also a muddy brown snow winter, like in Ottawa. I feel like for a long time self driving cars won't be able to handle unplowed streets and will have to get the human to do anything truly difficult.
Big O isn't fooling you, it's giving you a one-function explanation of how the algorithm runs on an idealized system as the size of the problem increases. There's other systems you can simulate for big O, but the math is much harder and you wouldn't generally use it unless you're doing something complex like a cache-oblivious algorithm.
If you're using solely big O to decide on an algorithm, you're fooling yourself. If performance is an issue, profile, benchmark, study, don't guess.
That doesn't really answer the issue, or the question. How are we supposed to get in touch when things go wrong? The blog post clearly showed that support was an afterthought and not properly QA'd.
This is especially true if you've got large smooth curves with small "sharp" curves that you want to keep a constant speed over. You can mostly just ignore it if all of your curves have a fairly constant curvature, but obviously test first.
I only really found out how easy and fast Bezier curves are recently when I was adding some smoothing pathing to a game. They're really impressively useful.
I've worked on the compilers for Z systems and on the z/PDT emulator that someone else mentioned. The processors they run are indeed monsters. The instruction set is especially interesting as you can see the transition from 24-31-64 bit. Messing around with the SAM (set address mode) instructions was always fun. They also have some interesting interruptable instructions that can move or compare up to 2GB of memory.
Interesting technology, and it'll be fun to see how they market the technology since people just started understanding that incandescent = lots of energy = money. I wonder if LED technology will be able to keep up.
This tool is also great for verifying that you've built you APK correctly. I just used it for the past week diagnosing some issues with building an APK with Unity. It was invaluable.
That's correct, however that would involve some branching. In theory you could do a bit masking trick to use the same code, but that would end up much more complicated and slower than the presented eor hack. That being said, I'm pretty sure that your idea could easily be done on a more modern processor.