C++ AMP: The Test Team - Hallway Office Tour

Posted: Feb 24, 2012 at 9:37 AM

By: Charles

(1)

55,372 Views

6 Comments

46 minutes, 43 seconds

Download

Right click “Save as…”

High Quality WMV (PC, Xbox, MCE)
MP3 (Audio only)
Mid Quality WMV (Lo-band, Mobile)
High Quality MP4 (iPad, PC)
MP4 (iPod, Zune HD)
Mid Quality MP4 (WP7, HTML5)

format
< > embed
+ queue

Sign In first to access your queue.
Close

Sorry, video was not added to the queue, an error occurred. Please Contact Us and let us know.
Close

Embed code for this video

Copy the code above to embed our video on your website/blog.

Video format

Auto
Use our suggested format for this video.
Smooth Streaming
Adaptive bitrate streaming - little buffering but lower video quality at times of low bandwidth.
Progressive
Traditional buffered video format.
HTML5
For browsers that support h264 MP4 or WebM video playback such as:
IE9+, Chrome 5+, or Safari 4+.

Note: These selections will fall back to the next best format depending upon browser capability.

C++ AMP (Accelerated Massive Parallelism) is a small set of open specification language extensions (two of them) and a single library (amp.h) that makes general purpose GPU programming (aka GPGPU) a first class, seamless experience in modern C++.

You've been able to experiment with C++ AMP since the VS11 Developer Preview back in September 2011. We figured it was a good time to go C9 on the C++ AMP team. So, we did. Four interviews have been conducted that pretty thoroughly cover C++ AMP and the people who design, implement, and test it. C++ AMP is a great technology for native developers seeking to harness the power of the GPU using the language and tools they are already comfortable with. C++ AMP is also an open specification and we'll see other compiler vendors producing C++ AMP implementations for their target platforms soon—that's been the goal since Day 1.

Get VC++11 Beta Now - test out AMP!

Here, we meet the members of the C++ AMP test team; the engineers who write C++ AMP test cases to push the technology to its limits, ensure that features work as intended, find bugs, make sure the technology is ready for prime time before it gets in your hands.

In Old School C9 fashion, we start off in an office - of team leader Jerry Higgins in this case - and then walk around the building to meet the C++ AMP test team members in their native habitat (offices).

Meet Jerry Higgins, Joe Mayo, Bharath Mysore Nanjundappa, Pavan Marella, Kevin Gao, Lukasz Mendakiewicz, Daniel Griffing, Hasibur Rahman, Pooja Nagpal, and Tamer Afify. Come take a hallway tour with us.

Enjoy!

See Part 1 - Daniel Moth: AMP Overview
See Part 2 - Yossi Levanoni: AMP Architecture and Design
See Part 3 - The AMP Development Team Roundtable

Hi Zura,

There are many dimensions to a Software Design Engineer in Test (SDET) role at Microsoft, but the most important dimension is development/technical skills. When you test a programming language, you write code. You write code that exercises the grammar, code with targeted imperfections to assess error detection by the compiler front-end, back-end or linker, you may create code generators, modeling tools, transformers that morph code from an abstract syntax tree, workloads, samples or stress situations that push the technology to its limits. This is not the only thing that an SDET does. Influencing the design through design discussions, feedback on usability and issues found through thought experiments and proof of concept designs are an important part of the job. Testing parallel libraries, language constructs and code generation is more than a little challenging and can only be done through writing code that is often pretty interesting. There are other parts of the job that vary considerably depending on the technology you are working on, but writing code is a major part of the SDET role.

I know many excellent SDETs that are far beyond decent as engineers.

Changing your role from SDET to SDE or Program Management (PM) is possible, as is making a role change from PM or SDE to SDET. Which of these roles best suites a particular engineer is a matter of personal preference and/or proclivity.

Hope this helps answer your question.

Best Regards,

Jerry Higgins

Follow the Discussion

Subscribe to these comments

Zura

Feb 25, 2012 at 7:01 AM quote reply

Hi Charles,

Very interesting video, thanks!

But I don't understand "Software Engineer in Test" phenomenon in general. I mean, if you're a decent engineer, why should you be writing _only_ the testing code for things which were produced by other developers?
I'd understood if the production of testing code were (maybe boring) part of that same developers who authored the original product. But here, I can see engineers are _only_ writing tests, and this continues years...
Some insight from these guys would be great. Do they enjoy this?

Regards,
Zura
evildictaitor strcpy(malloc(4), "Oh noes!");

Feb 26, 2012 at 7:41 AM quote reply

Hi Zura,
The Software Engineer in Test career is only boring if you want it to be - and lots of really senior developers at Microsoft have at one point or another been an SET.
It's a bit like a battle of wills between the SETs and the normal devs; the dev writes some new code, and the job of the SET is to prove himself by finding the bugs in the code. The job of the dev is to not write the bugs in the first place. As the developers get better at not writing bugs, the SET must get better and more ingenious at finding the bugs in the first place.
If you think about it, SETs have arguably a much more fun job than devs. They don't need to spend their life thinking about customers or features or compatability and upgrade paths and bashing out more code to comply with EU law. All they need to do is look at the code that someone else wrote, beat it with a stick and send back the mangled remains to the original developer with a note saying "I bashed it with a stick and it broke. Please fix".
Ivan

Feb 26, 2012 at 8:00 PM quote reply

Charles, I stumbled on this video:
http://vimeo.com/36917212
lecture sounds cool, but audio is terrible. Do you think it would be possible for you to follow MS employees with a cam if they are giving some cool lecture like the one on the link.
Zura

Feb 28, 2012 at 2:34 AM quote reply

@evildictaitor

I see. Thanks for the insight. Doesn't sound boring anymore, especially when the path of converting to the regular SDE exists.
JerryHiggins

Feb 29, 2012 at 9:25 PM quote reply

Hi Zura,
There are many dimensions to a Software Design Engineer in Test (SDET) role at Microsoft, but the most important dimension is development/technical skills. When you test a programming language, you write code. You write code that exercises the grammar, code with targeted imperfections to assess error detection by the compiler front-end, back-end or linker, you may create code generators, modeling tools, transformers that morph code from an abstract syntax tree, workloads, samples or stress situations that push the technology to its limits. This is not the only thing that an SDET does. Influencing the design through design discussions, feedback on usability and issues found through thought experiments and proof of concept designs are an important part of the job. Testing parallel libraries, language constructs and code generation is more than a little challenging and can only be done through writing code that is often pretty interesting. There are other parts of the job that vary considerably depending on the technology you are working on, but writing code is a major part of the SDET role.
I know many excellent SDETs that are far beyond decent as engineers.
Changing your role from SDET to SDE or Program Management (PM) is possible, as is making a role change from PM or SDE to SDET. Which of these roles best suites a particular engineer is a matter of personal preference and/or proclivity.
Hope this helps answer your question.
Best Regards,
Jerry Higgins
Zura

Mar 01, 2012 at 8:39 AM quote reply

Hi Jerry,

Thank you for the very informative reply. That definitely answers my question.

Regards,
Zura