

Google Compute Engine vs. Amazon EC2: Video Transcoding - Heff
http://blog.zencoder.com/2012/07/23/first-look-at-google-compute-engine-for-video-transcoding/

======
sp332
How could transfers from Google to Amazon be so much faster than from Google
to Google?

~~~
jbeda
I'm the TL for Google Compute Engine.

This isn't the performance we expect here and we will be looking in to see
what is going on.

~~~
rdl
How do people get beta access? I'd love to look at moving workloads over to
GCE.

~~~
jbeda
Sign up and let us know what you are looking to do. We are trickling out
invites but being careful that we can deliver a great experience (support wise
and otherwise) to everyone.

~~~
Bjartr
A google product with a great support experience? This I gotta see.

~~~
mythz
Like most things in life, you get better support when you pay for it.

~~~
rdl
Honestly I've always gotten good support for Google products, either from
friends at Google or through forums, since they are popular enough to have
lots of users. Of course, I remember when Google was basically the only hiring
destination for top people in the valley (2001-2004 or so), and I only
narrowly avoided going to google myself.

I suspect they will do a decent job of supporting GCE, either through a
premium offering themselves, or through third party developers -- same thing
AWS has done. I had some meetings with AWS application/security platform
consultants recently, and they do a really good job of it, you just have to
pay for it.

This isn't a good argument for consumer products (if a random grandmother gets
locked out of her gmail, and doesn't know anyone, she may be doomed), but I
suspect any developer building products on GCE either knows someone or can pay
for support, or can bitch in a high visibility forum and get help from third
parties or by Google.

------
dmv
This is nice, simple experiment design. However, I'm really surprised they
only ran this once - or indicate trial counts and indicate range/distribution.
I'd be curious if video transcoding is so consistent that a single measurement
is enough to draw a conclusion; certainly network/storage transfer is not.
Sure, time and bandwidth are not free...

~~~
jon_dahl
Hi DMV - we ran the transcoding tests a few times, but transcoding performance
is pretty steady across multiple runs (here and elsewhere).

Network obviously isn't; the numbers here include about a dozen test runs. We
should make that more clear. Even a dozen isn't enough to be a scientific
test, so hopefully we (or someone else) will do more benchmarking in the
future.

------
dpe82
Google cache:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.zencoder.com/2012/07/23/first-
look-at-google-compute-engine-for-video-transcoding/&hl=en&prmd=imvns&strip=1)

~~~
Heff
The actual page should be performing better now.

------
ww520
The comparison on cost is again on the EC2 on-demand pricing. Reserved pricing
or spot pricing would cut that down substantially.

------
wmf
Does 8 cores mean 8 cores or 4 cores/8 threads? The documentation is
confusing.

~~~
jbeda
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).

~~~
wmf
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...](https://developers.google.com/compute/docs/instances#overview)
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

------
radarsat1
bah, measurements without standard deviations are next to useless...

------
jcdavis
Its not a fair comparison, but shouldn't they also be trying/using EC2 GPU
instances? I would think a large transcoding service such as zencoder has at
least looked into it at some point

~~~
salem
Much of the SFX film industry is not using GPUs, at least not for final
renders because differences floating point precision.

~~~
dpe82
Floating point precision isn't the problem - when your output is 8 or 10 bit
resolution, floating point differences aren't a big deal.

The biggest blocking factor is amount of code that needs to be ported to make
it work. High end SFX companies spend virtually all their man hours
implementing new stuff. They don't have the time to go back and reimplement
everything, and their customers aren't so cost sensitive that they demand it.

~~~
salem
Well, I know of at least one very large SFX shop that skipped GPUs for now
because the results were not consistent with results from the host CPUs. But
you're correct, man-hours to rewrite are more expensive than the CPU time in
that application.

