Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

YOW! 2012: Martin Thompson - Mechanical Sympathy and High Performance Coding

Download

Right click “Save as…”

Martin Thompson is a high-performance and low-latency computing specialist, with experience gained over two decades working with large scale transactional and big-data domains, including automotive, gaming, financial, mobile, and content management. He believes Mechanical Sympathy - applying an understanding of the hardware to the creation of software - is fundamental to delivering elegant, high-performance, solutions.

Here, Martin explains his perspectives on high performance computing (and coding), when to go native versus managed (Can you really write super fast, highly machine-optimized code in Java and .NET? Martin does...). This is a long conversation and well worth your time if performant execution is important to you - yes, the irony of a long chat about highly performant computing doesn't escape me. Smiley

Given that this is a C9 conversation, we take various detours into more topics than the title suggests. Tune in.

Thanks, Martin, for taking the time to ride tandem with the random.

Tags:

Follow the Discussion

  • @Charles...No offense man, but you are really beating the sh*t out of this native thing. At this conference there were so many people there working on so many awesome things...and in each interview I've watched there's a big chunk of it where we get them talking about your latest thing instead of talking about their latest thing. Scoble used to do the same thing when he was at 9. ("River of news"...etc...My god that was painful.)

    Look man, I appreciate you getting these interviews in the first place. They are awesome. Thank you for doing them. I worked through SICP because of an interview you did with Dave Thomas.

    Maybe you could get someone at MS to actually do a series on "the machine" that you keep talking about. Instead of talking about whether native code is important do a series where someone demonstrates "getting close to the machine". When I was younger I did PIC programming with custom circuits and opcodes...as close as you can get...I promise there are more interesting things to talk about. In the interview with Dave...he mentions prototyping a device for the medical field...THATS INTERESTING. Hearing Martin talk about developers needing some kind of journeyman system...THATS INTERESTING. In fact, the area that this guy works in is remaking the entire stack that people are using...from the wire up. It would have been nice to hear more about that stuff...FPGA's, software defined networking, the limits of "speed" (optics vs electrical), fiber connections and co-location with trading floors...all kinds of things are happening in high frequency trading. It's actually the "big game hunting" of computing at the moment. Managed vs. native is just about the least interesting aspect of any of it.

     

     

  • CharlesCharles Welcome Change

    @B3NT_0: Thanks for the feedback. I know I've been pushing the native thing a bit hard, but there is still confusion to be addressed.

    Behind the scenes, at YOW! there were several conversations had with some speakers about native code and performance, questioning if the tool really matters, but more so the implementation of the tool (As I wrote in the description, Martin does high performance computing tasks in Java, with speeds that rival C...). Martin has some compelling views on the native versus managed topic, so we spent some amount of time talking about it. Most of the discussion is not focused on this topic.

    I'll take you to task and see if I can find some folks in MSR to talk to about the machine, in this context. That's a good idea.

    C

  • Very interesting discussion about a lot of things, and I loved the Jackie Stewart reference.  Oh boy does the very last minute of the talk ring true.

    However, it seems Martin has missed the last 10 years or so of what's happened in C++ and I had a few bones of contention about the first 20 minutes:

    I think it's a mistake to worry about only the "hot" code in your programme.  The rest of the programme will still compromise overall performance, by holding up your hot code or blowing away its cache (hello garbage collector).  Also, everything adds up in a large application, especially these days where programmers tend to glue together a lot of existing functionality.

    There are several points to make about Martin's claim that a JIT can optimise to the current architecture (like the count leading zeroes example, or vectorisation):
    - First of all I have my doubts that JITs can actually do this that well, it just strikes me as a theoretical argument ("Well, in principle, a JIT could ...").  But if a JIT can do it efficiently to bytecode, then so can microcode to an instruction set.  We'll see, we are talking about code that we write today to run on machines tomorrow.
    - You don't have to target a particular architecture (SSEn, AVXn), you can check which instructions are supported at run time and branch appropriately.  In fact the compiler might even do that for you (but check first).
    - If you "compile a binary and sell it as a product", these days with automatic online updates a customer can have the latest and greatest most efficient code for their system, if it matters that much.
    - The example of code that is vectorised most successfully, memcpy, is telling.  It doesn't even apply to nicely written C/C++, you only need memcpy if you have have constraints like immutable strings.
    - Yes a JIT compiler of an intrepreted/managed code can make decisions about optimisation at run-time, but so can profile-guided optimisation.

    Regarding the dropping into C in sensitive parts of a C++ programme because virtual functions ("polymorphic dispatch") are marginally slower than static dispatch, a good C++ coder should be able to use templates to implement so-called static polymorphism.  These function calls even have a good chance of being inlined.  Good C++ written like these is faster than straight C (doesn't have to use function pointers).

    Just holding up the native code end!

  • CharlesCharles Welcome Change

    @TheMagnum: Thank you. This conversation will spawn conversation. That's the making of a good conversation.

    There is much more to the debate and we should continue to discuss these important topics. I for one appreciate your feedback and will work to ensure the right native positioning is always present in these types of conversations (this means having other people besides myself present and in frame - that's coming...). I'm a generalist and best at moderating conversations versus taking a side and playing the role of expert.

    C

  • IvanIvan

    @Charles
    first of all I think the first comment is a bit harsh, but I do feel that somethimes your questions arent really questions and are a bit to vague/not question at all so it is confusing for the person being interviewed. Maybe you could write down a couple of questions before interview so you dont need to think about them while you are asking them.
    Also regarding JVM vs compiler - you could have asked him if JVM really does those nice optimization things or "it is in theory". AFAIK Cliff Click said that modern JVMs are pretty much like profile guided optimization in native code. :D
    Other that that there is a bunch of cool questions you could have asked Martin:
    1) what do you feel about people who say skip C++, do 99% of the app in C#/Java, and perf part in pure C.
    2) regarding GPGPU it is mostly high latency high throughput solution. In your job do you see more requirement for massive data processing or for low latency.
    3) Alexandrescu said that it is easier to write code in C#/Java than in C++ but that it is easier to writer performance code in C++ than in managed languages...
    4) what about exceptions in low latency code? Are they no go?
    5) did you encounter any Haskell in the real world, if yes tell us your feelings about it.
    6) regarding VM example... how do you know that there is a performance to be extracted. Do you just try, or it is matter of experience, or some approximate calculation... I mean VM example is interesting since it is not just run the profiler... aha, bottleneck is here.
    7) Do you have an opinion on StackX classes in C++? (LLVM project has them) Basically they are fat on stack in a sense that they hold up to n(template param) items inside before they need to do heap allocation.
    ...
    All this being said Charles you rock(I remember once asking a question in comments about AMP and almost randomly couple of months later Im watching a C9 video where you ask K. Gregory that question).
    Just please dont focus too much on native vs managed. (you could compile Java to x64, so what...) Focus on what herb likes to call tradeoffs - managed prioritize productivity when it is in direct conflict with perf, C++ prioritizes perf.

  • CharlesCharles Welcome Change

    @Ivan: Thanks, Ivan. In retrospect, I agree that I could have done a much better job in this interview. Certainly, having Martin's undivided attention for a long time, I could have asked him much better questions. Sometimes, when doing so many interviews, I lose my edge. Also, in this case, there were a number of off-camera debates I was a part of (with people much smarter and more knowledgeable than myself...) focused on native versus managed and what native really means, in general. I guess my limited mind was too taxed.

    If only I would have had my camera to film a conversation Martin and I had while drinking Smiley

    I appreciate all the feedback and will act on it. I do know that sometimes I am bit heavy handed when it comes to native. No excuses. This wasn't my best interview (as in my side of the conversation, not Martin's - he did great, just like he always does). I have a feeling I'll see Martin again and will do better next time when I get the chance to geek out with him. He's done some amazing work (in Java, C#, C/C++). That's where the focus needs to be.

  • JedrekJedrek

    By using abstract languages
    it is possible to write
    the following program:

    ---------------------------
    "I need a 'Hello, world' program by this afternoon."
    ---------------------------

    It is possible to get the same results
    in lower level programming languages
    but the program will be much longer.
    So there are some disadvantages of using
    assembler and machine code for everything.

  • CharlesCharles Welcome Change

    @Jedrek: True story. There are several disadvantages to using one tool chain for everything. It's not a good idea to have only one tool in your coding arsenal. You build systems of systems, after all.

    There's certainly always a right tool for some specific job... Here, the topic is writing software for high performance computing. Abstraction, or mean distance from the code you write to the cpu and gpu that realize it, is certainly worth discussing. As I said, I could have done better with my part of the conversation.

    C

  • I do agree with the first post, but then everyone does have a personal bias depending on their own experiences and background.

    I did find this interview to be one of the best lately (there's been a few good ones to come out of YOW). It was quite refreshing to see someone talk about getting back to the machine instead of the current trend of high level abstractions (not many can explain how Linq works), horizontal cloud scaling before even investigating how far you can scale up first.

    As a developer with a passion for writing good code to keep things both managable and fast, I want to see more like this. You don't need to go native to get good performance out of software, just don't create a billion objects and expect a smooth ride. Big Smile

    I wish I was a fly on the wall to see those off camera debates, they sound interesting!

  • @Charles

    Hey. I wanted to apologize. My post was harsh. Unnecessarily so...I thoroughly enjoy your work on Channel 9. These talks are great and I have learned a lot from them. Of course, I, and probably every other nerd on the planet, start thinking that I could do a better job at everything...really a sh1te attitude. I could have put my criticisms differently. Too often, we just let loose on the internet...and I wouldn't speak to someone that way in person...well, I do but I can be a real *. Anyway, channel 9 is great. Thanks.

     

    PS -- If you are interested in "getting close to the machine" I would recommend a book on "Modern C"...It's called

    "21st Century C: C Tips from the New School" by Ben Klemens.
     
    It's an O'Reilly book...I think that you will be surprised by the way that it sounds like the C++ stuff that you have been talking about...only simpler. There's something to argue about!
  • CharlesCharles Welcome Change

    @B3NT_0: No worries. I always appreciate honesty over style. You just expressed a natural reaction. I, too, can come across as hostile or angry even when I'm actually feeling neither emotion.

    Will check out the book. Thanks.

    C

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.