There are many possible levels of virtualization.

At a low level, one might emulate the HW. This is quite flexible but too slow.

At a higher level, a basic OS runs separate virtual machines, each with its own file system.

1. Harmless machine instructions execute normally.

2. Powerful ones are trapped and emulated.

3. This requires a properly designed instruction set.

4. IBM has been doing this commercially for 40 years, with something originally called CP/CMS.

   I think that IBM lucked out with their instruction set design, and didn't plan it.

5. Well-behaved clients might have problematic code edited before running, to speed the execution.

   I think that Vmware does that.

6. It seems that compute-intensive clients might have almost no overhead.

7. However, the emulated file system can be pretty slow.

8. With Vmware, several clients can all be different OSs, and the host can be any compatible OS.

9. E.g., I've had a linux vmware host simultaneously running both linux and windows clients.

In linux, root no longer has infinite power.

The next level of virtualization has an nontrivial host OS, but separates the clients from each other.

1. They see a private view of the process space, file system, and other resources.

2. This is lighter weight, e.g., quicker to start a VM and less overhead.

3. The host and client must be the same OS.

4. This might be called paravirtualization.

5. Linux supports this with things like namespace isolation and control groups (cgroups). Wikipedia et al describe this.

6. Ubuntu snaps do something like this.

   E.g., firefox is distributed as a snap to increase isolation and security.

   However starting firefox now takes 15 sec.

The next level up is the normal linux security.

1. You can see all the processes and similar resources.

2. The file system has the usual protections.

3. This is hard to make secure when doing something complicated.

4. How do I protect myself from firefox going bad?

5. It's easy to describe what it should be allowed to do, but almost impossible to implement.

6. That includes using apparmor etc.

Who guards the guards? I get spammed at a unique address that I used only to register with apparmor.

In theory, packaging an app in a virtual machine has fewer dependencies and is more secure.

You can run the vm w/o changes on different hosts.

A Vmware client can run w/o change on both linux and windows hosts.

You can run a client on your own hardware, then spill over to a commercial cloudy platform when necessary.

Traditional top level function

auto add(int a, int b) { return a+b;}

You can pass this to a function. This really passes a pointer to the function. It doesn't optimize across the call.

These have global scope.

Note auto. It's underused.

Overload operator() in a new class

Each different variable of the class is a different function. The function can use the variable's value. This is a closure.

This is local to the containing block.

This form optimizes well.

Lambda, or anon function.

auto add = [](int a, int b) { return a+b;};

This is local to the containing block.

This form optimizes well.

Placeholder notation.

As an argument in, e.g., thrust transform, you can do this:

transform(..., _1+_2);

This is nice and short.

As this is implemented by overloading the operators, the syntax of the expression is limited to what was overloaded.

Thrust is an API that looks like STL. Its backend can be GPU-CUDA, OpenMP, TBB, or sequential host-based code.

Functional-programming philosophy.

Easier programming, once you get used to it.

Source code is compact.

Compiled code runs efficiently.

Uses some unusual C++ techniques, like overloading operator().

Since the Stanford slides were created, Thrust has adopted unified addressing, so that pointers know whether they are host or device.

Links:

1. https://docs.nvidia.com/cuda/thrust/index.html NVIDIA API

2. https://developer.nvidia.com/thrust Developer doc

3. https://thrust.github.io/

4. https://github.com/NVIDIA/thrust

5. CUDA Tutorial 11: Thrust Library Intro 19:35

6. CUDACast #15 - Introduction to Thrust 6:23

7. Introduction to GPU Programming with CUDA and Thrust 1:18:19

   All the preceding contains other interesting links.