Shane StanleyのFrameworkバイナリ入りAppleScript Library「Bridge Plus」「Myriad Tables Lib」「SQLite Lib2」がApple Silicon対応していました。

それぞれ単独の配布アーカイブではApple Silicon対応していないのですが、「Shane’s Script Library Pack」でまとめて配布されているものはApple Silicon対応のUniversal Binaryでビルドされています。

インストーラーはAppleScriptアプレットになっており、実行すると……これらのライブラリがインストールされていません。このため、Shane Stanley本人に聞いてみたところ、これらのインストール対象のライブラリがすでにインストールされている場合には、あらかじめ削除しておいてほしいとのこと。

……それはわかりませんでした（＾ー＾；；

m1mini:~ me$ file /Users/me/Library/Script\ Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus 
/Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
/Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

あれ？　Dialog Toolkit PlusもFramework同梱ライブラリですが、これに含まれていないような、、、、
→ ああ、バンドル内にFrameworksフォルダが存在しているものの、中身はありませんでした（Thanks Shane!）

M1 Mac miniで各種AppleScript系のベンチマークをとってみたところ、信じられないほど遅く、「どうやらAppleScriptを高性能コア（Firestorm）ではなく高効率・省電力コア（Icestorm）」で実行しているのでは？　という疑いを持ちました。

＃　本件はmacOS 12で修正されました

10倍遅いというとショッキングな数値に見えますが、問題はこれが「まだマシな方」の結果であり、トータルで77倍遅い処理があったりと、目を疑いたくなるような結果のオンパレードです。

そんな中、アクティビティモニタの「ウィンドウ」＞「CPUの履歴」で各CPUコアの履歴とともに種別が表示されることが判明。Icestormには「効率性」、Firestormには「パフォーマンス」とコアごとの種別が表示されます。

冗談抜きで、AppleScriptがIcestormで（効率性コア）実行されているようにしか見えません。

M1 Mac＋macOS 11上で各種ベンチマークをとってみたところ、Intel Mac＋macOS 10.14よりも大幅にパフォーマンスが低下する例が頻発。NSMutableArrayに21万項目の項目を追加するベンチマーク（５回計測して平均値を計算）を走らせてみたところ、

　MacBook Pro Retina 2012（Intel Core i7 2.6GHz、macOS 10.14.6）：8.69秒
　Mac mini M1 2020（M1 3.2GHz、macOS 11.5beta）：104.25秒

M1 MacがIntel Mac（しかも2012年のマシン）の77倍も処理時間がかかるという結果が出ています。このため、AppleScriptをFirestormではなくIcestormで動かしているのではないか、と疑っていました。

とくに、M1ではAppleScriptのrandom number（乱数計算）コマンドが極端に遅く、これを使ってテスト用に乱数データを作ると腰が抜けるほど時間がかかります。シーケンシャル値の続く配列を作ってGamePlaykit.frameworkを用いてシャッフルするのがよさそうです。ただ、本当にM1でrandom number計算は遅くなります。

700箇所の位置情報をもとに、日本全国の最寄りの鉄道駅を計算する距離計算を行なったところ、M1 Mac miniでは2012年製のMacBook Pro Retina 2012の10倍処理時間がかかりました。MBPで6分かかるところがM1だと1時間かかりました。

GUIアプリケーションにちょこちょこ命令するだけとかいう、「単なるマクロ言語」としての世界観（小乗AppleScript）で使う分にはよいのですが、アプリケーションに依存せず単体でデータ処理を行なったり、Mac App Storeで販売するGUIアプリケーションまで記述して実行しているわけで、Icestormで実行してほしくはありません。

Intel Macで６分あまりの処理にM1 Macでは60分以上かかっており、2012年のマシンに比べて2021年製の最新鋭のマシンがまさに文字通り「桁違いの遅さ」を見せているのが現状です。

実行中のアクティビティモニタの表示を見ると、高性能コア（Firestorm）への負荷はあまりかかっておらず、逆に高効率コア（Icestorm）への負荷が集中していることが見て取れます。

Intel Mac上で実行中には、4コア8スレッドのIntel Core i7の各コア（4コア）に均等に負荷がかかっていることが見て取れました。

M1 Mac miniの基本性能の高さはグラフィック性能やディスクI/O性能を中心に実証されているため、あくまでOS側の「味付け」の問題が原因と見ています。

AppleScriptが単なる「GUIアプリケーションをちょこっと自動化するだけのお可愛らしいマクロ言語」なのであれば、Icestormで実行するという話も悪くはないでしょう。ただ、Mac App Storeで販売しているGUIアプリケーションから各種データ処理を行うシビアな処理を行う処理系でもあり、やはり2012年のIntelマシンの10倍とか77倍遅いという現状は面白くはありません。

を注文しました。WWDC21でハードウェア系の発表が行われなかったということは、少なくとも2021年中に現行のM1 Mac以上のマシンを投入できないものと判断したためです。

さすがにMacBook Pro Retina 2012では物理的にも性能的にも無理があり、メインマシンとして入れ替えることになります。まだ「上海を出た」ぐらいの距離感です。

