  |
はてなキーワード: オーバーヘッドとは
一方、僕が集めてきたプログラマーはプログラミング未経験の頭の良さそうなネットゲーマーだけです。
なので初期のドワンゴは、森さん率いる天才ハッカー集団からなる超強力な開発チームと、僕の率いる廃人ゲーマーによる即席プログラマーメインの弱小開発チームの二つからできてました。
僕と森さんで最初に考えたドワンゴのビジネスモデルは単純で、優秀な僕ら（といっても森さんチームだけですが）は控えめにいっても普通の開発会社の半分以下の工数でソフトウェアを開発できる。
なので、実際にかかる工数の2倍で見積もりを出せば、半分は利益で丸儲けのはずだ、というものでした。
とても簡単な算数ですが、後から振り返るとそこが「理系のずるさの限界」でした。
僕らはドキドキしながら2倍の見積もりを出したんですけど、本当は10倍ぐらい出すべきでした。じゃないと儲からない。実際は想定よりも工数がかかることがあり、2倍じゃ利益出なくてめちゃくちゃ大変です。
ドワンゴが大きくなってから当初のドワンゴぐらい実力があって良心的な下請けが欲しいと、心から思いました。当時のドワンゴが出してた見積もりのさらに2倍の金額払っても、同等の仕事をしてくれる下請けなんて、なかなか見つかりません。
でも、文系経営者の中には平気な顔して100倍の見積もりとか出せる人もいたんですよね。僕らの感覚ではもはやそれは詐欺で、とてもできない。
日本はまだまだ欧米に比べて遅れた価値観や労働環境であるのはいうまでもない。
それは民主主義が根付いて短いのと、そもそも自分たちで民主を勝ち取った経験がないからである。
それは置いておいて、それでも最近はコロナを経由したということもあり、
ITツールの活用や、システム化をすることによる効率化が目指されてきたのがこの4年間である。
その結果として「属人化」「人に集約するナレッジ」が忌避されるようになってきた。
つまり、「この件はあの人に聞けばいい」が無くなってきているのである。
すると何が起きるか。ナレッジは人ではなくシステムに集約されているので、人が人に経験なりナレッジをトランスファーするために生じるオーバーヘッドがなくなる。
そのオーバーヘッドのひとつに、パワハラやモラハラやセクハラがあったのであろう。
「ハラスメントがひどいけどこの人に聞くしかないから我慢しよう」がない時代になってきたといえる。
そんな傾向はこれからも加速するだろう。
つまり、これからもまだパワハラ・モラハラ・セクハラといった〇〇ハラをするような人間は前時代的な人間とされ、
未進化の「土人」扱いされるリスクが高くなってくるわけである。
https://anond.hatelabo.jp/20231014043358
についての
https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20231014043358
のお話です。増田は自称財務省主計局の元中の人だけど、ホントかどうかの判断は自己責任でよろしく。
参考資料の学級規模と教員一人当たりの生徒数のギャップを見る限り先生余っているはずだけど公立の学校見ているとどうも余っている様子は全く見られないのなんでなんだろうなあ
足りないのは事務員なんだよね。自治体予算には限りがあって教育分野でも削らざるを得ない、でも教師の雇用・処遇は相対的に守られてきてそれほど減らせない、となると他の部分にしわ寄せが行って、事務員が足りなくなった分、教師が事務仕事をこなすことになって多忙になると。人件費単価は教師より事務員の方が低いから、教師の枠を事務員に振り替えれば、学校の従業者数を増加させることになって職場環境は改善できるんだろうけど、世の中うまくいかないよね。
とりあえず予算を査定する側とされる側が対等にバトルしているという幻想は捨てよう。実際、他省庁が財務官僚に「査定のお願い」に行く際、財務省側は二ランクか三ランク下の官僚が相手をする程の権力差がある。
よくある財務省ツエー論の根拠の一つとして挙げられる話だけど、実態は全然違います。９月の最初のヒアリングは、要求を網羅的に聞くから各課の課長が主査（課長より２ランク下の課長補佐クラス）に説明するけどーー各担当補佐が説明するとなると、ヒアリング日程の調整やヒアリング現場での説明者入替え等のオーバーヘッドがかさむんですよーー、その後は普通に主査と補佐で議論してるからね。まあ各省庁の文化の違いや課長のキャラで補佐に下ろさず課長が出てきがちな場合もあるけど、少なくとも主計側から「主査は補佐を相手にしない、課長を出せ」なんてことを強いているわけではありません。
ともあれここ数十年財務省の力が強くなり過ぎているのが国力を削ぐ結果に繋がっているので、財務省は分割解体されるべきである
こうした主張、はてブに限らずいろんなところで見るけど、なんで一定の説得力を持っているのかさっぱりわかりません。だって大蔵省・財務省にとっては、ここ数十年、国債残高を減らすことが悲願なわけですよ。で、それを一度たりとも成し遂げていません。バブル末期に赤字国債脱却はできたけど、その間も建設国債は増えていて残高は右肩上がり、バブル崩壊後はご覧のありさまですよ。増田は個人的には国債残高減少を金科玉条として目指すことには批判的ですが、だからこそ、財務省が悲願を実現するだけの力がない弱っちい役所でよかったなあ、としか思えません。
補正予算になると精査もせず30兆ぽんと出し、剰余金を一般会計に繰り入れて好き勝手に使う財務省。文科省にだけは強気だけど、他の省庁にもちゃんと物申したらどうですか。大蔵省の頃はやってたと思うよ。
農水省や国交省の中の人たちからすれば、文科省はうらやましい限りだと思うけどなあ。増田は主計局を離れてそこそこ経つので、例えば最近の防衛費増の受け止めはわかりませんが、増田がいた頃は、文教費は、社会保障や地財と並んで扱いが難しい予算だ、というのが一般的な認識だったと記憶してます。文教族は政治力強いからねえ。
Photoshopのタイル構造はどのように実装したら良いですか？何か参考になるソースコードなどはありませんか？
Photoshopのタイル構造は、画像を小さな矩形のブロックに分割して、各ブロックを個別に処理することで実現されます。これにより、大きな画像の処理を高速化することができます。
このアルゴリズムを実装するには、以下のような手順が必要になります。
画像を読み込む
処理が完了したら、結果を保存する
以下は、Pythonで実装された簡単なタイル構造のコード例です。この例では、画像を単純にグレースケール化しています。
import numpy as np from PIL import Image # 画像を読み込む im = Image.open("input.jpg") # タイルのサイズを決定する tile_size = 128 # 画像をタイルに分割する tiles = [] width, height = im.size for y in range(0, height, tile_size): for x in range(0, width, tile_size): box = (x, y, x + tile_size, y + tile_size) tile = im.crop(box) tiles.append(tile) # 各タイルを個別に処理する for i, tile in enumerate(tiles): tile = tile.convert("L") tiles[i] = tile # 処理されたタイルを結合して、元の画像を再構築する output = Image.new("L", (width, height)) x = 0 y = 0 for i, tile in enumerate(tiles): output.paste(tile, (x, y)) x += tile_size if x >= width: x = 0 y += tile_size # 結果を保存する output.save("output.jpg")
このコードは、Pillowを使用して、画像の読み込み、タイルの分割、処理されたタイルの結合、結果の保存を行っています。このコードを改良することで、より高度な画像処理アルゴリズムを実装することができます。
回答ありがとうございます。しかし、実際にはこれに拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などが加わります。拡大縮小は画像ピラミッドのようなもの、メモリ以上の巨大な画像を扱えるのはmmapを使っているのではないかと予想しています。これらを一言で回答するのは難しいと思いますが、何かアドバイスをいただけないでしょうか。よろしくお願いいたします。
拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などを実装するためには、より高度なアルゴリズムとテクニックが必要になります。
拡大縮小に関しては、画像ピラミッドを使用することで実現できます。画像ピラミッドは、複数の解像度レベルで同じ画像を表現する方法です。画像ピラミッドを使用することで、拡大縮小のプロセスを簡単かつ高速に行うことができます。OpenCVやPillowなどのライブラリは、画像ピラミッドを構築するための機能を提供しています。
タイルを跨いでのコピー＆ペーストは、オーバーレイ技術を使用することで実現できます。オーバーレイとは、複数の画像を重ね合わせることで、新しい画像を生成する技術です。タイルを跨いでのコピー＆ペーストは、オーバーレイを使用して、複数のタイルを重ね合わせることで実現できます。また、透明度を使用することで、重ね合わせたタイルの一部を透明にすることもできます。
ペンツールでの描画に関しては、画像のピクセル単位での操作が必要になります。これは、OpenCVやPillowなどの画像処理ライブラリを使用して実現できます。画像のピクセル単位での操作には、色の変更、描画、消去などが含まれます。これらの操作を組み合わせることで、複雑な描画機能を実現することができます。
最後に、メモリ以上の巨大な画像を扱うために、mmapを使用することは可能です。mmapを使用することで、ファイルをメモリ上にマップし、ファイルと同じようにアクセスすることができます。これにより、ファイルがメモリに収まらない場合でも、ファイルの一部をメモリにマップし、必要な部分だけを読み書きすることができます。ただし、mmapを使用する場合は、適切なメモリ管理が必要であり、オーバーヘッドが発生する可能性があるため、十分なテストと調整が必要です。
Dockerは、開発から運用まで一貫した環境を提供することで、開発者の作業負担を減らすという大きな利点があります。また、仮想マシンと比較してリソースの使用効率が高いため、エコとも言えます。
ただし、確かにDockerには一定のオーバーヘッドが存在します。これは、DockerがゲストOSを持たずに、ホストOSのカーネルを共有して動作するためです。それにより、アプリケーションの実行に必要なリソースが追加で必要になり、パフォーマンスに影響を及ぼす場合があります。
また、Dockerを利用する際の設定や構成によってもパフォーマンスは大きく変わります。例えば、Dockerのネットワーキングやストレージの設定、またホストOSとの互換性など、考慮すべき要素は多数存在します。
あなたの現在の状況について具体的に述べると、FESSのクローリングが重いという問題は、Dockerのオーバーヘッドだけが原因ではない可能性があります。Dockerコンテナ内のFESSやJVMの設定、ホストマシンのリソース割り当て、ネットワークやストレージの設定など、様々な要因が絡んでいるかもしれません。
また、Dockerのログ出力が多いと感じる場合も、実際のところはFESSやDockerの設定によるものかもしれません。ログの出力レベルを調整することで、必要な情報だけを出力するように設定することも可能です。
しかし、これらの設定を調整するためには一定の知識と経験が必要で、それがなければ素直にネイティブ環境での構築が良い選択かもしれません。結局のところ、どの方法が最善かは具体的な要件や状況によります。
このような状況に直面した際には、パフォーマンスの問題を具体的に分析し、適切な解決策を見つけるためにパフォーマンスモニタリングやロギングツールを使用することをお勧めします。それにより、問題の原因を特定し、適切な対策を講じることが可能になります。
たとえば、Dockerが高いCPU使用率を示している場合、それはコンテナ内のアプリケーション（この場合はFESS）が高いリソースを消費している可能性があります。その場合、アプリケーションの設定や実行パラメータを調整することで改善できるかもしれません。
また、Dockerコンテナのリソース制限を調整することも検討できます。Dockerは、コンテナに割り当てるCPUやメモリの量を制限する機能を提供しています。これにより、他のプロセスに影響を与えることなく、特定のコンテナのリソース使用量を管理することが可能です。
さらに、Dockerのボリュームやネットワーク設定が適切であるかを確認することも重要です。不適切な設定はパフォーマンスに悪影響を及ぼす可能性があります。たとえば、ファイルI/Oのパフォーマンスは、ホストOSとコンテナ間でデータを共有する方法に大きく依存します。そのため、適切なボリュームの設定や、パフォーマンスを向上させるための最適化オプションが適用されていることを確認することが重要です。
最後に、Docker自体のアップデートもパフォーマンス改善に寄与する場合があります。最新のDockerエンジンには、パフォーマンスを改善するための修正や改善が含まれていることがあります。
これらの要素を考慮に入れ、Dockerのパフォーマンスを最適化する方法を探すことができます。ただし、これらすべてを試してもパフォーマンスが改善しない場合や、必要な知識や時間が不足している場合は、Dockerを使用しないネイティブな環境での構築が最善の選択であるかもしれません。
そりゃそうなんだろうけども。そんなに？
追記：FESSをOSに直接インストールするのに参考にしたというよりコピペさせてもらったのは以下の記事
https://qiita.com/hyoshiaki/items/598127fe30b94bd82b6e
半年前に辞めてしまった前任者から存在すら知らされていない客先のメールアカウントが必要になった。
無いならないであきらめてもらえるんだが、僕は優しいのでファイルサーバに無いかくらいは確認しようと思ったが
なので昔うっすら使ったことのあるFESSで全文検索しよう、多分txtかxlsだろう。
とウェブサイトで構築方法を見ると今はDockerで動かすのが良いらしい。何がいいか知らんが。
ドキュメントに従いインストールし、なんとかクローリングまで実行できたが、重い。重すぎる。
サブフォルダ無しで100ファイルくらいのフォルダでも2，3日回しても終わってない。
CPU使用率が50%超えてるんだよ！ってログが出まくっている。そのログ出力無駄じゃない？
使えないかー、とググってみるとDockerではなく素で構築する方法を有志の方が書かれているのを発見。
それに従い構築。するとサブフォルダ5階層くらいのフォルダが3分くらいで終了。
ログにCPUがーっていうのも出てないわけではないが、明らかに少ない。なんだこれ。
Dockerは構築楽らしいしVMよりエコだっていうのは聞いたことあるんですが、
素のOSに入れるよりはどうしてもオーバーヘッドあるんですかね、というのが今回の教訓でありました。
自分が副業で貰ってるより良い報酬で自分より圧倒的に能力が低い人が来ると凄くモヤっとする
例えば自分は時給5000円なのに雇ったヘボプログラマーは時給8000円、みたいな
（手数料が10%引かれてるはずなので実際には7000円ぐらいが収入なんだとは思ってる）
かといって安い報酬だと良い人がこないので渋々契約するんだけど
タイトル通り、副業で本業をやる方が会社としても個人としてもハッピーなんだよな
うちみたいなぬるい会社でショボい案件のプログラム作るだけで高報酬とかマジで天国だし
契約処理とか諸々がいらないからオーバーヘッドもかなり削減できるんだよね
かといって自分が本業でそのプログラム作っても給料は一円も上がらないし経済回らないからやらない
なんかその辺の事情を分かってるのか、人事部あたりが去年あたりに
「本業とは別の仕事をできるし、二つ合わせて7.5時間ならOK」
「業務時間は7.5時間だけど業務量が2倍になるから給料は2倍」
ぐらい言ってくれたら喜んでやってあげたのに
あと、自分の副業の報酬を上げればいいかというとそうでもなくて、単純に仕事を取りづらくなる
例えば月収を5万上げるといきなり応募できる案件が半分以下になる
じっくり待って仕事を探せばいいのがあるかもしれないけど機会損失が大きいからさっさと仕事を探してくるのがベストだと思ってる
いや、ベターか
入社しばらくしてからずっと、仕事への抵抗感がすごすぎて人の目のないところでは常時頭かきむしって手足バタバタさせながら無意味にAlt+Tabを連打して無駄に時間を浪費してる。
これどうすれば治るんだ？仕事って行為そのものが向いてない気がする。
自分なりに考えたんだけど、なんか考えても無駄な『無意味な仕事に対して湧いてくるイライラ』みたいなものへの抵抗力が極端に低いんじゃないかと思うんだよな。
でも無意味に感じる仕事とか、サラリーマンってそんなもんか。もう最近はなにもわからん。イライラしすぎて今日も無駄に有給使ってしまった。
ぼかしてるから全然意味不明だと思うけど、今の業務の不満点みたいなものを書きなぐってみた。
現状の職種としては対法人なんだけど、「現場の営業にあらゆる業務プロセスの不備の後始末が任される構造になってて、同担当の先輩見ても業務時間の2割も客とやり取りしてないのマジで意味が分からんなぁ」とか考えてると、目の前のこなすべき事務作業も全然捗らずにストレスだけが溜まってしまう。
なんというか自分の本業(対顧客)に力を注げるまでのオーバーヘッドがでかすぎて、一周回って自分が何やってるかわからなくなってくるんだ。
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
みたいな感じなんだけど、言語化できるだけまだマシな部類なんだよな。こんなんが何十種類もあって、担当内の誰もわからなくてナレッジがあつまるような場所もないから毎回手探りで対応して、それぞれに毎回イライラしてる。
上の一個一個の作業は大した手間じゃないけどこれが1人当たり5,6社(部門)×各2～4案件くらい並走してるので、ワイの貧弱なワーキングメモリが悲鳴を上げてる。
というか客に関係あるの最初と最後だけで、極論、間に挟まってる作業は社内で自動化できるはずで、俺が手作業で丹精込めてやってる意味なんもない気がする。
でも間の作業で規定から外れるとまたその修正作業が増えて余計に手間が掛かるので、客とのやり取りを雑に済ませて社内用excelマクロを延々ポチポチしつつ、社内他部門へのメールを連打している。
これに加えて、例えば「各部署内で事務作業の効率化を図りましょう！」とかお達しがあってRPAのライセンスだけ渡されて、通常業務の片手間でシナリオ作って効果検証して提出みたいなことをやらされたりもする。(そもそもの業務が全然定型的に組まれていないのでシナリオ作りも大変苦痛)
もっと腰を落ち着けて業界の情報取集したり客の要望引き出したり提案練ったりそのための社内調整したりしたかった。
なんだかんだ業界トップのクソデカ企業だし、まがいなりにもITだDXだとか言ってるからもう少しマトモな仕組みがあるのかと思ってた。
何の意味もない作業に時間を取られて、何のスキルも身につかないまま無為に時間と精神を削られるのもだいぶつらい。
ただ、普通に考えて自分でどうにもできない部分は「仕事の効率が～」とか喚いてないで何も考えずにこなすしかないし、逆に「運と相性が悪かったから評価最低でもいいや」と割り切って異動のために勉強に時間割くとか、そんな感じで開き直れもせずにウジウジしてるのは単に自分が無能で仕事にも向いていないからとは思う。
わからんなにも。どうしたらいいんだろう。
以下、ボクの考えた最強の iPad Pro
強化されたタッチパネルにより、どんな金属芯のプラスチック棒も Apple Pencil 2 並みの入力デバイスに変わります。
最新の AI技術を iPad でも。オープンな自動画像生成の力をあなたの仕事に取り入れましょう。
熟練のプロにさらなる力を。すべての UI アニメーションを短くして、あらゆる操作が魔法のように素早く。
Thunderbolt4 で接続すれば、あなたの許可で、iPad を外部ディスプレイに変えられます。
接続したコンピュータから一般のストレージのように自由にアクセスできます。
iOS subsystem for Linux の登場です。歴史ある GNU/Linux のユーティリティをオーバーヘッドなしで利用しましょう。
指に馴染んだ USBキーボードが、最新技術で生まれ変わります。
今年の新しい iPad はありません。その代わり、従来のiPadが＄200 安くなりました。
まったく新しいワンチップコンピュータ apple chip は iOS の基本部分が動きます。＄10 です。最先端の技術と一緒に、電子工作の世界を探索しましょう。
小学校時代にキャプ翼のTVアニメが始まったら部活に女が急増したり、Jリーグの選手が「キャプテン翼読んでサッカー始めました」って言ってるのを知ってるから別に低評価だと思っていない
それはそうと
・東邦学園のキーパー若島津が右肩を怪我したってチームに打ち明けた後、DFが「俺たちが頑張って若島津の怪我をフォローするんだ！！！」MFが「追加点を取って若島津を安心させてやるぞ！！」って叫んでたら南葛が怪我した方を集中的に狙ってきて、「どうやら南葛が若島津の怪我に気づいたらしい（←さっきお前らが全力で叫んでた」って展開とか
・翼がダイビングヘッドでシュート決めた時に実況が「翼君のオーバーヘッドーーーー！！！！！」って叫んでたと思ったら、次週の頭で作者が「ダイビングオーバーヘッドシュート」というオリジナル技の解説をするとか
CPUのクロックは微妙に速くなっているがシングルコアの性能はほぼ変わらない。
マルチコアになったとして、ThreadripperのようにIOダイを使って大きくしても、劇的に速くならない。
3D V-Cacheで積層してキャッシュを増やしても、アプリレベルでは劇的に速くなってない。
更に積層するのはあるかもしれないが、熱問題に対する解決策がないので出来ないでいる。
UCIe規格経由で複数のチップレットを接続するのが今後出てくると思うが、どれだけ専用の回路を搭載し利用するかで処理能力は変わるが、
Apple M1 UltraのようにProResの本数が増えても使いこなす人が居そうにないというのと似たことになりそうじゃないか。
GPUのように広帯域のHBM/GDDRと、データ依存性がない場合は処理能力高くなるが、
CPU側のメモリーとGPU側のメモリーとのコピーやらオーバーヘッドが合ったり、ゲームがAIの一部といった感じだし、
ゲームもベンチ上は数字が変わるが体感変わらねーなってのに金額が高くなるのもな。
ユニファイドメモリーにするとApple M1系のように性能でないしさ。
レイテンシは変わらないし、DDRの代わりになるものも出て来てない。
インテルがフォトニクスに注力してたり、日本の半導体戦略でもフォトニクスとしてが上がっていたりするが、
光は早いようで遅く、メリットだと低電力か発熱源の分散でしかない。
HPEがフォトニクスで先行していたが、処理能力というより、発熱源分散での設計のし易さアピールだった。
DPU(データ プロセッシング ユニット)、OPU(Optical Processing Unit）はスパコンやクラウドでは追加されるかもしれないが、
パソコンにはまだ遠そう。
DVDが不要になり5インチベイがなくなり、SATA SSDがなくなって2.5インチベイもなくなり、
ちょっとずつパーツ買って性能上げるなんてことはなくなって、全部とっかえ。
もう少しなんとかならないか。
CPUのクロックは微妙に速くなっているがシングルコアの性能はほぼ変わらない。
マルチコアになったとして、ThreadripperのようにIOダイを使って大きくしても、劇的に速くならない。
3D V-Cacheで積層してキャッシュを増やしても、アプリレベルでは劇的に速くなってない。
更に積層するのはあるかもしれないが、熱問題に対する解決策がないので出来ないでいる。
UCIe規格経由で複数のチップレットを接続するのが今後出てくると思うが、どれだけ専用の回路を搭載し利用するかで処理能力は変わるが、
Apple M1 UltraのようにProResの本数が増えても使いこなす人が居そうにないというのと似たことになりそうじゃないか。
GPUのように広帯域のHBM/GDDRと、データ依存性がない場合は処理能力高くなるが、
CPU側のメモリーとGPU側のメモリーとのコピーやらオーバーヘッドが合ったり、ゲームがAIの一部といった感じだし、
ゲームもベンチ上は数字が変わるが体感変わらねーなってのに金額が高くなるのもな。
ユニファイドメモリーにするとApple M1系のように性能でないしさ。
レイテンシは変わらないし、DDRの代わりになるものも出て来てない。
インテルがフォトニクスに注力してたり、日本の半導体戦略でもフォトニクスとしてが上がっていたりするが、
光は早いようで遅く、メリットだと低電力か発熱源の分散でしかない。
HPEがフォトニクスで先行していたが、処理能力というより、発熱源分散での設計のし易さアピールだった。
DPU(データ プロセッシング ユニット)、OPU(Optical Processing Unit）はスパコンやクラウドでは追加されるかもしれないが、
パソコンにはまだ遠そう。
DVDが不要になり5インチベイがなくなり、SATA SSDがなくなって2.5インチベイもなくなり、
ちょっとずつパーツ買って性能上げるなんてことはなくなって、全部とっかえ。
もう少しなんとかならないか。
MATLABを使っているが、どうも中途半端な存在になっている。
①言語的な競合はもちろんPythonになるが、Pythonとの差別化が出来てない。
Python側は純粋なPythonだと遅いが、今はC++のラッパーとして使うのが多くなっており、Pythonの方が速いということが起こる。
最近のMATLABはJITコンパイラによって昔ほどfor文を気にしなくても良くなっているが、それでも遅さは気になる。
GPU、分散コンピューティングにMATLABは対応しているが、使いこなすのに苦労する。
GPU使う場合だと、CUDAをそのまま使いたくなるし、GPUメモリーとのやり取りといったオーバーヘッドが加わるので、
単純にGPU使うようにしたら速くなるってことはなく、処理時間を測りながらトライアルを繰り返すことになる。
MATLAB側のエディタは機能が増えているとはいえ、Python+VSCodeとの対抗となると辛いものがある。
toolboxを追加で課金してCコードを吐き出すことはできるが、劇的に速くなるわけではない。
②toolboxは沢山あるが、使い始めると色々足りておらず、Pythonのエコシステムが欲しくなる
toolboxが多くなりすぎていることと、手を広げすぎているのかtoolboxを買って使ってみると色々足りないことがある。
買う前に調べるわけだが、色んな事ができそうだと思って購入し、実際使っていくと、嘘は言ってないが事あるごとに使いにくい所が出てくる。
GUI周りに関しては不満が多い。
③GUIが重い、使いにくい
事あるごとにGUIが重たいのが気になって仕方ない。
また使いにくいのが多い。デザインが良いというのはコンシューマ用ではないので気にしないが、重たさと使いにくさで嫌になってくる。
④plotや可視化周りが重い
エクセルが普通になっている今、エクセルで出来ないことが出来て欲しいが、そうなっていない。
インテルやAMDなどのCPUと、NVIDIAなどのGPUとの間の接続はPCIeが速くなってきたとはいえ、
双方向にデータのやり取りが発生するような場合は帯域の狭さがネックになる。
ゲームのようにGPUに投げっぱなしにして、GPUとGPU側のメモリー、そしてディスプレイへの出力だけで閉じても大丈夫な場合は問題にならないが、
世の中そういうアプリケーションだけではない。
GPUカードが高くなっているのにも関わらず、CPU側のメモリーとGPU側のメモリーで似たようなデータをコピーしないといけないという、
なので、「M1 Ultra」のように、CPUとGPU間の帯域が大きく、ユニファイドメモリでCPUとGPUで共通のメモリーにアクセス出来るというのはメリットがある。
インターポーザを介して帯域は確保出来ているが、遠いメモリーへのアクセスへのレイテンシは防ぎ用がないので、
チューニングしようとするとインターポーザを介するメモリーアクセスが発生するかどうかは、プログラミングで気にする必要はあると想像する。
さすがのAppleも最先端プロセスを使う、予約していたTSMCのキャパを使い切る状態にしないといかず、数を出荷しないといかないのだろう。
良品選別したダイをインターポーザで接続して、出荷するチップ数を増やすというのは選択肢としてよかったのだろう。
トランジスタ数も多くなりすぎて、EDAツールで設計する時に必要になるシミュレーション時間も馬鹿にならないはずで、
タイミング検証が済、動くことが保証できている領域があるというのは、段階を踏んで設計するということでも合理的だ。
ただ機能面では、単純に倍になってしまっているため、ProResの本数が増えて、使い切るような状況があるのか？という不安はある。
「M1 Max」でそれなりにバランスを取っているわけで、「M1 Ultra」では多くなりすぎて使われない部分も出てくるだろう。
価格がそれなりに高いので、使われない部分があるというのは、あまり許してもらえないのではないだろうか。
インターポーザで接続する技術は確率出来たので、そこのIF周りは変更せずに「GPUだけ増やしたチップ」と「M1 Max」を接続する
といったのは考えられるが、数がでないといかず、そういうのを作れるかどうか。
他にデスクトップ向けだが低消費電力を売りにしているのは気になっている。
