月別アーカイブ: 2014年1月

VFP Benchmark v1.1 浮動小数点演算命令の速度 (NEON/SSE/AVX)

x86 の SSE/AVX 命令に対応しました。
ARM CPU と同じように SSE/AVX の命令速度を計測することができます。

VFP Benchmark v1.1
VFP Benchmark Android (Google play)
VFP Benchmark iOS (AppStore)

上記は Android ですが iOS 版では ARMv8A (arm64) に対応しています。(2014/02/05 iOS 版追加)
下記は手持ちのデバイスでの結果。

Device           CPU                             sp GFLOPS  dp GFLOPS
---------------------------------------------------------------------
MacBookRetina13  Core i5-3210M Ivy    2.5GHz x2       90.2       45.2
Kindle HDX 7     MSN8974  Krait 400   2.2GHz x4       67.5       16.9
Tegra Note 7     Tegra4   Cortex-A15  1.8GHz x4       51.3        9.8
Nexus 7 (2013)   AQP8064  Krait       1.5GHz x4       47.8       11.8
iPhone 5s        A7 arm64 Cyclone     1.3GHz x2       40.9       20.5
iPhone 5s        A7 arm7s Cyclone     1.3GHz x2       40.9        8.0
Mac mini 2009    Core2 Duo P7350      2.0GHz x2       31.7       12.7
Nexus 10         Exynos5D Cortex-A15  1.7GHz x2       26.7        5.3
iPad 4           A6X      Swift       1.4GHz x2       21.5        3.6
iPhone 5         A6       Swift       1.3GHz x2       20.1        3.4
Nexus 7 (2012)   Tegra3   Cortex-A9   1.3GHz x4       18.9        4.7
EVO 3D ISW12HT   MSM8660  Scorpion    1.2GHz x2       16.6        1.3
VAIO Type P      Atom Z540 Bonnell    1.8GHz x1       10.9        1.9
Desire X06HT     QSD8250  Scorpion    1.0GHz x1        7.1        0.9
iPad 2           A5       Cortex-A9   1.0GHz x2        7.8        2.0
iPod touch 4     A4       Cortex-A8   0.8GHz x1        3.1        0.1
Raspberry Pi     BCM2835  ARM1176JZFS 0.7GHz x1        0.7        0.7

 * 数値が大きい方が速い。
 * sp= 単精度, dp= 倍精度

ピーク値の測定なので実アプリケーションの速度とは異なります。
詳しくはこちらを参照してください。
下記のページのほぼ理論値通りの傾向が出ています。

CPU FLOPS 理論値

倍精度のテストはまだ改良の余地があります。
スカラーで mul+add のペアリングを測定していないので、
一部の CPU でもう少しスコアが伸びると考えられます。

Core i5 Ivy Bridge は想定より高い数値が出ていますが、TurboBoost の効果で
より高いクロックで走っているようです。single-thread 時は 3.0GHz、
mult-thread 時は 2.85GHz 相当の結果となっています。

実際の測定結果は命令単位の数値を出すので、より細かく CPU の動作を
調べることができます。

SSE2/AVX1 には積和命令がありませんが、Intel CPU は加算と乗算命令が
並列に実行できるようです。
↓ 実際に addps/mulps の Interleave は半分の時間で実行しています。

Ivy Bridge Core i5-3210M
* SSE/AVX (single fp)                sec     MFLOPS     MFLOPS
AVX vmulps (32bit x8) n8      :    1.322    24205.7    24205.7
AVX vaddps (32bit x8) n8      :    1.319    24256.0    24256.0
AVX vmul+addps (32bit x8) n8  :    0.658    48604.4    48604.4

↓ Atom (Bonnell) は場合少々特殊です。
SSE 命令の乗算は加算よりも 2倍時間がかかっています。
動作クロックを考えると SSE の add が 128bit で mul が 64bit 幅で
演算していると考えられます。

Atom Z540 (Bonnell)
* SSE/AVX (single fp)                sec     MFLOPS     MFLOPS
SSE mulps (32bit x4) n8       :    4.307     3715.2     3715.2
SSE addps (32bit x4) n8       :    2.207     7248.1     7248.1
SSE mul+addps (32bit x4) n8   :    2.155     7424.2     7424.2