RAM 16GB、SSD 1TB構成です。RAM 8GB構成だと割と整備済製品や店頭販売品があるのですが、さすがに8GBはないだろうと。RAM 8GB構成だとSSDのSwapが激しいとのことなので避けてみましたが……実際に動かしてみないとなんとも言えません。

SSD 256GBでは「悪い冗談」、SSD 512GBだと「いまと同じ」、SSD 1TBぐらいが実用上の最低ラインだと判断しました。ポート数が少ないので、ディスプレイ以外で接続しておく周辺機器は最低限のものにとどめておくべきマシンでしょう。

YouTubeをはじめとして各種ベンチマークが掲載されていますが、正直なところムービー書き出しとかゲームやベンチマーク専用ソフトの結果ばかりで、実際に一般的なアプリケーションを動かして、アプリケーションをAppleScriptから操作してゴリゴリにコキ使ったときのパフォーマンスはどこにも載っていません。

Script Debuggerで巨大なScriptを編集すると、文字入力が止まるぐらい遅くなるので、Script Debuggerの操作が軽くなることを期待したいです。

以前に開発用にiMac Proを一時的に預かっていたときにすこしだけ自作ベンチマークをとってみましたが、あれよりも突っ込んだ内容は実験できることでしょう。iMac Proはいいマシンでしたが、（MBPR 2012よりも）３〜４倍ぐらい高価なiMac Proでも1.5倍ぐらいのシングルコア性能で、コストパフォーマンス的にはいまひとつでした。つまり、高い割にたいしたことがない、という印象。

M1 Mac miniにはとても期待しています。

M1 Macでベンチマークをとってみたい処理

・巨大な配列を使う処理
与えられた文字列の1D Listのすべての順列組み合わせパターン文字列を返す v3
→ これは、M1 Mac上でとくに遅い処理で、心底ガッカリしました。この挙動は問題ありすぎなので、Appleに報告して対処してもらえるよう「お願い」をしています

２点間の距離を求める v3
→ 全国のゲームセンターの最寄りの鉄道の駅を求める
→ 2012年のMacBook Proのほうが10倍速いです
・画像処理
画像の空白判定 v4
→ これは、2012年のMacBook Proより高速でした

画面スナップショット超解像バッチ処理 v1
→ M1内蔵のニューラルエンジンを利用しているためか、これはM1 Macが圧倒的に高速です
２つの画像が類似しているかを判定

ghostscriptによるPDFの圧縮・軽量化処理
→ MBP 2012で数分から10分ぐらいかかっていた処理が、１分ぐらいで終わるので速いと思います。ただし、瞬時に終わるとかいうことはありません

・アプリケーションとのやりとりが膨大で重い処理
Mail.appでメールボックスの仕分けを行う（最重量）
→ これは、Intel Macとさほど変わりません。ただ、Mail.appの起動がアホみたいに速い（起動してから操作可能になるまでのタイムラグがほとんどない）ので、その点だけでもM1のトータルなシステムとしての速さを実感できます
CotEditorのウィンドウを楕円運動
→ M1のほうが少し速いか？　ぐらいで、全般的にこの手のScriptはMBP2012の10倍遅いことを覚悟する必要があります
・AppleScriptで組んだGUIアプリケーションの動作
Kamenoko
→ ±ゼロぐらい。しばらく動かしていると動作が止まる瞬間があって、強制終了させたりしています
・重いアプリケーションの動作
巨大なScriptをScript Debuggerでオープンして編集したときの動作
→ Intel Macに比べて速い、ということは感じません。この用途でいえばiMac Proの方が快適かも？

JavaScriptで書かれた68k Macエミュレータの新規軸「macitosh.js」が登場してきたので、SheepShaverと対決させてみました。

macintosh.js–Classic Mac OS 8 on Mac mini 2014 2.6GHz Intel Core i5 macOS 11.5
SheepShaver–Classic Mac OS 9.2 on MacBook Air mid 2011 1.6GHz Intel Core i5 macOS 10.13.6

それぞれ、Mactracker上に記載のあるGeekbenchのベンチマーク値は以下のとおりです。

ベンチマーク対決内容はAppleScriptで1,000万回単純ループを行うものです。

結果：macintosh.js 191秒

結果：sheepshaver 10秒

古いSheepShaverのほうが新しく作られたmacintosh.jsよりも20倍ぐらい高速、という結果が出ました。だからダメということはなく、JavaScriptなどという処理系でここまでネイティブコードに肉薄したということに驚きます。

シングルコア性能でMac mini 2014のほうが倍ぐらい速いのですが、さすがにネイティブコードでエミュレータを動かしているだけあって、MacBook Airのほうが10倍ぐらい高速です。同一マシンでベンチマークしたらsheepshaverのほうが20倍ぐらい高速でしょう。

macintosh.jsにはM1対応版（っていうのか？）もあり、M1 Mac miniで動作させればMac mini 2014の３倍ぐらい高速ですが、それでもMacBook Air上で動かしたsheepshaverのほうが３倍高速ということになります（多分）。

