I think you can actually reduce the quality even more, that way we won't even see the screen.
Oct 25, 2006 at 12:17PMCharles, thanks a lot for again keeping us C++ developers in mind and talking about it in your interviews.
With all the buzz around C# and managed code I really feel left out!
Bobinho wrote:Thanks to [...] Charles for asking good questions.
I second that! Thanks a lot Charles for being the voice of us C++ guys. I must admit that I often feel left-out as a C++ developer (ie: the cool new features added to VB.Net, the lack of refactorings of C++ in VS2005, the modeling features of some VS editions, etc).
One interesting interview would be to ask some MS Games gurus and see what they have to say about game development (ie: big, AAA titles) and managed/C# code.
Is it feasible to use managed code in such a way that a game reaches the performance required to match, say, Half-Life?
It would be easy to say no outright, but if some clever people got together, I'm willing to bet something great could be done. Maybe games would take less time to build as there would be less bugs? Maybe?
Very nice video, Robert. Thanks!
I do agree that there wasn't nearly enough details on what makes the whole glitch resilience work, but it was still nice.
How about that neat stressing tool? Is it available anywhere? I could really use that while testing some of my apps. It is a MS tools or maybe available in the SDK? I couldn't find mention of it.
staceyw wrote:1) I missed a fundamental idea I think. It sound as if the last writer wins. So if I have an atomic block, I can make changes to state. But another thread can write to the state and commit, but the first atomic block will then rollback. What did I miss?
Your understanding sounds on par with mine, except that I don't see why the thread that commits its data wins and the other looses (except for the performance penalty).
If thread A tries to withdraw $100 from an account but there's no money in it, it retries which in effect puts it to sleep.
Then thread B comes along and credits $100 to the same account. Since no other threads are accessing that account, thread B can commit and continue its processing.
Then thread A wakes up since it detects a write to the account's memory and then retries the whole transaction which succeeds since the money is there.
Of course the thread that got into the retry state hits an additional performance penalty, but I think the whole idea of this system is to make things easier, not faster.
That sounds extremely powerful.
When you said the last writer wins, were you talking about performance?staceyw wrote:3) How does long running I/O and DB transactions play with this. So in a normal app, I would need both to be atomic. I need the in-memory objects to be atomic and the DB to be atomic in a single transaction. How does this work?
Yeah, there's still a lot of things that are still unknown.
In the debit/credit example, what if the money never gets deposited in the account? Does an atomic transaction has a timeout value? What if an atomic block triggers an external process of some kind by setting a property of an object?
I suppose there's a whole set of guidelines and restrictions we'd have to follow when using atomic blocks. Reading the papers available would surely answer most of the unknowns.
Another great one Charles. This is some pretty complex stuff to wrap your head around, and the bit about the garbage collector and all that's required to implement atomic transactions really went way over my head!
But I tell you, I wish I had this technology in the languages I use (C++ and Pascal) RIGHT NOW!
And Haskell is really getting some air time these days
I love C9 videos!
I'm trying to figure out how to spell the name of the programming Brian keeps mentionning, Askel, askl... What's the correct name?
Thanks Charles, what a great interview (again!). Boy, some people at Microsoft makes me feel so clueless! And that Timewarp OS stuff is one of the craziest thing I hear about.
PS: answering my own post: "Haskell"