ARM NEON の場合は、同じ SIMD でも 64bit 命令があります。
例えば「 vadd.f32 d0,d1,d2 」は単精度 32bit x2 の 64bit 加算を行うので、
Cortex-A8/A9 のように 64bit 幅でも 1cycle で実行します。
128bit 命令「 vadd.f32 q0,q1,q1 」の場合は 2cycle かかります。

SSE は常に 4要素 = 128bit 単位なので Pentium 3 等 64bit 幅の
SIMD Unit では最小でも 2cycle かかることになります。
同様に Atom の乗算も最小値は 2cycle です。
ただし mulps + addps の Interleave でも、addps のみの場合と同じ時間で
完了するため、加算と乗算は非対称ながら Overlap できるようです。

Atom には HT があるので、Multi-thread 時は無駄な隙間を埋められます。
メインスレッドで mulps + addps のペアを実行し、サブスレッドで addps のみ
走らせるとおそらく 128bit + 64bit の非対称なパイプラインが埋まります。

mulps + addps + addps 組み合わせを 2スレッド走らせたのが下記の結果で、
スコアが伸びていることがわかります。

Atom Z540 (Bonnell)
* SSE/AVX (single fp) multi-thread   sec     MFLOPS     MFLOPS
SSE ml+ad+addps (32bit x4) n6 :    3.075    10926.6    10926.6

これらの測定結果から、CPU の個別の演算能力をまとめたのが下記の表です。
倍精度の値はもう少し変動する可能性があります。

・スカラー

                  単精度                      倍精度
CPU               mul    add    mad   fma     mul    add    mad    fma
-----------------------------------------    -------------------------
ARM1176JZF-S      0.5    0.5      1    --     0.5    0.5      1     --
Cortex-A8        0.14   0.14   0.18    --     0.1    0.1    0.1     --
Cortex-A9           1      1      2    --     0.5      1      1     --
Cortex-A15          1      1    1.4     2       1      1    1.4    1.4
Scorpion            1      1      2    --     0.5      1      1     --
Krait 400           1      1      2     2       1      1    1.6      2
A6 Swift            1      1      1     1       1      1      1      1
A7 Cyclone arm7s    1      1      2     2       2      3      3      3
A7 Cyclone arm64    2      3     --     4       2      3     --    1.6
Atom Bonnell        1      1     --    --     0.5      1     --     --
Core2 Penryn        1      1     --    --       1      1     --     --
Core i5 Ivy Bridge  1      1     --    --       1      1     --     --

 * 数値は 1 cycle に実行可能な演算数
 * 値が大きい方が高速

ARM11 の mul は 0.5演算/cycle となっています。
つまり単精度の加算や乗算は 2cycle かかります。

mad/fma は命令あたり 2 演算なので、この欄が 2 の場合に 1 cycle で
実行できることを意味しています。

Cortex-A8 のピーク FLOPS は NEON のおかげで ARM11 より高いですが、
上記のように VFP のスカラー演算では ARM11 に負けています。

A7 Cyclone (ARMv8A) は AArch32 (32bit mode) と AArch64 (64bit mode) で
かなり違いがあります。
単精度演算は 64bit mode の方が数倍速く実行できるようです。
おそらく VFP が要求する仕様が NEON と異なっているためだと考えられます。
AArch64 は NEON と統一されたので、NEON と同等の速度で動作できるようです。
VFP が足を引っ張る似たような傾向は、Cortex-A15 など他の ARMv7A CPU にも
見られます。

・SIMD 単精度

                   SIMD2 (32bit x 2)         SIMD4 (32bit x4)
CPU                mul   add   mad   fma     mul   add   mad   fma  
----------------------------------------    ----------------------
ARM1176JZF-S        --    --    --    --      --    --    --    --
Cortex-A8            2     2     4    --       2     2     4    --
Cortex-A9            2     2     4    --       2     2     4    --
Cortex-A15           4     4     8     8       4     4     8     8 
Scorpion             2     2     4    --       4     4     8    -- 
Krait 400            2     2     4     4       4     4     8     8 
A6 Swift             2     2     4     4       4     4     8     8 
A7 Cyclone arm7s     4     6     8     8       8    12    16    16 
A7 Cyclone arm64     4     6    --     8       8    12    --    16
Atom Bonnell        --    --    --    --       2     4    (6)   --
Core2 Penryn        --    --    --    --       4     4    (8)   --
Core i5 Ivy Bridge  --    --    --    --       4     4    (8)   --

