JohnSawyer

I have a question about AVX (YMM registers) support: does the new autovectorizer also support wider 256-bit YMM registers (Sandy Bridge+)?

VC 10 also had support for SSE2 and AVX (via a command line) instructions. From the talk it seemed as if there wasn't any support for SIMD instructions.

Also the floating point addition was a bit misleading, since *AX and *BX registers are integer registers, while ADDPS means "Add Packed Single-Precision FP Values". You should have used an x87 FPU or SSE2 registers (as 32-bit float) as your nonvectorized example.

Look, moving* a block of memory can be done with four x86/x64 instructions.

mov ecx, _count (cx = count)
mov esi, _source_index (="si")
mov edi, _destination_index (="di")
repnz movsb (or movsd, or movsq in x64; repeat while CX Not Zero, MOVe String Byte / DWord / QWord)

Basically, all the work is done by one instruction, the instructions before just set up the operation. This can be cache efficiently implemented, since the processor knows that the whole block needs to be accessed.

Memory allocation is OS / runtime bookkeeping, you don't want to call it very often.

* "mov" actually means "copy".

16 hours ago, Charles wrote

@undefined: Slides will be released with each session video! Like this one

C

Cool. Now we can see the invisible graph.

It was a great lecture!

But I haven't had the time to watch other speakers. I'll download the 1080p version of talks, since 1080p makes reading the code much a nicer experience.

EDIT: Charles, would it be possible to also publish the PowerPoint or PDF slides?

I have one concern:

• for HDDs - the size is a non-issue
• for SSDs / NAND based drives - you get wearing by unnecessary rewriting
• for VMs - rewriting causes the diff image to grow - therefore using MORE disk space

 Did you take these concerns into account when designing the disk size "improvements"?

Oct 19, 2011 at 12:47 AM, JohnSawyer wrote

I watched the video yesterday. But it got me thinking - how exactly is rearranging the OS better than using a Hyper-V VM with memory deduplication on EPT/Nested Pages?

This keeps memory usage low. How many instances of IIS would you be able to run in VMs using memory deduplication, as opposed to the number in Drawbridge? How well does Drawbridge perform CPU-wise, as opposed to running on bare metal hypervisor?

Any benchmarks yet?

I watched the video yesterday. But it got me thinking - how exactly is rearranging the OS better than using a Hyper-V VM with memory deduplication on EPT/Nested Pages?

This keeps memory usage low. How many instances of IIS would you be able to run in VMs using memory deduplication, as opposed to the number in Drawbridge? How well does Drawbridge perform CPU-wise, as opposed to running on bare metal hypervisor?

There were also some scenarios mentioned, such as:
- using it to keep compatibility with XP
- sandboxing

Well, I don't think it is easy to refactor an outdated OS and to keep compatibility for every single system call. Would you use XP RTM, XP SP1, XP SP2 or XP SP3 as the baseline?

With an upgrade to a new OS version, your existing applications get a new look, since they blend with the OS's redesigned UI elements. This is very much desirable, as opposed to keeping it at the version "they were designed for". Then there's WinRT. I guess "desktop mode" APIs will stay Win7 compatible for a very long time, since most innovation will be in the WinRT world.

As to sandboxing, using a processor security feature (ie VM mode) is much more secure than it is to use existing ring protection. Unless you decide to use PL1 and PL2 (how's with ARM compatibility then)?

11 minutes ago, staceyw wrote

Nice. So in the future, a user could hit a exception, then "click-dump" the process (as a button in the exception window) and email to me. I could open that in VS debuging and be right in the context of the issue and even see what happened before the exception.

If you want to resume hibernation, you need hiberfil.sys as well as your intact filesystem. You can't just send hiberfil.sys to another machine and resume your OS there.

> My mistake, "ref new" differentiates them.

Yes, there's no GC, that's why no gcnew

I haven't checked the details, but to me it seems like C++/CLI compiled to native code, not MSIL.

If Microsoft needed to plug in .NET-like interfaces of WinRT to C++, it's easier to do it in a .NET supported language of C++/CLI. It's certainly less laborious.