  |
はてなキーワード: 高速化とは
メインメモリ容量は最低16GBに引き上げられたが、ストレージ容量は最低256GBに据え置かれ、512GBへの増量は30000円と、容量追加の価格も据え置かれた。
まだ発売されていないため、性能のグレードは不明だが、M3 Macbook pro 256GBのSSDの転送速度が3000MB/sに達していないため、PCIexpress3.0相当の接続インターフェースと推定される。
PCIexpress4.0のSSDで、原価率を50%と仮定すると、15000円で512GBクラスのSSDとして挙がるのは、Seagate firecuda。PCIexpress4.0対応としては最高級品で、Macの内蔵SSDにそれほどの性能はない。
いくら何でも高すぎだろう。何より、今や2万を切る値段で売られているミニPCでも256GBは普通で、そんなものと同じスペックからスタートというのもありえない。
Ruby全盛期のちょっと後くらいからWebエンジニアをしているんだけど、React.jsがいろんな意味で扱いにくすぎる
関わっている人にもフロントエンドエンジニア(=React.jsしかやりたくない)が多いので毒気で吐き出しておきたい
ライフサイクルや裏側の仕組みをなんとなく理解していないと使えず無意味に複雑
useEffect一つとっても~~の場合はuseStateでいけるとかTIPS集みたいのがあるけど、そういうウンチクみたいなのわかってないと使いこなせないのは仕事増えてない？
仮想DOMで高速化とか言っているけどライフサイクル理解しないと速度でないよね？いつものプロジェクトそんなにちゃんと書けてる？jQueryで良くない？
ベストプラクティス知っててちゃんと設計しないと改修する工数がすごいことになる
そもそもプロジェクトにおいて作るものは都度変わっていくので完璧な設計は存在しない。なので、設計をきちんとしないとカオスになるのはReact.jsのほうが間違っている
React.jsと別のフロントエンドライブラリ比較するだけで空気悪くなるので正直フロントエンドエンジニアの人の前で話せない話題がある
なぜかフロントエンドライブラリをReact.jsしか許さない人が多いのはなぜ
言うまでもないけどNext.jsの記法はひどすぎる。Remixは良いけどそれならもうReact.jsじゃなくていい
数少ないメリットだったエコシステムだけど、もうReact.jsしか対応していないことなんてほぼ無い
フロントエンドリッチでアクセス数ものすごいサイトを運用するのにフロントエンドライブラリが必要だった時代にReact.jsを開発する必要があったのはわかるけど、もっと便利なフロントエンドライブラリあるし正直時代遅れなのを理解してくれ
Roninとっくにクリアしてるのに感想文まだだったなぁ(´･ω･`) なんやかんや100時間以上やりましたわ
Rise of the Ronin 感想(1日目)
https://anond.hatelabo.jp/20240324192714#
Rise of the Ronin 感想(2〜3日目)
そしてキッズの頃に100時間たぶんやったロマサガ2のフルリメイク、リベンジオブザセブン（体験版)の感想ですのよ
(なお、サガフロがいちばん好きです。アセルスで冒険に出ないでいきなりBOSSに挑んだぜ)
（SQLを渡して）「このクエリを高速化するとしたらどうしますか」
「とあるバックエンドの負荷テストを任されたとするとまず何をしますか」
「モバイルアプリで使える投票システムの開発を任されました。技術構成とおおまかな設計を考えてください。スピード重視のパターンと機能拡張重視のパターンで考えてください。」
「検索エンジンが大量のデータから高速に検索できている仕組みを簡単に説明してください」
（インタビュアーの得意分野のコードを渡して）「このコードは不具合があります。不具合を修正してください。」
クリックデータの集計において、毎回全データに対して集計SQLを実行すると時間がかかりすぎ、一方でバッチ処理で集計結果を保存すると、その後に発生したクリックをリアルタイムで反映できないという問題があります。この課題を解決するためには、以下の方法を検討すると効果的です。
---
---
---
### **3. データウェアハウスとマテリアライズドビューの利用**
---
---
### **5. キャッシュとインメモリデータグリッドの使用**
---
---
---
---
### **まとめと提案**
---
1. **要件の明確化**: リアルタイム性の程度、データ量、システムリソースなどを考慮して要件を定めます。
2. **プロトタイプの構築**: 小規模なデータでインクリメンタル集計やストリーミング処理のプロトタイプを作成し、性能を評価します。
3. **システムの実装**: 選定した方法とツールを用いて、実際のシステムを構築します。
4. **モニタリングと最適化**: システムのパフォーマンスをモニタリングし、必要に応じて最適化やスケールアップを行います。
---
---
ご質問の課題に対して、リアルタイム性とパフォーマンスを両立する方法として、インクリメンタル集計やストリーミング処理の導入を強くお勧めします。これにより、新しいクリックデータを即座に集計結果に反映しつつ、全データに対する集計処理の負荷を大幅に削減できます。
この文にはいくつかの誤解や不正確な記述があります。それらを順に指摘します。
文中で「128Kトークンという巨大な入力コンテキストウィンドウを持っていることになっているが、これは殆ど嘘、ごまかしであり」と述べられていますが、これは事実ではありません。GPT-4の大規模な入力コンテキストは実際に存在し、正確に動作しています。GPTモデルは入力コンテキスト全体を考慮に入れながら応答を生成します。ただし、文脈が長くなりすぎると、特定の部分への依存度が減少し、より一般的な情報に基づく応答が生成されることがあるため、入力全体を「無視」しているように見えることはありますが、これは嘘やごまかしではありません。
2. **「後半が無視される」ことについての誤解**:
文中で「後半については殆ど無視される」と述べていますが、これは完全に正しくはありません。長いテキストを処理する場合、GPTは確かに最初の部分に強く依存する傾向があることがありますが、後半を完全に無視するわけではありません。モデルの動作は、入力されたすべてのトークンを考慮に入れるように設計されていますが、長い文脈の中では情報の重要度が異なる形で処理されることがあります。
3. **「出力を高速化するために適当に回答している」という指摘の誤り**:
GPT-4は、入力の一部だけを読んで適当に回答していると指摘されていますが、これは技術的に誤りです。生成AIモデルは、出力を高速化するために意図的に一部だけを無視するような動作はしません。出力は、全体の文脈を基に応答を生成します。出力の品質や関連性はトークンの数やトレーニングデータによって影響されますが、これは「適当に回答する」とは異なります。
4. **「問題視している人がほとんどいない」という主張**:
この主張も誤解を招く表現です。大規模言語モデルのコンテキスト制限や性能に関する議論は活発に行われており、ユーザーや研究者はその制約を認識し、さまざまな解決策や改善策を模索しています。モデルの制約に飽きたために「誰も使っていない」というのは主観的な意見であり、実際には多くの人々が日々活用しています。
RAG（Retrieval-Augmented Generation）は、外部の知識ベースから情報を引き出して生成に役立てる技術ですが、この文脈で「がんばる」と述べるのは具体性に欠けます。実際にどのように取り組むべきかについて、もう少し具体的な説明があると適切です。
全体として、この文はGPT-4の性能や動作に関していくつかの誤解が含まれており、技術的に誤った結論に導いている部分があります。
例えば、DRMをクラックした本とかを読ませて「なんて書いてある？」みたいなことを聞いてみると分かるのだが、後半については殆ど無視される。128Kトークンという巨大な入力コンテキストウィンドウを持っていることになっているが、これは殆ど嘘、ごまかしであり、出力を高速化するために「渡されたものの前のほうだけ読んで適当に回答する」ということをやってくる。でもこれについて問題視している人をほとんど見たことがないので、とっくにみんな生成AIには飽きていて使ってないんだと思う。
現実的な対策としては、RAGをがんばるか、あるいはテキストを分割して適切なサイズにしてから渡していって最後にその結果を統合するか。それか「OpenAIさんはそのレベルで信用できないことをやってくる」ということを前提にそもそも使わないか。
『電子工業月報 1966年11月号』 日本電子工業振興協会発行
P.19 付表 主要な技術革命の内容一覧
「20年後の世界」ナイジェル・コールダー 赤木昭夫・須之部敏男訳 P.450〜.451
革命の性格 情報処理における革命。つまり、計算能力と通信能力の増大、及び電子技術を応用した記憶装置と情報検索の広範な利用 技術的な側面 電子計算機の高速化と入出力装置の簡便化。国内及び国際間を結ぶ電子計算機のネットワーク。電子計算機ネットワークを利用した（数値コードによる）通信。ミリ波、レーザー光線、通言衛星を利用する通信量の増大。 その具体的な現われ テレビ電話。ダイヤル方式によるニュースと図書の利用。衛星を使って行う気象予報災害予報の国際的組織。 個人への影響 情報の即時入手（家庭にも記憶装置を置くことになる？）政府の監視が厳しくなる？テレビ電話網の使用により業務上の旅行は不要となる。 社会的側面 図書館、書類作製、タイピストの「消滅」。あらゆる分野において電子計算機が広く利用される。ローカル放送の増加。現在のような形式の新聞はなくなる？ 国際的な側面 国際的な即時報道体制。機械による飜訳。通信業界に対する投資の増加（国家企業の進出？）
1984年時点ではハズレも多いけど、現在までに概ね実現している
「ダイヤル方式によるニュースと図書の利用」は、ダイヤル方式じゃないけど99年のiモードかな？
フリーランスでゲームエンジン担当したり調整したりの仕事を今でもやってます。
「ITがつまらなくなった」「ゲーム制作がつまらなくなった」のは違う角度の話も入りますが同意です。
おそらく現在４０歳あたり以降の人たちは「めちゃくちゃコード書けた時代」の人たちだったと思います。
私もめちゃくちゃコード書いてましたし、他人のコードも修正してたし（それでキレられたり１日中討論したりも）、何より車輪の再発明がすごく楽しかった。
Game Programming Gemsが唯一の経験者のナレッジの詰め合わせで、貪るように読んでましたね。懐かしい。
というよりそうでないと生き残れなかった。
何よりもコードを書くのが楽しい、起きてる間は全てコーディング、アーキテクト、新技術の調査に時間を充てるような生き方しか出来ない人たち。
生産性？それよりもテンプレートプログラミング面白くね？意味あるか分からんけど。そういやこのコンパイラいいよね、メモリの使い方上手くてさあ。
プログラミング全般の技術力は、正しい知識を身に着けているかも重要なんですが、それよりも重要なのはライブラリの仕様を覚えるくらい何度も何度もアウトプットすることなんですよね。
DirectXやOpenGLの仕様を追えばだいたい効率的な計算方法や描画手法は身についちゃうので。
技術体系に紐づくものだったり、デザパタとかある程度知っておくものもあるにはありますが、何なら自分で見つけたくらいの方が遥かに理解度が高い。
頭で創るより、実際に書いてコンパイラ通して目で確認するほうが何倍も重要。
3Dゲームの知見がまだまだ日本に足りていない時代、ドラマチックな演出を行おうとしたら別の技術が必要になった。
今の時代では、ただFPS/TPSにすりゃええって回答になっていますが、模範解答として映画しかモデルが無かったんですよね。
しかも日本の画作りは時間を使った画作りより、止め画、見栄を軸とした画が多くて、海外のセンスとはジャンルが違う。
最先端の技術を生業にしていた大手ゲームパブリッシャー、デベロッパーは頭を抱えていました。
なにせ、個人の技術で戦ってきてしまっていた日本では太刀打ちできないことがわかったからです。
すでに海外では映画や映像の最先端の技術者やクリエイターをかき集め、サイエンスとしてナレッジ化を進めていました。
物理学者を集めまくってたのもそのときだったのを覚えています。
結果的に、大手は各社最高のグラフィックエンジンやクロスコンパイルエンジンを自社開発しようとして、（ほぼ）全て断念していますね。
……ただフォローのつもりで言いたいのですが、失敗ではあったと思いますが、そこで得た技術は非常に重要なものでして
日本は失敗を許容しない組織が多く、初めるのが遅く、辞めるのも遅い、それでいて二度と挑戦させない文化なので育つ土壌が無いんだと思います。
だいたい誰かが俺仕様で作ったクソみたいなコードを修正して、高速化したりメモリリーク改善したりがメインです。
「またコレか…」のパターン多すぎる。これがつまらなくなった所以です。
GCの仕様くらい考えたらなんでスパイクが起こるかわかるやろ……なんで調べんのなんて思うこともあります。
ただ出来ない人が多い、才能の無い人がビジネスだけでゲーム作ってる時代でもあるので、そのおかげでおまんま食べられてるんだよなって考えてます。
プロジェクトが破綻してることも多くて、その大部分はエンジニアがクソすぎるってのが多いですね。
体制の問題もあるにはあるんですが、ゲームにこだわることもなく、ただ稼げるで来ちゃった人たち。
だからそんな人達に何か伝えても響くことも無いし、生き方も違うので何も言わない。
ゲーム自体もどこかで見た何か。なので正解が存在するのでアーキテクトや制作に頭をひねる必要も無い。
感謝されるのでやりがいはあるんですが、当時激論を交わしていたような人たちはゲーム業界から離れ超ホワイトな外資系や大手でぬくぬくやってます。
幸いなことにソーシャルゲームバブルが起こり、その波に乗れた人たちです。
たまたま私の周りはコミュニケーション能力や問題解決能力、分解能力が高かったのでちゃんと地位を築き、ちゃんと生活しています。
次に、我々が解決したい課題そのものよりも、その周辺の競プロっぽい部分に勝手に取り組んで時間を消費することであった。あくまで例えばであるが、データベースに大量データをインサートする際のパフォーマンスが低くて困っていた、としよう。その issue を競プロ出身者に渡すと、大量データを取得する部分を高速化したり、インサートする前の前処理でデータをソートしたりして僅かな高速化を喜ぶのである。ボトルネックはインサート処理そのものなので、それ以外の部分を改善してもユーザーに届く価値はほとんど向上しない。やんわり指摘しても「でも以前よりは速くなっています」という返答である。同様に、何らかの issue を割り当てたときも、その issue の周辺からグラフ理論の問題に落とし込めるようなポイントを探し出し、改善して喜んでいた。カスであった。
こういう感じの自分の興味ある専門分野にだけ取り組む態度は、プログラミング以外の領域でやるとそれはもうボコボコのボッコボコに社会から叩かれまくって完全に心を折られるプロセスが必ず入るんだよね。
プログラミングだけは時代の流れに乗っちゃってるせいでそのプロセスが入ってない状態なんだろうな。
しかも最近はワークライフバランスとかハラスメント排除の社会的潮流が重なっているせいで、ボッコボコにすること自体が実行できない雰囲気になっている。
ワイ、国内では結構大きいインターネットサービスを提供する会社にいる。
この数年、一部で競プロ出身者を持て囃す傾向があるが、それは全く幻想であることを伝えよう。
ワイの会社に来た競プロ出身者(2人いる)には、システムのパフォーマンスが出てない部分を高速化してもらったり、なんやかんやで複雑化してしまった箇所を改善してもらったりなどを期待していた。(やけに抽象的なのは特定を防ぐためで、実際はもっと我々の課題は明瞭である。)
その競プロ出身者は、プログラミングの腕は一見一流だと思う。高学歴で学生時代から競プロに親しみ、何色が云々だとか、いくつかのコンテストで入賞したりしていた。パズル的な問題を解くには確かに強い人材だと思う。しかし、企業で使うにはあまりにカスすぎて、「企業に出張ってきて迷惑をかけるんじゃなく、部屋にこもって競プロやってろ」と思うに至った。
まず何よりも第一に、コードの品質があまりにひどく、見るに耐えないものだった。「これは可読性が低いコード、ということを本当に理解できないのか？」というレベル。コードレビューで「◯◯さん、あなたは賢いからこのコードでも問題ないと思いますが、他の多くの方は◯◯さんほど賢くないので、コードが長くなってもいいからもう少し意図を掴みやすいコードにしてもらえると助かります」のようなことを何度も何度も何度も何度も言った。でも変わらなかった。「自分のコードが正しい」「動けば良い」という発想から抜け出す柔軟性を全く持ち合わせておらず、控えめに言ってカスであった。
次に、我々が解決したい課題そのものよりも、その周辺の競プロっぽい部分に勝手に取り組んで時間を消費するという問題があった。あくまで例えばであるが、データベースに大量データをインサートする際のパフォーマンスが低くて困っていた、としよう。その issue を競プロ出身者に渡すと、大量データを取得する部分を高速化したり、インサートする前の前処理でデータをソートしたりして僅かな高速化を喜ぶのである。ボトルネックはインサート処理そのものなので、それ以外の部分を改善してもユーザーに届く価値はほとんど向上しない。やんわり指摘しても「でも以前よりは速くなっています」という返答である。同様に、何らかの issue を割り当てたときも、その issue の周辺からグラフ理論の問題に落とし込めるようなポイントを探し出し、改善して喜んでいた。カスであった。
人格はそこまでガチのカスというわけではなく、ある意味では無邪気な少年のようであった。ただそれは我々が求めている人材とは異なった。競プロ出身者一人だけこういう行動ならまだしも、我々は二人ハズレを引いている。言うまでもなく人材採用は大変コストがかかるので、今後わざわざハズレを引きに行くことはないだろう。もっとはっきり言うと、競プロ出身者を採用することは無い。
世間にはまだまだ「競プロ出身者はプログラミングに詳しいすごいプログラマである」という幻想があることだろう。しかし実際は、自分の好きな領域にのめり込んでいるだけで、宿題そっちのけでゲームをやっている小学生と似たようなメンタリティなのだ。
企業にプログラマとして雇われるなら、プログラムを書くだけでなく、もう少し大きい視点を持ってユーザーに価値を届け利益を上げなくてはならない。その重要な能力が欠如している競プロ出身者は採用すべきではないのである。
Q.
1つのCPUコアでの逐次処理を高速化することには限界があるため、コア数を増やし並列化させることで性能を向上させる必要がある、という考え方について、市販のサーバコンピュータとスーパーコンピュータで違いはありますか？
A.
この考え方に関して、市販のサーバコンピュータとスーパーコンピュータの間には基本的な違いはありません。両者とも、シングルコアの性能向上に限界がある中で、並列化によって全体的な処理能力を高めるという方向性を共有しています。しかし、その実現方法や規模には大きな違いがあります。 サーバコンピュータとスーパーコンピュータの並列化アプローチの比較 1. 並列化の規模 サーバコンピュータ: 数個から数百個のコアを使用 スーパーコンピュータ: 数万から数百万個のコアを使用 2. 並列化の方法 サーバコンピュータ: 主にSMP（対称型マルチプロセッシング）やNUMA（非一様メモリアクセス）アーキテクチャを採用 比較的少数のプロセッサを密結合 スーパーコンピュータ: 大規模な分散メモリシステムを採用 多数のノードを高速ネットワークで接続 3. 相互接続技術 サーバコンピュータ: 一般的なネットワーク技術（イーサネットなど）を使用 スーパーコンピュータ: 専用の高速相互接続技術（InfiniBand、Tofu Interconnectなど）を使用 4. ソフトウェアとプログラミングモデル サーバコンピュータ: OpenMPやpthreadsなど、比較的シンプルな並列プログラミングモデルを使用 スーパーコンピュータ: MPIなどの複雑な分散メモリプログラミングモデルを使用 ハイブリッド並列化（MPI+OpenMP）などの高度な技術も適用 5. スケーラビリティ サーバコンピュータ: 中規模までの並列化に適しているが、大規模になるとスケーラビリティに課題 スーパーコンピュータ: 極めて大規模な並列化に対応できるよう設計されている 6. 用途 サーバコンピュータ: ウェブサービス、データベース、ビジネスアプリケーションなど、比較的汎用的な用途 スーパーコンピュータ: 気象予報、宇宙物理学シミュレーション、分子動力学計算など、極めて計算負荷の高い科学技術計算
基本はそうだよ？型定義なんかない方が解析が早いからわざわざGoogleが型にルーズなPythonを流行らせたわけだし、
コードが遅いのだって彼らの目的には間に合ってたんだからいいんじゃね？
データ解析系は結果さえ出ればよいので処理時間でのチューニングなんかしないしな（＝仕事上・研究上価値がないので高速化の勉強をしない）。
パッとコード書いて試して、違ったらちょっと変えてまた試しての繰り返し、そのサイクルを如何に回すかの世界だ。
もちろん速さが必要な分野、例えば競プロ勢はそこの戦いだからアルゴリズムを爆速で動かすぞ？
まぁコピペが多いとかは限られた時間で問題の答を出さないといけない競プロでは正解になることがあるけど、
それはただプログラミングの経験が浅い人が多いだけで、競プロ・機械学習出身者だからコピペが多いという話なのか？
ただ経験の浅い人が流行り物の競プロ・Pythonとかに飛びついただけの話で、それを機械学習出身者とかってくくるのはおかしい。