ちなみに、現代のIntel Mac（およびARM Mac）で1,000万回程度の単純ループを普通にAppleScriptで実行させると、速すぎて１秒以下になってしまい計測不能。1億回ぐらい回さないと１秒以下です（10億回ぐらい回さないとダメかも）。PowerPCの時代には1,000万回単純ループが計測の（個人的な）指標になっていました。

▲M1 Mac mini+Macintosh.jsで実行したら68秒。だいたい予想どおり

▲M1 Mac mini+SheepShaver（Universal Binary）で実行したら10秒。MacBook Air 2011＋SheepShaverと同じ結果に

いまからはじめるプログラミング②を書いていていろいろ新情報を見つけてしまいました。

すでにご存知の方もいるかもしれないので、「この俺がぁぁぁぁ、世界でぇぇぇぇ、一番に見つけたァァァァァァ！！！」と主張するわけではありません。「そういえばそうだよね」ぐらいの印象のものです。

長年deprecatedだと表示されてきたけど、そろそろそんな気がするinfo forコマンド

誰もがファイル情報の確認時に雑に使っているStandardAdditions.osax中の「info for」コマンド。長年「deprecated」扱いになっていました。

そんなにdeprecated感はなかったのですが、macOS 11上で使ってみるとその遅さにめまいがしました。

System Eventsでfileのpropertyを取得したほうがはるかに高速で、さすがにもうinfo forを用例で引き合いに出すのは無理があるなと感じました（②巻のリリース直前に気づいて書き直した次第です）。

ファイル処理は完全にCocoa系の機能を使ったほうが速くて強力なので、最近はまじめに深掘りしていなかったのですが、入門者向け本を書いてみて気になりました。入門者向け本にCocoaのコードはさすがに書けません、、、、

as alias listはないけれど……

Finderからまとめてfileを取得する際に、「as alias list」という用語が使えます。通常はfileなりdocumentなりのオブジェクトをlistで返してくるFinderですが、aliasで結果がほしい（ファイルパス情報だけほしい）というケースが多々あります。

それに応えるかたちで「as alias list」が、たしかMac OS X 10.4あたりで新設されました（selectionからファイルをとってくる処理が、えっらく簡単になった記憶があります）。

その後、Mac OS X 10.6あたりで（？）System Eventsにファイル関連のSuitesが新設され、「あー、こりゃFinderのないOS環境、ワンチャンくるかも？」と怯えていたのですが、さすがにFinderを廃止すると反発が大きいという判断をしたのでしょうか、「FinderレスMac OS X環境」という世界観はやってきませんでした（iOSあたりはそういう感じですけれども）。

で、System Eventsにファイル関連のSuitesができても「これ本気で使わせたり移行させたりするつもりがあるんか？」という雰囲気で、Finder上で行っていたファイル処理をそのまま移し替えられる様子ではなく、速度面でも腰が抜けるほど速いわけでもなく、Appleのエンジニアリングチームが何を考えているのか意図を測りかねていました。

指定フォルダ内のfile一覧をaliasで取得しようとして、

set aFol to choose folder
tell application "Finder"
	set aRes to every file of aFol
end tell

という処理を、

set aFol to choose folder
tell application "System Events"
	set aRes to every file of aFol
end tell

と、書き換えて、ふとaliasで欲しいと思って、

set aFol to choose folder
tell application "System Events"
	set aRes to every file of aFol as alias list
end tell

などと書いてみてもエラーに（知ってたけど）。そこで、冗談半分に、

set aFol to choose folder
tell application "System Events"
	set aRes to every alias of aFol
end tell

と、書いてみたら………期待どおりの動作に。aliasのlistで結果が返ってきます。

log on/log offってあったよね？　ねえ、あったって言って

ログ（履歴）出力用のlogコマンド、そのログ出力を許可/禁止するlog on/log offコマンドがClassic Mac OSの時代には存在していま……

魔が差して、Classic Mac OSエミュレータ「SheepShaver」を起動してClassic Mac OS 8.6上で確認してみたら……

あっれえええええ？？？
log on/log offコマンドが存在していないよ？

現行のmacOSで確認されている（でも、AppleScript Language Guideに書かれていない）「start log」「stop log」を書いてみたら……通りますね。

当時流通していた何かのOSAXで提供されていたコマンドだったのか、ちょっとショックです。

駄目押しで、1999年に作成された「AppleScript Language Guide」で「logコマンド」まわりを確認してみたら「start log」「stop log」がある！！！

自分の「薄い資料集」を書き換える必要がありますね。
まー、気づいたのでヨシ！（よくない）

われながら、よくもまあこれだけド派手に間違ったもので。修正方法もいろいろ考えなくてはなりませんね。

なんといいますか、現在では現役ではないプラットフォーム（Classic MacOS）に関する言及の部分なので、しれっと「そんなことはなかったよ」という顔をして修正するのもアリなんですが、個人的にショックです（FileMaker選手権で落ちたときよりは大きくないですが）。

しばし放置しつつ、様子を見てみましょう、、、、
→ 相談したら、「誰も気にしてないので直せばいい」とのこと。直しておきました。すでに購入された方は再度購入ページからダウンロードしてください。