I'd love to make our docs more clear on this. If you have a pointer to what is confusing we'll fix it up.

To be clear, for every machine type, we are offering a HT per virtual CPU. So that means that an n1-standard-8 instance gets 4 physical cores and 8 hyperthreads. (We are also offering 3.75GB of RAM and ~440G of ephemeral disk per vCPU).

I assume GCE is based on a space-shared design (1:1 pinned vCPUs); if that's not correct then this becomes harder. On https://developers.google.com/compute/docs/instances#overvie... I see the term "Virtual Cores", but I don't want to hear about virtual cores. I want to know how many physical cores are backing the VM. (I don't find the term "logical core" further down the page helpful either.)

So I would say:

n1-standard-1: 1/2 physical core

n1-standard-2: 1 physical core

...

n1-standard-8: 4 physical cores

Not to worry it is confusing for everyone. My experience when drilling down on these things are that generally in marketing advertising literature a 'core' is what most people would call a 'thread.' Engineering documentation is usually more precise but when its perceived value, perception take priority over precision.

I'd love to hear what people think the standard nomenclature here is. I've been arguing with our PM as to call these things virtual cores or virtual CPUs. Our API uses guestCpus.

This stuff is very confusing and I'd love to find the right way to communicate it clearly.

Part of the challenge is that Intel and AMD don't do you any favors.

In the ideal world for a set of cores C if I run a piece of independent, memory bound, code on all of them I get O(C) scale. Generally that doesn't hold in shared L2/L3 cores or where HyperThreads are counted as cores.

We can define a scaling factor Cf such that 0 < Cf < 1.0 independent code scales at O(Cf).

In one school you could price out at cores such that 1/Cf physical cores were assigned per Core purchased (rounded up to the nearest unit of computation) but that doesn't begin to get into the question of shared memory vs shared network vs shared disk.

I think the best you can do for now is call it a core if Cf is > .95.

In this case it means 8 cores/16 threads. Logging into a cc2.8xlarge instance shows 32 threads.

It sounds like EC2 and GCE are using different terminology here, so Google is giving you half as many cores as you think but thanks to Sandy Bridge they're crazy fast.

We went back and forth on naming the machine types. I'm sure you can imagine those discussions. In the end we opted for naming them based on the number of virtual CPUs from inside the VM. This is easier to remember than arbitrary sizes (small, medium, large) and is always going to be an integer. Hopefully this naming scheme can hold up and make sense over time as new machine types are introduced.