サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
wlog.flatlib.jp
Apple の製品紹介には、前モデルからどれだけパフォーマンスが向上したか比較値が載っています。この数値をまとめてみました。 iPad mini/iPad 2 はどちらも Apple A5 (Cortex-A9 1.0GHz dual/PowerVR SGX543MP2) が用いられており同一です。これを 1.0 とした時の速度の比較は下記のとおり。数値が大きい方が高速です。
S-SP = Single Thread 単精度 (GFLOPS) いずれも数値が大きいほうが高速 S-DP = Single Thread 倍精度 (GFLOPS) M-SP = Multi Thread 単精度 (GFLOPS) M-DP = Multi Thread 倍精度 (GFLOPS) 浮動小数点演算のピーク値だけの比較なので実際のアプリケーションの速度とは異なります。ですが、浮動小数点演算の速度だけでも Apple の公称値である「CPU 速度で 6倍」に近い数値を得ることが出来ました。 M-SP: 35.5 (iPod touch 6) / 6.2 (iPod touch 5) = 5.7倍 また 32bit 世代 (A4~A6) と 64bit 世代 (A7/A8) の間に入る調度良い比較対象だったので Mac mini Early 2009 の結果も載せてみました。もち
それまでコンシューマをやっていたチームが、新たに PC系ビデオカードでゲームを 作ろうと評価を始めると、エフェクトなど半透明の描画が遅いので引っかかって しまうことがあるようです。 でもよくよく話を聞いているとポリゴンを重ねすぎているだけのように見えます。 半透明の描画が通常のポリゴン描画よりも遅いのは当たり前です。 唯一当たり前じゃなかった特殊なハードが PS2 です。 PS2 には PixelShader どころかマルチテクスチャ等の pixel 演算系機能が無いので 表現力を上げるにはマルチパスを用いる必要がありました。 なのでエフェクトもひたすらポリゴンを重ねて半透明を大量に使う傾向があります。 PS2 は GPU (GS) にオンチップで VRAM を搭載していて、その転送バスは 2560bit (147MHz で 47GB/sec) もあります。16 pixel/sec と並列
昨年の AMD Mantle を皮切りに DirectX 12 が発表され、 つい先日 Apple から Metal も登場しました。 DirectX 11 以降停滞かつ安定していた状態から一変、 新しい GPU 向け API への流れが加速しつつあります。 どれも DirectX11, OpenGL とは互換性がない全く新しい API セットです。 これまでと趣が大きく異なっているのは CPU のための刷新だということ。 新しい描画機能への対応はなく GPU へのハードウエア追加も特に求められていません。 目的は CPU 負荷の軽減です。 API Platform Beta SDK GPUs ------------------------------------------------------------- Mantle Windows 2014/5 RADEON GCN Dire
iOS/OSX の API の多くは Objective-C の Interface となっています。 他のプラットフォームとのコード共有を考えるならば、 アプリケーション側はできるだけ普通の C/C++ で書きたいと思うかもしれません。 この場合 System の API 呼び出し部分を分離して、何らかの Wrapper 経由で アクセスすることになります。 Applicaton *.cpp : C++ Library header *.h : C++ / Objective-C++ Library source *.mm : Objective-C++ Wrapper Library のヘッダは C++ と Objective-C++ で共有されることになるので、 Objective-C の Object をそのまま記述することが出来ません。 ヘッダとソースで実装を分離して隠蔽すべきな
Amazon Fire TV は Qualcomm Snapdragon 600 APQ8064 搭載。 Kindle Fire HDX の Snapdragon 800 には及ばないものの、 Nexus 7 2013 の Adreno 320 より 1.5 倍高速です。 ・Amazon Fire TV Console SoC CPU clock core GPU GPU性能比予想 ----------------------------------------------------------------------- OUYA Tegra3 T33 Cortex-A9 1.7GHz 4 ULP GeForce(12) 1 Fire TV S600 APQ8064T Krait 300 1.7GHz 4 Adreno 320 6倍 Vita TV Cortex-A9 ?GHz 4 PV
Android NDK r9d では、新しく APP_ABI に armeabi-v7a-hard が追加されました。 とはいえ端末側の ABI の種類が増えたわけではなく、hard-float を指定した バイナリのビルドがより簡単に行えるようになります。 ・Android NDK r9b/r9c では hard-float を使うために jni/Android.mk に直接オプションを 記述していました。 # android-ndk-r9b/r9c # jni/Android.mk ifeq ($(TARGET_ARCH_ABI),armeabi-v7a) LOCAL_CFLAGS+= -mhard-float -D_NDK_MATH_NO_SOFTFP=1 LOCAL_LDLAGS+= -lm_hard -Wl,--no-warn-mismatch endif r9d からは上記のよ
SSE 等の SIMD 命令やキャッシュを意識したプログラムではメモリのアライメントを 考慮する必要があります。 これまではコンパイラ毎の拡張命令に頼っていましたが、 C++11 では言語仕様に含まれるようになりました。 メモリアクセスの同期命令も含めて、低レベルなメモリ命令を積極的に取り込んでいる印象です。 CC alignas alignof ----------------------------------------------------------------- VisualC++ __declspec(align(byte)) __alignof(type) gcc/clang __attribute__((aligned(byte)) __alignof__(type) C++11 alignas(byte) alignof(type) alignas はメモリ配置時のア
Windows を除いてほとんどのプラットフォームには zlib が入っており、 データの圧縮に利用することが出来ます。 ・zlib メモリ上のイメージを圧縮するだけなら下記のとおり。 // [1] // 圧縮データが入るバッファの確保 uLong buffer_size= compressBound( src_size ); Bytef* buffer= memory_alloc( buffer_size ); // 圧縮 compress( buffer, &buffer_size, src_memory, src_size ); // 圧縮後のサイズ compressed_size= buffer_size; 圧縮率を指定するなら compress() の代わりに compress2() を使います。 展開も同様。 // [2] uLong buffer_size= uncompre
下記 CPU ベンチ の結果を更新しました。 この結果だけを見れば iPhone 5 (A6) より約 1.8倍速く、 iPhone 5s は Core2 duo の 1.74GHz 相当となっています。 ・CPU ベンチ 以下抜粋 (詳細は上記ページを参照してください) CPU arch GHz time MB/sec 1GHzあたり -------------------------------------------------------------- Apple A7 CPU ARMv8 (arm64) 1.3 1.04s 104.27MB/s 80.21MB Apple A7 CPU ARMv8 (armv7s) 1.3 1.16s 93.04MB/s 71.57MB Cortex-A15 ARMv7A 1.7 1.49s 72.61MB/s 42.71MB A6 swift
iOS7 では iPad mini/iPad 2 の iPhone アプリの解像度が上がっています。 これまでの iOS6 の対応デバイスと対応する画面解像度は下記の通り。 iOS6 3.5 3.5R 4.0R HD HD-R RAM 480x320 960x640 1136x640 1024x768 2048x1536 ---------------------------------------------------------------- iPhone 3GS 256M ◎ -- -- -- -- iPhone 4 512M -- ◎ -- -- -- iPhone 4S 512M -- ◎ -- -- -- iPhone 5 1G -- -- ◎ -- -- iPod touch 4 256M -- ◎ -- -- -- iPod touch 5 512M -- -- ◎ --
iPhone 5s の浮動小数点演算速度を命令単位で比べてみました。 A7 の CPU core は ARMv8 で 64bit 命令に対応していますが、 ここでの比較は AArch32 (32bit mode) の VFP/NEON 命令となっています。 64bit mode (AArch64) ではレジスタの個数や view が異なるので 違う結果になる可能性があります。 (1) (2) (3) (4) (5) (6) Nexus7 EVO 3D iPhone5 HTL21 Nexus10 iPhone5s Cortex-A9 Scorpion Swift Krait Cortex-A15 ? Tegra3 MSM8660 A6 APQ8064 Exynos5D A7 1.2GHz 1.2GHz 1.3GHz 1.5GHz 1.7GHz 1.3GHz? ----------------
Bitbucket などクラウド系のリポジトリサービスを使うと、 どこでもソースコードをチェックできるので非常に便利です。 電車の中や外出時だろうと、ちょっとした空き時間にブラウザだけで コードを追うことができます。 そのうち欲が出てきて、どうせならこのままコードを手直ししたいとか コンパイルもできたらいいのに、とか思うようになります。 最近のモバイルデバイスは非常に性能が高いので、 クロス開発でなく自分でコンパイルしてもそれなりに速いはずです。 Android 端末なら各種 Linux 環境を install できそうなので試してみました。 Nexus 7 で動く Ubuntu 13.04 ●開発環境として gcc, clang はもちろん、python, git, mercurial などそのまま使えるので ライブラリのコンパイルや arm CPU のテストには十分です。 RAM は
浮動小数点演算も全体的にパフォーマンスが上がっています。 CPU core が Cortex-A9 でないことは間違いありません。 特に NEON は 4並列 (128bit) になっており、Cortex-A8/A9 の 2倍、 Qualcomm の Snapdragon 系 CPU core である Scorpion/Krait に 匹敵する速度が出ているようです。 特筆すべきは NEON 命令の out-of-order で、順番依存による 速度低下がほぼ発生していないように見えます。 この点は Scorpion より有利で、同じ 128bit 演算でも大きく差がつくと 思われます。 ただし Qualcomm の新 CPU core 、Krait でも同等の性能が出ている 可能性があります。残念ながらまだ Krait を手に入れておらず 評価できていません。 VFP も全体的に高速です
次のページ
このページを最初にブックマークしてみませんか?
『ホイール欲しい ハンドル欲しい | Mobile系、Direct3D や Shader などについて書い...』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く