「安全よりもスリルを！」 メモリ安全性のために、LinuxカーネルモジュールはRustで実装すべし、と世間に大声で訴えているけれど、本当はちょっと物足りない…危険に惹かれてしまう、そういう秘めた自分の気持ち、大切にしたいですよね！ 今回は、いかなる安全性も保証しないアセンブリ言語とRustを組み合わせて、Linuxカーネルの機能を実装してみました。 アセンブリ言語？「アセンブリ言語、何それ？」と思ったデジタルネイティブ世代の読者も大勢いることでしょう。CやRustのような高級プログラミング言語では、人間が理解しやすい型や構文などを使った記述形式をコンパイラを使って、CPUが実行できる形式へと翻訳します。一方、アセンブリ言語では、CPUが実行できる形式に限りなく近い記述形式を使います。自分の気持ちをインスタやLINEのメッセージで伝えるのは難しいですよね？アセンブリ言語はCPUへ直接気持ちを
この記事はANDPAD Advent Calendar 2024の17日目の記事になります。(投稿予定の12/17前後で風邪を引いてしまい投稿が遅れてしまいました。🙇♀️) @youchanです。実は今年の8月にアンドパッドに入社していました。アンドパッドではインフラコストを削減するための施策を行なうチームに配属しています。 アンドパッドでは建設業のDXを実現するサービスを提供しています。建設の現場では多くの写真が取り扱われます。膨大な写真データはインフラコストに響くので削除できるものは削除したいところです。実際にサムネイル画像も保存されていたりして削減可能なものがたくさんあります。 私の最近のミッションはこの不要なファイルを削除するということなのですが、ファイル数が膨大なためいくつかの工夫が必要なのでそれについて記事にしたいと思います。 また本稿では、課題を通して並行・並列処理につい
Haskell Advent Calendar 2024 3日目の記事です。 TypescriptやZigでゲームボーイエミュレータを書いたことがあったのでHaskellでも試して見ました。CPUまで書いて力尽きたのでゲームは遊べません。自分でゲームボーイエミュレータ書いてみたいという方はgbdev.ioを見ればだいたいなんとなくおおよそたぶんわかるかと思います。 エミュレータはCPUの命令を実行するたびにレジスタやメモリなどを逐次更新していくことになるのでミュータブルの方が効率が良いと思います。素直にIORefやVector.Mutableなどを使うのがよいと思うわけですが、StateMとLensを使えばミュータブルっぽいインターフェイスですっきり書けそうな気がしました。気がしたんです。 type CPU a = StateT CPUState (StateT MBCState (Sta
FPGAをはじめてみたい 「FPGAという何やら面白いものがあるらしくて、使うとすごい計算やいろいろなデバイス制御ができるらしい。」 と、興味を持って頂ける方はそれなりにいらっしゃるのではないでしょうか？ 早速なんらかのHDLなる言語を勉強し、例えば SystemVerilog を少し勉強すれば下記のようなプログラムを書くことが出来ます。 入力ポート a,b から入ってくるデータをクロックサイクル毎に加算してc に出力するロジックのソースです。 module add ( input logic reset, input logic clk, input logic [31:0] a, input logic [31:0] b, output logic [31:0] c ); always_ff @( posedge clk ) begin if ( reset ) begin c <=
先日、とある米国の業界ニュースサイトの写真を見て仰天した。AMD/Intel両社のCEO、Lisa SuとPat Gelsingerがにこやかな表情で1つの写真に収まっているのである。 最近のIntelの周りでは買収提案などのニュースが飛び交うので、フェイクニュースか？ とも思ったが、調べてみると先ごろシリコンバレーのSan Joseで開催された「2024 OCP( Open Compute Project) Global Summit」にて、AMDとIntelがx86命令セットに関するAdvisory Groupを立ち上げ、x86命令セットの共通化で協業するという発表があったことを知った。仇敵の両社の前代未聞の発表に思わず喝采した。 x86命令セットでAdvisory Groupを立ち上げたAMDとIntel 50年近い歴史を持つx86命令セットの歴史はそのままマイクロプロセッサーの歴史
Netflixの技術ブログに、Linuxのカーネル機能を拡張できる「eBPF」を活用してパフォーマンスを改善する方法が投稿されました。 Noisy Neighbor Detection with eBPF | by Netflix Technology Blog | Sep, 2024 | Netflix TechBlog https://netflixtechblog.com/noisy-neighbor-detection-with-ebpf-64b1f4b3bbdd Netflixのコンピューティング・パフォーマンスエンジニアリングチームは、定期的にマルチテナント環境におけるパフォーマンスの問題を調査しています。問題が発生したとき、調査の最初のステップは原因がアプリケーションにあるのか基盤となるインフラストラクチャにあるのかを切り分けることです。 Netflixのサービスを支えるプラ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Linuxカーネルパラメータのチューニング＆設計 0.目的 【カーネルパラメータのチューニング】を修得する目的は、サーバの特性を理解し、それぞれに合ったカーネルパラメータのチューニングすることでリソースの有効活用をできるようになることを目的とし、私個人の経験を元にした見解を以下の記事に掲載します。 1.最初に サーバには、それぞれ必要なリソース特性があり、それに合わせたカーネルパラメータのチューニングが必要となります。 世の中の流れはオンプレよりクラウドに移行してはいるので、カーネルパラメータのチューニングよりスケールアップなりスケール
ある日漫然と半導体アナリストの市場分析記事を眺めていたら、AMDとNVIDIAが躍進しているという趣旨の記事が出てきて興味を持って読んでみたら、かなり衝撃的な事実が浮かび上がってきて思わず詳細を調べてしまった。 記事の内容は、データセンター市場でのCPU/GPUの売り上げの推移に関するもので、Intel、AMD、NVIDIAの3社がデータセンター市場向けに供給するCPU/GPUの売り上げを四半期ごとに追いかけた形で構成されていた。GPUで強みを発揮するAMDとNVIDIAという構図は以前から感じていたが、各社の四半期の決算の数字をずらりと並べると、この2年間でデータセンター市場では劇的な変化が起こっていることがはっきりと見て取れた。 GPUノードの急増で激変するデータセンター市場 Intel、AMD、NVIDIAの3社はオープン市場で汎用のCPU/GPU半導体製品を供給している。 この2年
こんにちは。ソーシャル経済メディア「NewsPicks」のSREチームの飯野です。 SREでは2023年から円安に負けないコスト削減を継続して行なっていますが、最近は圧倒的な円安におされ気味です。 2024年1月-6月の間に141→161円の変動はちょっと厳しすぎますよね。 今回は2024年1月から3月にかけて行なったNewsPicksの共通バックエンドAPIサーバーのARM対応プロジェクトについて話したいと思います。 ARM対応はコスト削減を目的とした施策です。適用範囲の見誤りがあり、当初の想定ほど大きなコスト削減は実現できませんでしたが、活発に変更が行われるプロダクトに段階的に変更を加えてリリースすることができました。 ARM対応をするにあたり、何を考えてどの順番で着手したかという情報は、今後ARM対応を行う開発者に参考になりそうなので紹介します。 ARM対応計画 ARMのコンテナイメ
Oh！X関係者が語る，あのころのX68000。「X68000 Z」のローンチを記念して，かつての関係者にあれこれ話してもらおう 編集長：Kazuhisa ライター：西川善司 2022年6月8日にTwitter上で第一報が報じられ，マウスとキーボードのチラ見せ，TGS2022でのモック展示，クラウドファンディングでの展開など，次々と新たな展開を打ち出している「X68000 Z」。我々4Gamerも，TGS2022でブースの一部を提供したが，そのあまりの熱気にちょっと動揺している。 ?弊社はやります??詳細は後日? #68の日 pic.twitter.com/jU5gE2sG8R— 株式会社 瑞起（ZUIKI Inc.） (@ZUIKIInc) June 8, 2022 関連記事：【PR】新生X68000誕生。瑞起の「X68000 Z」は10月8日に予約受付を開始。TGS 2022の4Game
切り替えを辞めた Cloudflare から別サービスへの移行をしており Cloudflare Workers を利用しないことに決めた HTTP リクエスト経由での DuckDB 処理をしたいので Node.js だと厳しい sqlc-gen-typescript のメンテナンスが怪しい 今のまま Go を継続することにした。
8Bitレジスタ扱いは､Z80や8085Aは､8Bitデータなどは扱いやすいのですが 16Bit扱いと成ると､やはり6809の方が断然作りやすく 16Bitで扱う為に､8Bitレジスタ間をZ80ではたらい回ししなければならず また､16Bitペアレジスタとして使うにはBC､HL､DEレジスタの3個で Aレジスタ中心の演算が､返ってまどろこしい結果となり 16Bit-Address計算などは､断然6809の方が優れており Z80-Assembler言語で､僕のしている事が､なんと回りくどい事をしているのかと思う様に成りました｡ある意味では『6809-Assembler言語』の方がSequenceには向いているのでは･･･と思うこの頃です｡ 『6809』がミニコンに相当しているというのは確かな事です アーキテクチャーを見た限りでは､Z80の方が優れているのでは･･･と思うかもしれませんが､簡単
PC向けCPUの主流な命令セットアーキテクチャであるx86は、Intel 8086プロセッサに起源を持ち、46年の長きにわたって使われてきました。そんなx86は近い未来に滅んでしまうだろうと、技術系ブログのHackadayが主張しています。 Why X86 Needs To Die | Hackaday https://hackaday.com/2024/03/21/why-x86-needs-to-die/ x86を採用する現代のCPUは、複雑な命令セットコンピューターであるCISC、1クロックサイクルあたり複数の命令を実行可能な「スーパースカラー」、命令を高速化するため順序を変更して実行する「アウト・オブ・オーダー実行」、分岐先の命令を条件が満たされるか不明な状態で実行する「投機的実行」を特徴とする、フォン・ノイマン型アーキテクチャの一部分です。x86はもともとは16bitプロセッサで
従来から、「ARMはx86より（電力的に）効率的だ」という言説があります。これは単純に「ARMは省電力なスマホ向けで、x86は電力を食うPC向け」程度のアバウトなイメージのこともありますし、前世紀のRISC vs CISC論争のころからある「ARMはx86 (x64を含む)に比べ命令セットがシンプルなので、命令デコードにかかる電力が少なくて済んで効率的」という議論の形をとることもあります。 この議論については、半導体エンジニアの多くは「ARMがx86 より効率が良いというのは、もはや過去の神話」(in today’s age it is a very dead argument)という認識を共有していると言っていいでしょう。有名なところではApple CPU (ARM)とZen (x86)の両方を開発したジム・ケラー氏のインタビューでも言われていますし、Chips and Cheeseとい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
