You're probably right, although "embedded" is not automatically equal to "real fast" either. The thing is, he didn't say. It's not clear whether he (or his company) has spec'd out their performance requirements. Reading his description, it seemed like he'd made an assumption about said requirements. So what I really wanted to say was that, if that's the case, he should validate his assumptions.
I guess I didn't say that very well. Plus you could argue that I made an assumption about his making an assumption. Am I having a bad day?
In every embedded app I've worked on, the performance requirement was "fast enough to meet the spec" and not "as fast as possible." Or as my senior project advisor insisted, "real time" != "real fast."
Real engineers benchmark, either in simulation or the lab. Unless you can prove in advance that a usermode driver will fail to meet the needed performance, write one and see how close you get. Depending on your app, you could find that even in usermode you've got time to spare.
In other words, solve the technical issues first, because you might find that the other stuff becomes non-issues.
Slashdot Mirror
You're probably right, although "embedded" is not automatically equal to "real fast" either. The thing is, he didn't say. It's not clear whether he (or his company) has spec'd out their performance requirements. Reading his description, it seemed like he'd made an assumption about said requirements. So what I really wanted to say was that, if that's the case, he should validate his assumptions.
I guess I didn't say that very well. Plus you could argue that I made an assumption about his making an assumption. Am I having a bad day?
-cb
In every embedded app I've worked on, the performance requirement was "fast enough to meet the spec" and not "as fast as possible." Or as my senior project advisor insisted, "real time" != "real fast."
Real engineers benchmark, either in simulation or the lab. Unless you can prove in advance that a usermode driver will fail to meet the needed performance, write one and see how close you get. Depending on your app, you could find that even in usermode you've got time to spare.
In other words, solve the technical issues first, because you might find that the other stuff becomes non-issues.
-cb