Cortex-A8/A9 は 64bit 幅なので、SIMD2 では Scorpion/Krait/Swift と
差がありません。
SIMD4 では 128bit の Scorpion/Krait/Swift の半分であることがわかります。

ユニークなのは Cortex-A15 で、SIMD4 では同じ 128bit の
Scorpion/Krait/Swift と同等ですが SIMD2 では 2倍の数値となっています。
Cortex-A15 は 64bit 幅 2 pipe なので、2命令同時実行できるためです。
スカラーでは単精度でも 1命令/cycle だったので、半分しか使わなくても
NEON の方が速いことになります。

Ivy Bridge は AVX に対応しているので、上の表では省略していますが SIMD8
があります。下記のページに SIMD8 や倍精度 SIMD 含めて表にまとめています。

CPU FLOPS : FPU

一番最初の GFLOPS のリストでは、Quad core かつ動作クロックの高い
Snapdragon 800 (MSM8974) が上位でした。
CPU の cycle 単位の命令数を出してみると、唯一の ARMv8 CPU でもある
A7 Cyclone が群を抜いて高性能であることがわかります。

計測結果から、mul, mad/fma で 2命令、add では 3命令を同時に実行できるようです。
NEON の場合は AArch32 と AArch64 特に違いはありませんでした。

A7 Cyclone の設計は DEC Alpha や StrongARM に由来するエンジニアが
関わっているとのこと。(Wikipedia P.A.Semi)

Benchmark はあくまで浮動小数点演算能力のピーク値を実測することが目的なので、
必ずしも総合的な優劣には一致しないことを予めご了承ください。

関連エントリ
ARM CPU の VFP Benchmark アプリ 浮動小数点演算速度の計測
iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
Nexus 10 CPU Cortex-A15 の速度
Nexus 10 CPU Cortex-A15 の浮動小数点演算速度
Qualcomm APQ8064 GPU Adreno 320 の速度
Qualcomm APQ8064 Krait/A6 swift の浮動小数点演算能力
ARM Cortex-A8 の NEON と浮動小数演算最適化
benchmark 関連

ARM CPU の VFP Benchmark アプリ 浮動小数点演算速度の計測

今まで ARM CPU の浮動小数点演算速度について調べてきましたが、
その計測プログラムをアプリにしてみました。

VFP Benchmark (Android)

今までの測定結果のまとめは下記の通り。

ARM CPU core 毎の浮動小数点演算速度の比較 (VFP/NEON)

VFP Benchmark アプリの表示結果は上記の表と互換性があります。
さらに FLOPS 表示、倍精度浮動小数点演算の計測、マルチスレッド実行に
対応しました。
下記は幾つかの端末の結果(一部)です。

MSN8974 Krait 400 2.2GHz x4 quad
---------------------------------------
SingleT SP max : 16.619 GFLOPS
MultiT  SP max : 67.185 GFLOPS (理論値: 70.4 GFLOPS)
                               = 2(mad) x 4(simd) x 4(core) x 2.2(clock)


Tegra4 Cortex-A15 1.8GHz x4 quad
---------------------------------------
SingleT SP max: 13.371 GFLOPS
MultiT  SP max: 51.345 GFLOPS  (理論値: 57.6 GFLOPS)
                        = 2(mad) x 2(simd) x 2(unit) x 4(core) x 1.8(clock)


APQ8064 Krait 1.5GHz x4 quad
---------------------------------------
SingleT SP max: 11.947 GFLOPS
MultiT  SP max: 47.808 GFLOPS  (理論値: 48.0 GFLOPS)
                               = 2(mad) x 4(simd) x 4(core) x 1.5(clock)

Exynos5D Cortex-A15 1.7GHz x2 dual
---------------------------------------
SingleT SP max: 13.483 GFLOPS
MultiT  SP max: 26.724 GFLOPS  (理論値: 27.2 GFLOPS)
                        = 2(mad) x 2(simd) x 2(unit) x 2(core) x 1.7(clock)


