64bit対応で高速化が期待できる
Cortex-A35は、Cortex-A7などと同じくインオーダー（命令を順序通りに実行する）でデコーダーで2命令を同時に発行することができる。パイプラインは8ステージでロードストアと整数演算、NEON命令は別のパイプラインとなっている。
Cortex-A35の内部パイプライン。命令を順序通りに実行する「インオーダー」構成で、8ステージのパイプラインとなる。命令デコーダーは、制限付きながら2命令の発行が可能
ただし、同時に実行できるのは、整数演算とロードストア、またはNEON命令と組み合わせが限られ、すべての場合に2命令を同時実行できるわけはない。このため、単純て整数演算などでは、Cortex-A7とCortex-A35はあまり大きな性能差がない。
Cortex-A35とCortex-A7のパフォーマンス比較。整数演算では6%しか差がないが、データアクセスや浮動小数点のSIMD演算を多用すると性能差が出てくる
しかし、データアクセスにプリフェッチ機能があり、連続した領域のデータアクセスなどが効率良くできるようになっている。もう1つは、L1とL2が改良されて、性能が高くなっている。このため、メモリアクセスだけを見ると、Cortex-A35は、Cortex-A7の3.75倍の性能があるのだという。
性能差の理由の1つは、L1、L2の性能向上やデータのプリフェッチ機能などだ。この部分だけを見ると最大で3.75倍の性能差がある
こうしたアーキテクチャ上の工夫で、同じ製造プロセスで作っても、ウェブブラウジングのベンチマークでCortex-A7（同じくインオーダーコア）より16％ほど高速化している。
同じ28nmプロセスで製造したとき、Cortex-A35は、ウェブブラウジングで比較するとCortex-A7の1.84倍の性能が出せる。ただし、Cortex-A35は28nmプロセスで高性能な実装を行なっているため、クロック周波数も高くなる。しかし、クロック比では約1.7倍（2GHz÷1.2GHz）でアーキテクチャの違いによる性能差もある
また、同じコードで比較した場合だが、AMRv8の場合、ソフトウェアが64bit対応していると、同等の機能であっても、高速化されることが少なくない。というのも64bit命令のほうが高機能な暗号化命令などに対応しているからだ。
また、NEONの仕様も64bitでは拡張されているため、64bitコード化することで高速化することがある。同じ32bit環境でも、ARMv8の32bit環境（AArch32）では、拡張されている部分があり、64bit環境と同じ暗号化処理命令が利用可能など、高速化する余地がある（写真10#%P10%#）。同じクロック周波数でも暗号化処理などでは、3.5～11倍という速度差が生まれる（写真11#%P11%#）。
ARMv8-Aは、ARMv7互換の32bitアーキテクチャ（AArch32）と64bitアーキテクチャ（AArch64）を持っている。しかし、A35では、ARMv8で新設された暗号化命令などが利用できるように拡張されている
SHA-1（ハッシュ関数）、AES（暗号化方式）などに対応した命令セット（ARMv8で導入された）を持つため、Cortex-A7と比較すると性能差が大きくなる
ただし、どちらの場合も既存のソフトウェアを64bit化やARMv8対応する必要がある。比較的更新頻度の高いソフトウェアであれば、高速化が期待できる。なお、Androidの場合、アプリケーションはJavaの仮想マシンコードで記述されるため、アーキテクチャには影響されにくい。
しかし、これを実行するJava仮想マシン（VM）自体が高速化すれば、アプリケーションも高速化される可能性がある。また、一部のアプリでは高速な処理を行なうために機械語コードのモジュールを組み込んでいるものがある。それならば、この部分だけを64bit対応などにすることでさらに高速化される可能性がある。
Cortex-A35は、現在Cortex-A7を使うような低価格スマートフォン向けに利用可能で、さらにスマートウォッチなどのハイエンドなウェアラブルもターゲットにしている。また、LITTLEプロセッサとして、Cortex-A72やArtemisなどのbigプロセッサとの組み合わせでハイエンドスマートフォンやタブレットに導入されるだろう。その意味では、最も重要なCortex-Aプロセッサになる可能性がある。
本記事はアフィリエイトプログラムによる収益を得ている場合があります
