iMac Pro 14 コアのベンチと Apple A11X について
GeekBench による iMac Pro 14 コアのベンチ
14 コアは、シングルスレッドで 5187、マルチスレッドで 40373 とのこと。
10 コアと比べてマルチスレッドでは 5000 スコア向上し
シングルスレッドでは -68 減少といったところ。
マルチスレッドは 8 コアから 10 コアで約 5000 スコア向上で、10 コアから 14 コアでも同様のスコア。
多分、18 コアのベンチも 14コアから約 5000 スコア向上が予想される。
そうなると、CPU のアップグレード費用 88,000 円で約 5000 スコア向上することとなり、 アップグレード費が均一価格なのは妥当かと。
ひとまず表にまとめてみた
ここ最近の Mac と iMac Pro 14 Core を比較
構成で一番安いものを価格として設定しており、
価格差、Multi-Core 性能差は iMac Pro 14 Core を基準。
1コアあたりと書かれているものは論理コアで計算している。
また、MacBook Pro (15-inch Mid 2017) Intel Core i7-7820HQ 2.9 GHz が 3.5 GHz より高いのはカスタマイズからしか選べないため。
| 機種名 | CPU | Clock | 物理コア | 論理コア | Multi-Core Score | Multi-Core 性能差 | 価格差 | 価格(税別) |
|---|---|---|---|---|---|---|---|---|
| iMac Pro (Late 2017) | Intel Xeon W-2170B | 2.5 GHz | 14 | 28 | 40373 | 100.00% | 100.00% | ¥734,800 |
| iMac Pro (Late 2017) | Intel Xeon W-2150B | 3.0 GHz | 10 | 20 | 35163 | 87.10% | 88.00% | ¥646,800 |
| iMac Pro (Late 2017) | Intel Xeon W-2140B | 3.2 GHz | 8 | 16 | 30531 | 75.60% | 76.00% | ¥558,800 |
| Mac Pro (Late 2013) | Intel Xeon E5-2697 v2 | 2.7 GHz | 12 | 24 | 26050 | 64.50% | 69.20% | ¥508,800 |
| Mac Pro (Late 2013) | Intel Xeon E5-1680 v2 | 3.0 GHz | 8 | 16 | 22787 | 56.40% | 51.30% | ¥376,800 |
| iMac (27-inch Retina Mid 2017) | Intel Core i7-7700K | 4.2 GHz | 4 | 8 | 19368 | 48.00% | 37.50% | ¥275,800 |
| iMac (21.5-inch Retina Mid 2017) | Intel Core i7-7700 | 3.6 GHz | 4 | 8 | 17787 | 44.10% | 25.40% | ¥186,800 |
| Mac Pro (Late 2013) | Intel Xeon E5-1650 v2 | 3.5 GHz | 6 | 12 | 17778 | 44.00% | 40.70% | ¥298,800 |
| MacBook Pro (15-inch Mid 2017) | Intel Core i7-7920HQ | 4.1 GHz | 4 | 8 | 15618 | 38.70% | 39.70% | ¥291,800 |
| iMac (27-inch Retina) | Intel Core i7-4790K | 4.0 GHz | 4 | 8 | 15465 | 38.30% | 37.50% | ¥275,800 |
| MacBook Pro (15-inch Mid 2017) | Intel Core i7-7820HQ | 2.9 GHz | 4 | 8 | 15299 | 37.90% | 41.20% | ¥302,800 |
| iMac (27-inch Retina Mid 2017) | Intel Core i5-7600K | 3.8 GHz | 4 | 4 | 15229 | 37.70% | 34.50% | ¥253,800 |
| MacBook Pro (15-inch Mid 2017) | Intel Core i7-7700HQ | 2.8 GHz | 4 | 8 | 14418 | 35.70% | 35.20% | ¥258,800 |
| iMac (27-inch Retina Mid 2017) | Intel Core i5-7500 | 3.4 GHz | 4 | 4 | 13836 | 34.30% | 27.10% | ¥198,800 |
| iMac (21.5-inch Retina Mid 2017) | Intel Core i5-7500 | 3.4 GHz | 4 | 4 | 13742 | 34.00% | 22.40% | ¥164,800 |
| iMac (21.5-inch Retina Mid 2017) | Intel Core i5-7400 | 3.0 GHz | 4 | 4 | 12824 | 31.80% | 19.40% | ¥142,800 |
| MacBook Pro (13-inch Mid 2017) | Intel Core i7-7567U | 3.5 GHz | 2 | 4 | 9570 | 23.70% | 31.50% | ¥231,800 |
| MacBook Pro (13-inch Mid 2017) | Intel Core i5-7360U | 2.3 GHz | 2 | 2 | 9112 | 22.60% | 22.40% | ¥164,800 |
以前も書いているが、全体で iMac のコストパフォーマンスが良い。
現状のラインナップだと、ほぼほぼ拡張できないので iMac という選択肢はありかも。
また、個人的には、ラップトップでプロ向けのスペックとして考えると MacBook Pro 13-inch は正直購入する選択肢から外すべきだと思っている。
大きさ、重さ、価格など考慮しない場合の話ではあるが。
iOS と iMac Pro 14 Core も比較してみる
A10 Fusion からは big.LITTLE の構成のため、高性能のチップでベンチが動いている模様。
| 機種名 | CPU | Clock | 物理コア | 実測用コア | Multi-Core Score | Multi-Core 性能差 | 価格差 | 価格(税別) |
|---|---|---|---|---|---|---|---|---|
| iPhone 8 Plus | Apple A11 Bionic | 2.4 GHz | 6 | 2 | 10184 | 25.20% | 12.20% | ¥89,800 |
| iPhone 8 | Apple A11 Bionic | 2.4 GHz | 6 | 2 | 10127 | 25.10% | 10.70% | ¥78,800 |
| iPhone X | Apple A11 Bionic | 2.4 GHz | 6 | 2 | 10112 | 25.00% | 15.40% | ¥112,800 |
| iPad Pro (10.5-inch) | Apple A10X Fusion | 2.3 GHz | 6 | 3 | 9305 | 23.00% | 9.50% | ¥69,800 |
| iPad Pro (12.9-inch 2nd Generation) | Apple A10X Fusion | 2.3 GHz | 6 | 3 | 9284 | 23.00% | 11.80% | ¥86,800 |
| iPhone 7 Plus | Apple A10 Fusion | 2.3 GHz | 4 | 2 | 5774 | 14.30% | 10.20% | ¥74,800 |
| iPhone 7 | Apple A10 Fusion | 2.3 GHz | 2 | 2 | 5694 | 14.10% | 8.40% | ¥61,800 |
| iPhone SE | Apple A9 | 1.8 GHz | 2 | 2 | 4088 | 10.10% | 5.40% | ¥39,800 |
| iPad mini 4 | Apple A8 | 1.5 GHz | 2 | 2 | 2841 | 7.00% | 6.20% | ¥45,800 |
Apple A11 Bionic では iMac Pro 14 Core の約 25％ のスペックを出し、
13-inch の MacBook Pro の Core i7 より速い結果が出てしまっている。
4台分の iPhone 8 が iMac Pro 14 Core と同等というのはおもしろい。
（並列につないでも確実にその速度は出ないとは思うけど）
ベンチマークの参考リンク
Mac Benchmarks - Geekbench Browser
iOS Benchmarks - Geekbench Browser
もうすぐ出ると思われる Apple A11X について
Apple A10 と A10X の時のように倍ぐらいになるのなら、
Apple A11 Bionic がマルチスレッドで1万スコアを超えているので、
iMac の Intel Core i7-7700 や 7700K 並になる。
それは行き過ぎだと思うが、少なくとも 15inch MacBook Pro (Intel Core i7-7700HQ) と同等になるのではないかと。
実現すると 13inch とは異なり物理コア4つ、論理コア8つのものと肩を並べることになる。
去年、色々なニュースサイトに流れていたが
A11X は高性能コア Monsoon x3 と高効率コア Mistral x5 になるらしく、
このコア数だと、A11 の 1.5 倍ぐらい.
噂どうりプロセスルールを変更して 2 倍にしてくるかもしれない。
今後
今年、macOS で iOS アプリが動作するようになるとの噂があるが、
最終的には Apple TV を強力にした据え置き型でプロ向けの Apple A チップのデバイスが出たりして、
パラダイムが変わるかもしれない。
Document Base App テンプレートを使って SceneKit のシーンファイル(.scn)簡易ビューワーをつくる for iOS
macOS の場合、ファイル選択しスペースキーを押すと QuickLook 経由でシーンファイルのプレビューが閲覧できるのだが、
iOS の場合設定がされていないので、極めて簡単な表示するだけのビューワーをつくってみる。
iOS の Document Based App とは？
iPhone は登場後、しばらくはユーザー側でファイルを直接扱うことができず、
iPad が登場した際に Pages、Numbers、Keynote など制作向けのアプリが登場し、
UIDocumentInteractionController が導入されユーザーからファイルを扱うことができるようになった。
iOS 11 では Files（ファイル）アプリが登場し、macOS の Finder と同様な操作ができるようになった。
Document Based App は Files の UI を使用でファイルを選択しアプリが動作するという、初期の iOS の思想とは異なるタイプのアプリとなっている。
Pages、Numbers、Keynote や GrageBand, ペイントソフトなど今までもこのタイプものはあったが、
今回は専用の API が用意されるようになった。
また、iOS 10 の iCloud Drive アプリではできなかった各アプリの Documents のフォルダにアクセスできるようになっている
Document Based App の主な動作
- Files（ファイル）アプリのような ViewController が起点となりファイルを選択し開く
- 開くと閲覧や作業用の ViewController に遷移
基本的にはファイルは自動保存させる必要があり、このタイプの Apple 製のアプリは自動で保存されているはずである。
また、特定のファイルを開くため、アプリでファイルの関連付けを行う必要がある。
Document Based App テンプレート
振る舞い
Files アプリのような UI が表示され画像を選択するとファイル名が表示される。
Open-in-place の設定もされているため、アクションシートなどからサポート対象にしたファイルを開くことができる。
つくってみる
Xcode 9 を起動し、Welcome to Xcode のパネルの「Create a new Xcode project」か Command + Shift + N を押して、 新しいプロジェクトのテンプレート選択画面を表示する。
「Document Based App」テンプレートが表示されていると思われるので選択して「Next」を押す。
プロジェクト名を決めて「Next」を押して任意の場所に保存。
Command + R で実機にビルド。
（多分、シミュレータでも動作するが iCloud のIDやパスワードを入れるのが面倒なので）
画像ファイルを選択すると ViewController に遷移してファイル名が表示される。
Document Based App テンプレートを編集してシーンファイルを表示する
流れ
- シーンファイルの情報を調べ関連付けを行う
- 新規作成時にプロジェクトのリソースにあるシーンファイルをコピーする
- シーンファイルを表示する SCNView を設定する
シーンファイルの情報を調べ関連付けを行う
シーンファイルの情報を調べる
ファイルの関連付けを行うためファイルの設定をする。
今回はあまり必要ないのだが、一応 macOS 側でシーンファイル(.scn)が関連付けられているため、ターミナルからファイルを調べる。
ターミナルで何らかのシーンファイルがある階層までき、以下を入力。
mdls ファイル名
文字列が羅列されるのでコンテントタイプと名前に注目。
kMDItemContentType = "com.apple.scenekit.scene"
kMDItemContentTypeTree = (
"public.item",
"public.content",
"com.apple.scenekit.scene",
"public.data",
"public.3d-content"
)
・
・
・
kMDItemKind = "SceneKit Scene Document"
シーンファイルの UTI として「com.apple.scenekit.scene」、
ファイルタイプとして「public.3d-content」、
ファイルの種類として「SceneKit Scene Document」が割り当てられている。
シーンファイルの情報を設定する
プロジェクトのターゲットで自分のアプリを選択し上のタブの「Info」を選択。
現状では Document Types と Imported UTIs が設定されている。
Document Types の編集
現状、画像ファイルが設定されているので修正。
今回はカスタムのファイルなのでなんども良いのだが、
Name を先ほど調べた「SceneKit Scene Document」に、
Types を「public.data」に設定している。
本来は Types を public.3d-content にしたいのだが、iOS で 3D の汎用ファイルがないため、汎用的な「public.data」を使用している。
テキストデータではないのはシーンファイルがバイナリの plist であるため。
閲覧だけなので document type properties は割愛
Exported UTIs の編集
Document Types の下にある Exported UTIs 編集してみる。
以下を設定。
| 設定名 | 値 |
|---|---|
| Description | SceneKit Scene Document |
| Identifier | com.apple.scenekit.scene |
| Conforms to | public.data |
関連づける拡張子を Additional exported UTI properties を以下に設定
UTTypeTagSpecification (Dictionary) > public.filename-extension (Array) > Item 0 (String) で scn を設定する
新規作成時にプロジェクトのリソースにあるシーンファイルをコピーする
テンプレートのままだと、「書類を作成」のボタンをタップしても何も起こらないので、
「書類を作成」のボタンをタップ時にリソースのシーンファイルを Documents フォルダーにコピーする。
DocumentBrowserViewController.swift を開き、 以下の中身を修正
func documentBrowser(_ controller: UIDocumentBrowserViewController, didRequestDocumentCreationWithHandler importHandler: @escaping (URL?, UIDocumentBrowserViewController.ImportMode) -> Void) { ... }
こちらに変更
func documentBrowser(_ controller: UIDocumentBrowserViewController, didRequestDocumentCreationWithHandler importHandler: @escaping (URL?, UIDocumentBrowserViewController.ImportMode) -> Void) {
if let url = Bundle.main.url(forResource: "max", withExtension: "scn") {
importHandler(url, .copy)
} else {
importHandler(nil, .none)
}
}
ビルド後、このアプリのフォルダの「書類を作成」のボタンか、ヘッダー右上の「＋」ボタンを押すと、
リソースにあるシーンファイルが新規作成時のファイルとしてコピーされファイル情報がファイル情報を取得できるようになりファイル名が表示される。
シーンファイルを表示する SCNView を設定する
Main.storyboard の SCNView 設定
Main.storyboard を開き、「Document View Controller Source」を選択。
Object Library (Command + Control + Option + 3) から SCNView をドラックして、Docuemnt Outline の Stack View の上に配置。
ざっくり Auto Layout を設定。
DocumentViewController.swift の設定
そして、DocumentViewController.swift に SCNView の IBOutlet を作成。
DocumentViewController.swift の 以下のコードの下に
self.documentNameLabel.text = self.document?.fileURL.lastPathComponent
こちらを追加すると完成
self.scnView.scene = try? SCNScene(url: (self.document?.fileURL)!, options: [:])
GIF のスクリーンショットでのアイコンがおかしい
本来は iPad と iPhone で各 small と Large の画像を設定する必要があり、設定されていないため Slack のアイコンが設定されてしまっている。
次の XCode 9.3 では1枚の設定だけでよく、今回は面倒なので複数画像作っていないためこうなってしまっている。
注意点
上記の GIF を見るとわかるがテクスチャが適応されていない。
シーンファイルで書かれているテクスチャのパスと合わせる必要があり、このままではテクスチャ画像のファイルを適応するのが難しい。
今回のものは iCloud を使用するため、以前のような iTunes からファイルを扱うものとはファイルが保存される場所が異なるので注意。 また、iTunes からアクセスする場合は以前のように info.plist で Application supports iTunes file sharing (UIFileSharingEnabled) を YES にする必要がある。
まとめ
まだまだ設定しなければいけないものがあるが、Document Base App テンプレートを使用すると割と簡単にファイルを扱うアプリができるかと。
今回は、挙動の詳細やファイルのサムネールや QuickLook などの設定はしていないため、iOS 11 Programming などを参照してもらえれば良いかと思われる。
サンプルコード
Apple の US サイトに Augmented Reality for iOS のページが追加
ARKit を使用した拡張現実の紹介がされている。
近いうちに日本語訳が出ると思われる。
追記
日本語ページができている模様。
序文の訳
Augmented Reality for iOS バーチャルとリアルに境界が存在しないと想像してみてください。 教室を宇宙にすることができます。 過去は、今現在のようにビビットになる可能性があります。 そして、馴染み深いものが今まで見たことのないものが見えるかもしれません。 iPhone と iPad では、すでに体験が可能です。 AR は、仕事、学習、遊び、そして周りのほぼすべてのものとのやりとりを変えるテクノロジーを使う新しい方法です。 これはほんの始まりに過ぎません。 新しい世界へようこそ。
紹介されているアプリでストアに公開されているもの
その他
Apple Heart Study というヘルス系のアプリのページもできていた。 日本ではダウンロードできない模様。 https://www.apple.com/watch/apple-heart-study/
Xcode 9.3 Beta 2 の SDK での変更
ざっと見た感じ BusinessChat の API が追加されている模様。
Beta 1 の頃から Swift 4.0 > 4.1 の変更があるけど割愛。
（機能追加や、flatMap { $0 + [1] } の flatMap が compactMap に変更とか）
BusinessChat で追加された Class
- BCChatButton
- BCChatAction
アプリから BusinessChat を開くための API らしい。
ちなみに BusinessChat と連携するアプリは iMessage アプリの Extension で作成する。使用方法は以下を参照。
BCChatButton
BusinessChat 用のボタン。
中身は light と dark のアピアランスが用意されているボタンの形状をした UIControl。
アクション用に BCChatAction が用意されているのでこのボタンを必ず使用する必要はなさそう。
BCChatAction
パラメーターとして intent、group、body がパラメーターとして用意されており、
openTranscript のメソッドでチャットの固有識別子と共にパラメーターに渡して、
iMessage アプリの BussinesChat を開く。
| パラメーター名 | 説明 |
|---|---|
| intent | サポートエージェントまたはビジネスシステムが製品、サービス、アカウント、またはその他のコンテキストを識別する |
| group | メッセージを適切なサポートエージェントグループにルーティングするのに役立つ |
| body | コンテキストメッセージの設定。入力欄に自動的に挿入されるいわゆるメッセージ本文 |
チャットの固有識別子は BusinessChat アクセス時にコールされる「urn:biz:〜」の波線の部分。
使い方
いつも通り、プロジェクトの設定の「Link Binary With Libraries」の「＋」ボタンから BusinessChat.framework を追加。
使用する Swift ファイルでどこかに下記を記載しインポート。
import BusinessChat
BCChatButton ボタン部分。
AutoLayout のコンストレイントは省略しているが普通のボタンの設定。
let button = BCChatButton(style: .light) button.bounds = CGRect(x: 16, y: 16, width: 160, height: 44) button.addTarget(self, action: #selector(change(sender: )), for: .touchUpInside) self.view.addSubview(button)
BCChatAction は openTranscript にパラメーターを入れるだけで起動する
@objc
func callBusinessChat(sender: BCChatButton){
BCChatAction.openTranscript(businessIdentifier: "test", intentParameters: [
BCChatAction.Parameter.group : "group",
BCChatAction.Parameter.intent : "intent",
BCChatAction.Parameter.body : "body"
])
}
iOS のアプリ が macOS でも動くという噂
恐らく一番最初に報道していたのは Axios というサイト。
どうでもよいけど、1月31日の記事なので、自分の予想のほうが早かった感はある。
実装的にはシミュレータが動作し、カメラなど一部機能は macOS の機能にアクセスするのだろう。
Drag and Drop や File Providor によるファイルアプリへのアクセスの API が追加されたのはこのための様な感じはする。
macOS で使っているファイルを同じデスクトップで動いている iOS にドラッグ&ドロップして動作する流れが実現できたら面白い。
多分、初期はアプリが動くだけで macOS との機能の繋ぎこみは後々となと予想される。
macOS で iOS のアプリが動く利点とは何か
実装がどうなるか分からないが、もし、これを実行する専用の iMac Pro の T2チップの様な SoC が付き、
最適化されるのであれば、現状動いている macOS のアプリより速く、バッテリーを食わない可能性がある。
重量級のアプリは macOS ネイティブ、軽い作業は iOS のアプリという運用になるのではないかと思われる。
また、Mac のシェアから考えると macOS のアプリの開発を行う人が、今後少なくなるだろう。
macOS での使いやすさはどうなるか分からないが、iOS アプリが動作するのであれば、
結果的に macOS アプリが増えることとなる。
そうなると、画面サイズ的に iPad のアプリベースの UI でのものと想定されるので、iPhone よりアプリの少ない iPad 対応アプリも増えると予想され、
ユーザーから見ると、最良の選択だと思われる。
一応、UIWindow を複数使用することで iOS でも複数のウィンドウを表示するアプリも作ることはできる。
（iOS で複数のウインドを使用している例としては Keynote で AirPlay や HDMI を使用した複数のディスプレイで表示している際の発表者ディスプレイのモード）
たぶん現実には起きない妄想
Macintosh PowerBook Duo の様に、macOS へ Thunderbolt 3 や Air Play 経由で iOS 端末を繋いで、
iOS アプリを macOS のデスクトップで動かすとかも面白いかも。
取り回しが煩雑になるのでやらないだろうとは思うけど。
個人的な問題点
基本的にはペンタブレットで作業しているため、もし iOS のアプリが動くとピンチインの動作が面倒。
Panasonic さん。照明などのスイッチを HomeKit 対応にしていただきたく
表題通り。
家庭の照明のスイッチはほとんど Panasonic 製だし、スイッチなので配線から電源取れるし、 そこそこお金を持っている人のスマートフォンやタブレットは iOS である可能性が高いので。
Philips Hue は、照明の色を変えたい、屋外や複数の照明の一部だけ点けたいなどの需要は満たすだろうが、
通常の照明で考えるとスイッチがスマート家電である方がどう考えても便利だろう。
あと Hue に関してはランプ自体が高いので LED が死んだ時に結構なお値段が必要になる。
スマートHEMS の AiSEG2 が Google Home 対応するとのことだけど、 そのシステム自体が HomeKit のアプリで完結できるため、スイッチを HomeKit に対応していただきたいところ。
スイッチ分だけ HomeKit 対応スイッチの製品価格と工事費がかかるのでそれなりに儲かるのではないかと思っている。
自分的には1つ4万ぐらいは出しますよ。
法律上、電気工事士の資格がないと取り付けられないと思われるが、 一応 Koogeek というメイカーが照明スイッチを出している。
iOS と macOS のアプリを統合すると噂の Project Marzipan について勝手な妄想
正直、現状から考えると当分先なきはするが勝手に妄想してみる。
多分、予想は間違っているけど。
現状の課題
macOS 10.4 からある PDFKit が iOS 11 から使えるようになったり、 iOS の Finder となりうる Files アプリが導入されたり、 SDK やシステムが iOS と macOS で似通ってきている。
ただ問題は UI が各 OS 異なっているものがあり、iOS と macOS で各UIに付随する機能やパーツを共有するのは難しいのではないかと思っている。
iOS で Array Controller などはないし、ボタン類だけでも多い。
もし行うのであれば、UI の共有化を地道に行うこととなるだろう。
それが完了してから tvOS のような形になるのではないかと思っていて、
数年でできる感じではないような気はしている。
統合プランその1
iOS のアプリを macOS でシミュレーションする
多分、これが一番想像しやすいパターン。
開発者向けの機能の Autolayout によって UI の配置や大きさがフレキシブルにできる（楽ではないが）ので、macOS 上で表示するだけなら問題ないと思われる。
また、iPad Pro の解像度は 2048 x 2732 なので、現状どの MacBook Pro 13 inch より解像度が高い。
iOS シミュレータで UI をマウスで使用する場合、使いづらい部分があるためこのようになるかは不明である。
もし、iOS アプリを実行するのであれば、実行専用の SoC チップを搭載する可能性もある。
統合プランその2
iOS のアプリのバイナリは同じで実行時に macOS の機能を呼び出す
Universal Windows Platform Bridge の Project Astoria の様に
macOS 上の iOS アプリ実行時に、macOS の機能と結びつけて実行する。
シュミレータを使用しないので速く起動しそうだが、Microsoft がこのシステムを諦めたのでまず難しいだろう。
統合プランその3
逆に iOS で macOS のアプリをシミュレーションして動かす
一番、夢がある。
A シリーズのチップが速くなってきたので iPad とかで macOS アプリが動いたら面白いかも。
もし、Xcode が iPad で動いたら胸熱ではある。
また、intel チップを使用せずに A シリーズのチップのみで構成 MacBook Pro などでても面白い。
ま、結果的にはこの場合は統合されてないんだけど・・・・・・。
統合プランその4
やっぱり地道にやる
NSColor や NSImage なんかの基本となる部分だけ、UIColor や UIImage などにして、 固有の UI や機能だけ別実装な感じで tvOS みたいな感じになるのだろう。
まとめ
とりあえず、実行が速くて開発が楽になればどの様な方法でも構わないし、iPad などで Xcode が使いたい。
それと、Swift、libswiftCore.dylib 的なやつをアプリに含めなくてもよくなる世界がおとずれて欲しい。