Tegra3 Cortex-A9 1.2GHz x4 quad (TB1.3GHz)
---------------------------------------
SingleT SP max:  4.783 GFLOPS  (理論値:  5.2 GFLOPS
MultiT  SP max: 18.905 GFLOPS  (理論値: 19.2 GFLOPS)
                               = 2(mad) x 2(simd) x 4(core) x 1.2(clock)

K3V2 Cortex-A9 1.2GHz x4 quad
---------------------------------------
SingleT SP max:  4.694 GFLOPS
MultiT  SP max: 18.662 GFLOPS  (理論値: 19.2 GFLOPS)
                               = 2(mad) x 2(simd) x 4(core) x 1.2(clock)


MSN8260 Scorpion 1.2GHz x2 dual
---------------------------------------
SingleT SP max:  8.898 GFLOPS
MultiT  SP max: 16.560 GFLOPS  (理論値: 19.2 GFLOPS)
                               = 2(mad) x 4(simd) x 2(core) x 1.2(clock)


QSD8250 Scorpion 1.0GHz x1
---------------------------------------
SingleT SP max:  7.098 GFLOPS  (理論値:  8.0 GFLOPS)
                               = 2(mad) x 4(simd) x 1.0(clock)

Tegra 2 Cortex-A9 1.0GHz x2 dual
---------------------------------------
SingleT SP max:  1.973 GFLOPS
MultiT  SP max:  3.913 GFLOPS  (理論値:  4.0 GFLOPS)
                               = 2(mad) x 2(core) x 1.0(clock)

比較的理論値に近い数値が出ています。
各 CPU の理論値は下記にまとめました。

CPU FLOPS

この出力結果はあくまでピーク値による比較なので、
実際のアプリケーションの実行速度とは異なります。

例えばスカラ VFP 演算で n8 と n1 の結果を比べると、
Cortex-A9 では命令の並び順によって 5倍も速度が落ちるケースがあります。
同じ条件でも Krait / Cortex-A15 はほとんど速度が落ちていないので、
パイプラインの実行効率が向上していることがわかります。

よって実際のアプリケーションでは、Cortex-A9 と Krait/Cortex-A15 では
ピーク値よりもさらに差が開くことが予想されます。

multi-thread は同じテストを CPU core の数だけ走らせています。
Tegra 3 のように single thread 時に動作クロックが上がるものがあるので、
single-thread の値を core 数倍しても正しい値にならないためです。

アプリの出力結果を見ると、Cortex-A15 は VFP のスカラ演算よりも
NEON の 64bit (float x2) の方が 2倍速く実行できることがわかります。

// Exynos 5 Dual Cortex-A15 1.7GHz dual (Nexus 10)

* VFP/NEON (single fp)         sec    MFLOPS    最大
----------------------------------------------------
VFP fmuls     (32bit x1) n8 :  2.675  1495.4  1555.9
VFP fadds     (32bit x1) n8 :  2.392  1672.1  1672.1
VFP fmacs     (32bit x1) n8 :  3.171  2523.2  2523.2
VFP vfma.f32  (32bit x1) n8 :  2.985  2679.9  2679.9
NEON vmul.f32 (32bit x2) n8 :  1.187  6740.5  6740.5  **
NEON vadd.f32 (32bit x2) n8 :  1.187  6740.7  6740.7  **
NEON vmla.f32 (32bit x2) n8 :  1.187 13480.8 13480.8  **
NEON vfma.f32 (32bit x2) n8 :  1.187 13480.3 13480.3  **
NEON vmul.f32 (32bit x4) n8 :  2.373  6741.8  6741.8
NEON vadd.f32 (32bit x4) n8 :  2.374  6740.7  6740.7
NEON vmla.f32 (32bit x4) n8 :  2.373 13482.7 13482.7
NEON vfma.f32 (32bit x4) n8 :  2.373 13482.3 13482.3

以前予想したようにおそらく NEON の演算 unit は 64bit の 2 pipe ですが、
VFP は 1命令しか実行できない可能性があります。
Cortex-A8 で行ったように、VFP 命令を NEON 演算に置換する
Cortex-A15 最適化ができるかもしれません。

関連エントリ
iPhone 5s A7 CPU の浮動小数点演算速度 (2) (arm64/AArch64/64bit)
iPhone 5s A7 CPU の浮動小数点演算速度 (32bit)
Nexus 10 CPU Cortex-A15 の速度
Nexus 10 CPU Cortex-A15 の浮動小数点演算速度
Qualcomm APQ8064 GPU Adreno 320 の速度
Qualcomm APQ8064 Krait/A6 swift の浮動小数点演算能力
iPad 4/iPad mini A6X/A5 の CPU/GPU 速度
iPhone 5 / A6 の CPU 速度 その 3
ARM Cortex-A8 の NEON と浮動小数演算最適化
benchmark 関連

OpenGL ES 2.0/3.0 Mobile GPU の Shadow Map の違い

・Android Adreno 320 OpenGL ES 3.0 (Nexus 7 2013)
adreno320_nexus7_es3.png

・Android Adreno 320 OpenGL ES 2.0 (HTC J butterfly HTL21 )
adreno320_es2.png

・Android Mali-T604 OpenGL ES 3.0 (Nexus 10 2012)
malit604_nexus10_es3.pngmalit604_nexus10_es3_b.png

・Android Tegra 4 ULP GeForce(72) OpenGL ES 2.0 (Tegra Note 7)
tegra4_note_es2.png

・Android Tegra 3 ULP GeForce(12) OpenGL ES 2.0 (Nexus 7 2012)
tegra3_nexus7_es2_colorbuffer.png

・iOS7 PowerVR SGX543MP3 OpenGL ES 2.0 (iPhone 5)
pvr543mp3_iphone5_es2.png

・iOS7 PowerVR G6430 OpenGL ES 3.0 (iPhone 5s)
pvrg6340_iphone5s_es3.png

・RK3066 Mali-400MP4 OpenGL ES 2.0 (MOMO7)
mali400mp4_es2.png

・Vivante GC4000 OpenGL ES 2.0 (dtab 01)
vivante_gc4000_es2.png

OpenGL ES 2.0 デバイスの大半は GL_OES_depth_texture だけに対応しており
フィルタはかかりません。
depth_texture が無い Tegra2/3 は ColorBuffer で代用しています。

Tegra 4 は OpenGL ES 2.0 ですが Extension で GL_EXT_shadow_samplers に
対応しておりハードウエアで sampling できるようになっています。

同じように iOS の PowerVR Series5XT も OpenGL ES 2.0 ながら早くから
GL_EXT_shadow_samplers に対応していました。
iOS5/6 の当初は PCF もなく見た目が全く変わらなかったのですが、
iOS7 ではいつの間にかフィルタがかかるようになっていました。

なお同じ PowerVR Series5XT の GPU でも Android では残念ながら
shadow_samplers が使えない場合が多いです。

OpenGL ES 3.0 以降は PC 同様そのまま shadow samplers が使えます。
ただし結果は GPU やドライバによってかなり差があるようで、
Adreno 320 や PowerVR G6430 が 4 tap PCF のみ。
逆に Mali-T604 のフィルタは他より質が高くなっています。

                        OS  OpenGL depth-tex sh-sample PCF Linear
-----------------------------------------------------------------
APQ8064 Adreno 320      A44 ES 3.0     ◎       ◎      ◎   --
APQ8064 Adreno 320      A41 ES 2.0     ◎       --      --   --
Exynos5 Dual Mali-T604  A44 ES 3.0     ◎       ◎      ◎   ◎
Tegra 4 ULP GeForce(72) A43 ES 2.0     ◎       ◎      ◎   ◎
Tegra 3 ULP GeForce(12) A44 ES 2.0     --       --      --   --
A6 PowerVR SGX543MP3    i70 ES 2.0     ◎       ◎      ◎   ◎
A7 PowerVR G6430        i70 ES 3.0     ◎       ◎      ◎   --
K3V2 Vivante GC4000     A41 ES 2.0     ◎       --      --   --
RK3066 Mali-400MP4      A41 ES 2.0     ◎       --      --   --
OMAP4430 PowerVR SGX540 A42 ES 2.0     ◎       --      --   --

Tegra 2 → Tegra 3 は core 数(速度) が違うだけで機能は全く同一でした。
対して Tegra 4 の GPU は、Tegra2/3 と比べると大幅に拡張されています。
機能面で見ればほぼ別 GPU といえるほど差があるのですが、
OpenGL ES 3.0 未対応など先行する他 GPU より見劣りする部分もあります。

DX9 世代の G70 ベースの限界なのか、それとも単に Tegra2/3 で
削っていた能力を元に戻しただけなのかもしれません。

一般的に NVIDIA に期待するイメージは強力な GPU でしょう。
ですがこれまでの Tegra は真逆で CPU に偏重した作りでした。
次の Tegra K1 以降はようやく NVIDIA らしい GPU になりそうです。

関連エントリ
OpenGL ES 2.0 Adreno 330, Tegra 4 の GPU 速度

OpenGL ES 2.0 Adreno 330, Tegra 4 の GPU 速度

ベンチマークの結果を更新しました。

Mobile GPU bench mark

Android 4.1 以降かつ対応しているデバイスでは SwapInterval を 0 に
変更したので 60fps 以上出ています。(関連)

GPU            SoC   CPU clock OS    Screen     fps       pix/sec
---------------------------------------------------------------------
Adreno 330     MSM8974 2.2GHz  A4.2  1920x1200  71.98fps   165.8M
Adreno 320(64) APQ8064 1.5GHz  A4.4  1920x1104  40.97fps    86.8M
Mali-T604     Exynos5D 1.7GHz  A4.4  2560x1504  20.73fps    79.8M
ULP GeForce(72) Tegra4 1.8GHz  A4.3   1126x800  44.58fps    43.4M
ULP GeForce(12) Tegra3 1.2GHz  A4.4   1280x752  15.70fps    15.0M (*1)

*1: Shadow Map 無し, 16bit depth

Adreno 330 は予想以上に速く、Adreno 320 比でもおよそ 2倍の速度が出ています。
ついに一番負荷が高い設定でも Full HD (1920×1200) で 60fps を超えるように
なってしまいました。
2010 年の GPU では 800×480 でもわずか 3fps でした。

対する Tegra 4 はあまり速度が伸びていません。
負荷を下げても速度が上がらないので、SwapInterval 設定が効いていないか
何かしら問題が発生している可能性があります。

その代わり Tegra 3 で省かれていたさまざまな extension をサポートしており
描画結果が他の GPU とほぼ一致するようになりました。

特に GL_EXT_shadow_samplers は単なる Hardware ShadowMap ではなく
PCF にきちんと Bi-linear Filter もかかります。
GL_EXT_shadow_samplers は OpenGL ES 3.0 以降のデバイスはどれも対応
していますが、必ずしも Filter がかかるとは限らないようです。
下記はいくつかテストした結果です。

                               depth-tex sh-samplers PCF Filter
----------------------------------------------------------------
8064 Adreno 320 OpenGL ES 3.0      ◎        ◎      ◎   --
8064 Adreno 320 OpenGL ES 2.0      ◎        --      --   --
Mali-T604       OpenGL ES 3.0      ◎        ◎      ◎   ◎
Tegra 4         OpenGL ES 2.0      ◎        ◎      ◎   ◎
Tegra 3         OpenGL ES 2.0      --        --      --   --
iOS PVR 543MP3  OpenGL ES 2.0      ◎        ◎      ◎   ◎
Vivante GC4000  OpenGL ES 2.0      ◎        --      --   --
Mali-400MP4     OpenGL ES 2.0      ◎        --      --   --
PowerVR SGX540  OpenGL ES 2.0      ◎        --      --   --

この辺りはもう少し詳しく調べたいと思っています。
なお Tegra4 の Extension 詳細は下記のページに追加しました。

CPU/GPU OpenGL ES Extension (Mobile GPU)

関連エントリ
Android OpenGL ES と V-Sync (eglSwapInterval)
Nexus 10 GPU Mali-T604
Qualcomm APQ8064 GPU Adreno 320 の速度
さらに OpenGL ES 2.0 Mobile GPU の速度比較
GPU 速度に関連するエントリ

VisualStudio と C++11 、コンパイラの違いなど

Visual C++ Compiler Nov 2012 CTP では動いていたけど、
VisualStudio 2013 以降コンパイルできなくなったコード。

struct List {
    int var_a, var_b;
    List( int a, int b ) : var_a( a ), var_b( b )
    {
    }
};

class Tree {
public:
    template
    T* Alloc( A0... a0 )
    {
        return  new T( a0... );
    }
};

class Compiler {
    Tree    tree;
public:
    template
    T* Alloc( A0... a0 )
    {
        return  tree.Alloc( a0... );
    }
};

...

Compiler compiler;
compiler.Alloc( 1, 2 );
VS2012 + Nov 2012 CTP : OK
VS2013                : internal error
VS2013 + Nov 2013 CTP : internal error
gcc 4.8.1             : OK
clang 3.2             : OK

template を分解して単純化して回避。

struct T0 {
    T0()= default;
    T0( const T0& )= default;
    T0( int a ){};
};

↑ T0 は VS ではまだ POD 扱いにならないようです。

                 std::is_pod
-----------------------------------
VS2013                 false
VS2013 + Nov 2013 CTP  false
gcc 4.8.1 (Linux)      true
clang 3.2 (Linux)      true

POD かどうかで、値渡し時に関数の呼び出し方が変わります。
sizeof が 8byte 未満でも register に入らず参照戻しになります。

struct T1 {
    T1()= default;
    T1( const T1& )= default;
    int var;
};
struct T2 {
    T2()= default;
    T2( const T2& )= default;
    T2( int a ){};
    int var;
};

T1 pod_test1( T1 a )
{
    return  a;
}
T2 pod_test2( T2 a )
{
    return  a;
}

void pod_test()
{
   T1 a1;
   T1 ret1= pod_test1( a1 );
   T2 a2;
   T2 ret2= pod_test2( a2 );
}
// Windows x64
// T1
    xor ecx, ecx
    call    ?pod_test1@@YA?AUT1@@U1@@Z      ; pod_test1
// T2
    lea rcx, QWORD PTR $T2[rsp]
    xor edx, edx
    call    ?pod_test2@@YA?AUT2@@U1@@Z      ; pod_test2

Windows x64 は fastcall 相当なので引数はレジスタ ecx, edx, r8, r9 に入ります。
上の T1 ではそのまま引数が ecx に入っています。

↑ T2 の場合戻り値を受け取るために、呼び出し側が領域を確保して rcx で渡しています。
実際の引数は edx です。

// Windows x64
// T1
?pod_test1@@YA?AUT1@@U1@@Z PROC             ; pod_test1, COMDAT
    mov eax, ecx
    ret 0

// T2
?pod_test2@@YA?AUT2@@U1@@Z PROC             ; pod_test2, COMDAT
    mov DWORD PTR [rcx], edx
    mov rax, rcx
    ret 0

↑ T1 では呼ばれた側は引数を戻り値 rax にコピーしているだけ。
↑ T2 は rcx のバッファに結果を格納しつつ rax にもアドレスを返しています。

gcc 4.8/clang 3.2 ではどちらも POD 扱いなので T1/T2 共に同じコードとなっています。
Linux では呼び出し規約 (calling convention) が異なるのでレジスタは別です。
(rdi, rsi, rdx, rcx, r8, r9 の順)

Function Calling convention

// Linux x86_x64
// T1
    xorl    %edi, %edi
    callq   _Z9pod_test12T1
// T2
    xorl    %edi, %edi
    callq   _Z9pod_test22T2
// Linux x86_x64
// T1
_Z9pod_test12T1:                        # @_Z9pod_test12T1
    movl    %edi, %eax
    ret
// T2
_Z9pod_test22T2:                        # @_Z9pod_test22T2
    movl    %edi, %eax
    ret

下記は gcc 以外はコンパイルが通ります。

template
void CallScript_UIEvent( A0... a0 )
{
    slice::Add( "Move",
        [=]( slice::SliceBase* slice ){
            CallScript_Direct( a0... );
            slice->Delete();
        }
    );
}
VS2012 + Nov 2012 CTP : OK
VS2013                : OK
VS2013 + Nov 2013 CTP : OK
gcc 4.8.1 (Linux)     : error
clang 3.2 (Linux)     : OK

template 引数が可変長でなければコンパイル通ります。

関連エントリ
C++11 Lambda function ラムダ関数
C++11 Variadic Templates 可変長引数のテンプレート
スレッド同期命令の比較 C++11 とコンパイラ
C++11 Rvalue Reference 右辺値参照