超電導という現象はそれを引き起こせる温度によって、いくつかの区切りがつけられています。
このとき装置を2日間安定させて観測を行い、理論上コイルを冷やし続ければ、外部電源無しで10万年間も電流を流し続けられる、ということを示したのです。
⇧ コイルが低温状態を維持されていることが肝であると。
そこで、研究グループは、その後、実際に約2年間、この装置の永久電流運転を実施し、高温超伝導接合が長期間に渡って安定的な永久電流を維持できることを実証したのです。
これは電流を供給しなくても300万年も磁場を発生し続けることができることを意味しています。
⇧ 運用が大変そうではありますが、低温状態を維持できる資源が枯渇しない限りは、環境を保つことが可能であると。
一応、
急成長するアジアを中心とした新興国の製造業のヘリウム需要は今後も増大し、その量は2030年までに年間3億立方メートルになると予想されています(2012年の生産量は約1.8億立方メートル)。また世界のヘリウム埋蔵量は約70億立法メートルであり、現在のペースで消費されれば計算上では25年後には枯渇することになります。
何十年も前からずっと「あと40年で枯渇する」と言われ続けている石油と同様、ヘリウムも枯渇が懸念されつつも技術の進歩により"延命"されるのか、今後の行方に注目です。
⇧2013年時点で、消費状況によっては、25年後に「ヘリウム」が枯渇するという話が出ていたみたい。
2013年から25年後というと、2038年になるわけなんだが、「ヘリウム」が枯渇して利用できないってなると、あと、15年の間に
- 「ヘリウム」を人工的に生産する技術の確立・実運用
- 「ヘリウム」を代替する技術の確立・実運用
が必要になってくる気がするんだが、「ヘリウム危機」に対するプロジェクトは進んでいるのかね？
⇧ 研究が止まる可能性も出てくるってなると厳しい気はしますが、「MRI」など医療分野における割合が高いところを見ると、医療崩壊のリスクも有り得てしまうということなんですかね？
日本における「ヘリウム」の必要量がどの程度なのかが分かりませんが、いろいろな資源が枯渇に近付いている状況を鑑みるに、文明の終焉に向かいつつある感じなんですかね？
2500年頃には、日本の人口が0になるとみなされていますが、そもそも、新たな技術が確立されないと、枯渇するとされている資源に依存した技術を活用できなくなるからして、技術的な先祖返りを余儀なくされることが有り得ると。
旧石器時代みたいな世界まで文明が衰退することは流石に無いと信じたいですが...
技術の発展には、資源が必要なんだなぁ、と改めて思った今日この頃。
Pythonで出てくるGIL（Global Interpreter Lock）って何なのか
Wikipediaによりますと、
グローバルインタプリタロック（英: Global Interpreter Lock, GIL）とは、プログラミング言語のインタプリタのスレッドによって保持されるスレッドセーフでないコードを、他のスレッドと共有してしまうことを防ぐための排他 ロックである。インタプリタのひとつのプロセスごとに必ずひとつの GIL が存在する。
プログラミング言語においてグローバルインタプリタロックを採用した場合、複数のスレッドを持つインタプリタプロセスの並行性を制限してしまう。プロセスをマルチプロセッサのマシンで実行させた場合、ほとんどあるいはまったく速度の向上が見られない。
こうしたロックを採用する理由として、下記のものがある。
- シングルスレッドのプログラムの速度向上（すべてのデータ構造に対して別々にロックを獲得・解放する必要がなくなる）
- 通例スレッドセーフではないC言語のライブラリとの結合が容易である。
グローバルインタプリタロックを実装した言語には、下記のものがある:
⇧ とあり、『プログラミング言語のインタプリタのスレッド』に依るマルチスレッドにおける「排他ロック」のことらしい。
で、「GIL（Global Interpreter Lock）」という仕組みが何故に存在するのか？
ただしこれはPythonという言語自身の特性ではなく、C言語で実装されたCPythonに付随するものです。例えばJavaで実装されたJythonは、JVMによるスレッド管理のおかげでマルチスレッド下でも競合が発生しないため、GILが存在しません。
⇧ 上記サイト様によりますと、Pythonというよりは、C言語で実装された「CPython」のライブラリの問題であって、Javaで実装された「Jython」のライブラリでは、「GIL（Global Interpreter Lock）」は存在しないそうな。
「Jython」については、
⇧ Python 3系の進捗が全く不明なので、Python 2系しかサポートされておらず、実質、利用を断念せざるを得ないかと。
ちなみに、
⇧「Py4J」なるライブラリであれば、Python 3系でも利用可能らしいのですが、「並列処理」系の処理が用意されているのかは不明です。
話が脱線しましたが、「GIL（Global Interpreter Lock）」に話を戻すと、
大量データに関するワークロードを、モノリシックに解決する場合、並行・並列処理の知識は活用できます
但し、一般にPythonにはGILが存在するため、正しい挙動を抑えておきたい所です
⇧ 上記サイト様によりますと、「GIL（Global Interpreter Lock）」は、「CPython」に限定される話ではなく、Pythonという全体的な話に関係するというようにも見える。
ちなみに、
他のプログラミング言語で、マルチコアのCPUを利用する際、同時にコア数のスレッドが実行できます。しかし、CPythonでは1つのインタープリタープロセスでは、ある時刻において1つのスレッドしか実行されません。つまり、CPythonのマルチスレッドは完全に並行処理です。その理由はGIL（Global Interpreter Lock）にあります。
⇧ 上記サイト様によりますと、「GIL（Global Interpreter Lock）」が有効になっている場合「並行処理」になるそうです。
上図の通りに処理されるのだとすると、Pythonで「マルチスレッド」な処理を実装したとして、メリットが無いように思えてしまうんだが...
何故、Pythonに「GIL（Global Interpreter Lock）」が導入されたのか
ネットの情報によりますと、
プログラミング言語の設計者が「Python」を設計した当時、コンピュータに複数のコアが搭載されることなど想像できなかった。
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
1980年代から1990年代にかけて、ソフトウェアエンジニアはムーアの法則に大きな信頼を寄せていた。「集積回路上のトランジスタの数は2年ごとに倍増する」というのがムーアの法則だ。そうなれば、当然速度も同じように速くなる。
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
Pythonの生みの親として知られるグイド・ヴァンロッサム氏も、このムーアの法則に基づいて、「将来コンピュータには安価で限界なく高速なCPUが1基だけ搭載される」という、致命的欠陥がある想定の下、Pythonの全てのマルチスレッド機能を設計した。
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
Pythonのグローバルインタープリタロック（GIL：Global Interpreter Lock）は、「全ての操作が単一のコア上で実行される」と想定して構築されている。PC、スマートフォン、マイクロデバイスが複数のCPUを搭載することなど全く想定していなかった。
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
⇧ とあり、当時のハードウェアの構造を元に、ソフトウェアの機能の仕様・設計を決めざるを得ないことから、Pythonにおける「マルチスレッド」の機能についてもCPUが1コアしか利用できない想定の元、設計されましたと。
ただ、
当然ながら、コンピュータのハードウェアは、CPUの速度をどんどん上げていく方向に向かわなかった。チップの設計者は、CPUの速度を上げるのではなく、CPUを小型化し、チップ上に複数のコアを組み込む方向に進んだ。
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
⇧ ハードウェアの進化が想定と乖離してしまったが故に、「GIL（Global Interpreter Lock）」が「技術的負債」となってしまったと。
ヴァンロッサム氏はレックス・フリードマン氏のポッドキャストで次のように述べている。
「『物事を並列に実行しろ』というプレッシャーが突然降りかかった。Pythonのソリューションではそれは機能しなかった。その瞬間にGILの悪名が広がった」
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
そのため、Pythonが生まれてから30年以上たった今、256コアを備えるエンタープライズサーバ上でPythonのマルチスレッドアプリを実行しても、255のコアはアイドル状態のままになる。
PythonのGIL（グローバルインタープリタロック）はソフトウェアにおける世界最大の間違いか：Pythonの並列処理は幻想 - ＠IT
⇧ 上記が事実だとすると、実質、Pythonで「マルチスレッド」を実装する意味が無くなってしまっている気がするんだが...
アジャイル開発とかでも、改修が難しかったということでしょうかね？
と言うのも、ハードウェアのCPUがマルチコアに対応し始めた時点で、Pythonの「マルチスレッド」の仕様、設計、実装を改修することはできなかったのかと。
「ウォーターフォール開発」に比べて「アジャイル開発」は柔軟な対応が可能と歌われていた気がするので、「アジャイル開発」を導入できていれば何とかなったのか気になりますな。
結局、「GIL（Global Interpreter Lock）」は「CPython」のみに対する問題なのか
で、
Summary -- Release Highlights
Python 3.13 beta is the pre-release of the next version of the Python programming language, with a mix of changes to the language, the implementation and the standard library. The biggest changes to the implementation include a new interactive interpreter, and experimental support for dropping the Global Interpreter Lock (PEP 703) and a Just-In-Time compiler (PEP 744). The library changes contain removal of deprecated APIs and modules, as well as the usual improvements in user-friendliness and correctness.
Free-threading:
-
PEP 703: CPython 3.13 has experimental support for running with the global interpreter lock disabled when built with
--disable-gil. See Free-threaded CPython for more details.
⇧ とあり、上記の書きっぷりだと、「GIL（Global Interpreter Lock）」は、Python全体というよりは「CPython」の問題というように読めてしまうんだが...
ただ、ネットの情報が錯綜しており、
- 「GIL（Global Interpreter Lock）」は、「CPython」という限定的な領域の問題である
- 「GIL（Global Interpreter Lock）」は、「Python」の問題である
のどちらの問題なのかがサッパリ分からない...
Pythonのコアな部分における、「CPython」の実装の割合が分からないので何とも言えないが、「CPython」という限定的な領域の問題である、という話であるならば、
⇧ C言語の実装をRustに変換したら、改善されるんだろうか？
話が脱線しましたが、早くも、
⇧ パフォーマンスを測定しておられる方がおり、スレッドが2つ以上であれば、性能の改善が見られると。
結局のところ、Pythonで「マルチスレッド」処理を実現するにあたって、「GIL（Global Interpreter Lock）」の影響を受けないケースはほとんど無いと考えておけば良いんかね？
まぁ、Pythonでのアプリケーションについては、「マルチスレッド」な処理が不要なぐらいパフォーマンス的には困っていないってことなんかね？
「GIL（Global Interpreter Lock）」の影響を排除できない状態だと、「マルチスレッド」を使ってもほとんど効果が無さそうな話があるからして、これまでは、「マルチスレッド」な処理が実現されてこなかったのだろうか？
Python何も分からないマンなので、Python有識者の人に、Pythonにおける最適な実装をご教授願いたいところではありますな。
例の如く、Pythonの学習のモチベーションが上がらないですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
