いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
LLVMやSwiftを作ったChris LattnerがCEOをやっている会社が、Pythonの使用感とC言語並の性能を併せ持つ言語としてMojoをアナウンスした。 まだ手元で試せる状態でリリースされてはいないが、最大35000倍Pythonより速いという。 Mojo🔥 combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models. Also, it's up to 35000x faster than Python 🤯 and … deploys 🏎 pic.twitter.com/tjT09U4F80— Modular (@Modular_AI) May
はじめに Pythonは世界的にも人気のあるプログラミング言語ですが、実行速度については課題があります。Pythonの実行速度を高速化したい、という要求は根強く、これまでにも様々なツールや処理系が開発されています。 この記事ではMITの研究者らが開発したPythonを高速化するツール「Codon」について紹介します。 この記事を3行でまとめると： 高性能で簡単に扱えるPythonコンパイラ「Codon」 Pythonとの互換性がありながら、CやC++に匹敵する高速化を実現 実際にPythonコードが100倍速くなることを検証 Codonとは Codonは高性能なPythonコンパイラです。実行時のオーバーヘッドなしにPythonコードをネイティブなマシンコードにコンパイルし、シングルスレッドで10-100倍以上の高速化が実現できます。Codonの開発はGithub上で行われており、2021
はじめに 最近、Node.jsとDenoの開発者であるRyan DahlさんがJavaScript Containersという記事を書いていることを知った。 Webとの親和性の高さがサーバーサイドで求められる中、JavaScriptがユニバーサルスクリプトとして活躍するだろう。そして、コンテナランタイムがLinuxコンテナの抽象レイヤーとしてあるように、JavaScript界隈では既存のWebAPIそのものが抽象化の手助けとなるであろう、みたいな趣旨の内容だった。 彼がChromeのV8 JavaScript Engineを使ってNode.jsを誕生させた同じ頃、JavaScriptの可能性を信じて方法を模索した人がいる。Alon Zakaiさんだ。 Alon(以降、敬称略)はWebAssemblyやその考えの元になった asm.js 、 JavaScriptコンパイラ Emscripte
Pythonの高速なスーパーセットをうたう新言語「Mojo」、コンパイラなど公開、ローカル環境で利用可能に Modular社はPythonの高速なスーパーセットだと同社が位置づける新言語「Mojo」をローカル環境で実行可能にする、コンパイラなどのツール群を公開しました。 Mojo is now available for download locally to your machine! Beyond a compiler, the Mojo SDK includes a full set of developer and IDE tools that make it easy to build and iterate on Mojo applications. Let’s build the future together!https://t.co/KxmLvsxx5e — Modula
Innovative Tech： このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。Twitter: ＠shiropen2 Pythonは人気な言語だが、実行速度が遅いため、速さを求められる環境になると違う言語が採用される。この研究では、Pythonのような高水準言語のシンプル性とCやC++のような低水準言語の高速性を兼ね備えることができるPythonベースのコンパイラ「Codon」を提案する。 Codonは、Pythonのコードをネイティブなマシンコードにコンパイルするコンパイラであり、シングルスレッドにおいて通常のPythonよりも10倍から100倍速く実行され、CやC++に匹敵する速度を実現できるという。またCodonではマルチスレッドも可能なため、より大きな性能向上
［速報］マイクロソフト、ArmネイティブなVSCode、.NET、WSLなど投入へ。Python、Node.jsなどのArm対応も進行中。Microsoft Build 2022 マイクロソフトは現在開催中の開発者向けイベント「Microsoft Build 2022」で、Arm64ネイティブなVisual Studio Codeや.NET、Windows Subsystem for Linuxなどを投入することを明らかにしました。 投入予定として発表されたのは以下のソフトウェアです。 フル機能のVisual Studio 2022 Visual Studio Code Visual C++ .NET 6 旧.NET Framework Windows Terminal Windows Subsystem for Linux Windows Subsystem for Android 以下
Rustコードのコンパイルが遅いことは誰でも知っています。しかし筆者は、世の中のほとんどのRustコードはコンパイルをもっと速くできると強く感じています。 例えば、つい最近の記事にこのように書かれていました。 一方、Rustでは、プロジェクトやCIサーバーの性能にもよりますが、 CIパイプラインの実行に15～45分かかります。 これは筆者には理解できません。GitHub Actions上にあるrust-analyzerのCIの所要時間は8分です。しかも、これは100万行の依存関係に加え、20万行の独自コードが記述されたとても大規模で複雑なプロジェクトでの話です。 確かに、Rustは根本的な部分で非常にコンパイルが遅いのは間違いありません。Rustはジェネリクスのジレンマにおいて「遅いコンパイラ」を選び、全体的な設計思想としてコンパイル時間よりもランタイムを優先しています（この点に関する優れ
Graydon Hoareが2019年にカナダのブリティッシュ・コロンビア大学でコンパイラ関連のゲスト講義した時の資料21 compilers and 3 orders of magnitude in 60 minutes - a wander through a weird landscape to the heart of compilationを読んだら大変面白かったのでメモ。 作者 Graydon HoareはMozillaでRustを開発したことで有名。その後Rustの開発もMozillaも離れて（というかRustの開発からは2013年に離れたようだ）、一時期AppleでSwift開発チームに所属していたらしい。（ソース：Reddit: I wonder, why Graydon Hoare, the author of Rust, stopped contributing in
「作って学ぶコンピュータアーキテクチャ」(いわゆるRISC-V + LLVM本)は書籍執筆時の状況と出版時のツールチェインの状況がかなり変わってしまっており、各所で迷惑をかけてしまっています。 確実にLLVMビルド + シミュレーションを行うために、ツールチェインを含んだDockerイメージをリリースします。 github.com 大きく分けて4つのイメージを用意しています。 ubuntu_2204 Ubuntu 22.04の環境を使用し、新しいRISC-Vツールを使用したDocker環境です 本書で説明している実行コマンド列と大きく異なっている場所があります LLVMリポジトリはコンテナ内にダウンロード済みです(コンテナ容量削減のためビルドは行っていません) 最終的なバイナリのみ必要な方向けです ubuntu_2204_onlyenv Ubuntu 22.04の環境を使用し、新しいRIS
「Spring Native」ベータ版公開、GraalVMによりSpring FramworkのJava/Kotlinアプリをネイティブイメージにコンパイル。JavaVMに依存せず瞬時に起動可能 Spring Frameworkの開発チームとGraalVMの開発チームは、GraalVMを用いてSpring Frameworkのアプリケーションをネイティブイメージにコンパイルする「Spring Native」がベータ版として公開されたことを発表しました。 Announcing Spring Native Beta! Read the blog post https://t.co/5klXV6kSVB and check out the video for more details. #spring #native #graalvm https://t.co/83pI3vNYEr — Spri
1個の本質的な問題を解いてしまうほうが細かいことを考えるよりも簡単植山類氏：では始めます。本日、機会をいただいて講演をすることになった植山と申します。この講演の内容は「大きな問題のほうが小さな問題より解くのは簡単だ」というタイトルです。 どういう趣旨かというと、常に簡単だというわけではないのですが、いろいろな場面で、1個の本質的な問題をドッカンと解いてしまうほうが、いろいろな細かいことを考えるよりも簡単なことが多いという話です。 そういうソリューションが往々にして見逃されがちということがけっこうあって、そういうことにどうやって挑戦していくのかという気持ちの話を、僕がそういう大きな問題を解決した経験を踏まえて話をしていきたいと思います。 「LLVM lld」と「mold」が解決した問題僕が何を作ったかというと、リンカと言われるプログラムです。「LLVM lld」というリンカと、「mold」と
コンパイラ基盤であるLLVMについて、全く知識がない私が、 javascriptソースコードをパースしLLVMでコンパイルできるようになりました。 LLVMの記事は数多くありますが、初心者向けの記事が少なく感じたため、 本記事では、できる限り分かりやすくLLVMについて紹介できる記事を書こうと思います。 ソースコードは、こちらに置いています。 自己紹介 ふだん、javascriptやpythonなどインタプリタ言語を使うエンジニアです。 LLVMについて、全く知識がなかった人間です。 背景 過去に、おもちゃのブラウザ自作をやってみました。 HTMLとCSSを解析し、レンダリングするところを書き、基本的な動作を知ることができました。 HTMLとCSSとくれば、次はJSだと思い、JSを実行するエンジンを書いてみたくなりました。 ただし、WebブラウザのAPIとJS実行エンジンをバインディングす
概要 小さなプログラミング言語から本格的なプログラミング言語へ……ステップバイステップでの開発を通して、プログラミングそのものへの理解を深めよう！ こんな方にオススメ コンピュータサイエンス、とくにプログラミング言語そのものやコンパイラについての素養を得たいと考えている人 他言語でのプログラミング経験があり、Rustの習得に興味のある人。とくに、学習のための題材を探している人 目次 第1章：プログラミング言語概論 プログラミング言語の分類 他の切り口での分類方法 コンパイルパイプライン 第2章：スタックベース仮想マシン 仮想マシン概論 Rustでの実装 標準入力からの読み込み パースとコマンドの実行 ブロックとネスト構造 if制御構文 変数の定義 複数行のソースコードへの対応 関数呼び出し 関数の再帰呼び出し WebAssemblyへのコンパイルとブラウザでの実行 第3章：プログラミング言
はじめに 半導体の微細化が鈍化し、ハードウェアによる高速化が困難になっている現状において、ソフトウェアによる計算の高速化が喫緊の課題となっています。この状況において、特定のドメインの問題を解くことに最適化された言語であるドメイン固有言語と、そのコンパイラであるドメイン固有コンパイラの活用が望まれています。 ドメイン固有コンパイラの構築の際には、開発を容易にするために、既存のコンパイラ基盤であるLLVMを活用することが考えられます。しかし、LLVM はドメイン固有コンパイラの構築にはあまり向きません。この理由は、LLVM の成功と表裏一体の関係にあります。 LLVM が成功した理由は、コンパイラの処理を適切に分割し、独立したモジュールとして機能させたことにあります。このモジュール化において中心的な役割を果たしているのが、LLVM で用いられる中間表現(Intermediate Represe
インフィニットループは会社として、先日設立された The PHP Foundation にささやかながら寄付をしました。 PHP 原作者の Rasmus Lerdorf さんと Laravel 原作者の Taylor Otwell さんと JetBrains さんとあいえるたんが同じ画面におさまって見えるのは、たぶん今だけ……！ TL;DR この記事では、以下の内容について述べています。 PHP は主要開発者が抜け、今後のために Foundation を作りました 弊社は支援を行いました 継続的な PHP の成長のためにみなさんの会社でも寄付を考えていただけませんか
llrlは自作のプログラミング言語です。大きな特徴が2つあります。 Hindley-Milnerベースの型推論による静的型付け (+型クラス) Lisp-likeなS式によるシンタックスとLLVM JITによるマクロ この言語の処理系をRustとLLVMを用いて実装し、それをllrl上に移植してセルフホスティングを試みました。無事セルフホスティングを達成したので、取り組んだことやモチベーションなどを順に振り返りたいと思います。 LLVMについては、フロントエンド側・バックエンド側ともに既にいくらかの解説記事が見られるため、概要は省略します。今回は新たなプログラミング言語のバックエンドとしてLLVMを用いるので、LLVMのフロントエンド側の実装がメインとなります。 事の発端: LLVM Kaleidoscopeチュートリアル Kaleidoscopeは、LLVMのチュートリアルにおいて実装す
WebAssemblyランタイム「Wasmer」がiOSをサポート、iOS上でWebAssemblyを実行。「Wasmer 5.0」正式版リリース 米Wasmer社はスタンドアロンなWebAssemblyランタイム「Wasmer 5.0」の正式リリースを発表しました。 Wasmer 5.0では、iOSのサポート、WebAssemblyランタイムのバックエンドがV8やWAMRなどに変更可能になるなどの新機能が加わりました。 Introducing Wasmer 5.0. Experimental V8, Wasmi and WAMR backends iOS support Enhanced Performance Upgraded LLVM and Cranelifthttps://t.co/wpwcmMT0tg — Wasmer (@wasmerio) October 29, 2024
「RustでLinuxカーネルモジュールを実装しよう！」とはしゃいできましたが、実は、X86-64とLoongArchという2つのCPUアーキテクチャしかサポートされていません。近いうちに、ARM64もサポートされそうですが、Linuxカーネルがサポートする大半のアーキテクチャで、Rustは使えません。 Linuxカーネルの標準コンパイラのGCCは、CのソースコードをLinuxカーネルがサポートする様々なCPUアーキテクチャ用の実行ファイルに変換することができます。一方、Rustの公式コンパイラがサポートを保証しているCPUアーキテクチャはARM64とX86、X86–64だけです。 Rustの公式コンパイラがサポートしているアーキテクチャが少なすぎるということで、別のコンパイラを試してみました。 Rustの公式コンパイラRustの公式コンパイラは、コンパイラを実装するための基盤的なソフトウ
「作って学ぶコンピュータアーキテクチャ」では、執筆時点ですでに500ページを超えてしまい、泣く泣く2章分を削除しています。 1つ目の付録である「付録1. 関数呼び出しのバリエーションと高度な機能」についてはすでに公開済みですが、もう一つの「付録2. 浮動小数点命令」についても公開しました。 こちらは、LLVMに浮動小数点命令を追加し、いくつかのアプリケーションを動かそうというものです。 github.com この章は、本当は基本的な演算や機能の実装後に挿入したかった章で、以下の範囲をカバーしています。 この章は割と頑張ったもので、浮動小数点の説明から、実装、さらにアプリケーションを2つ実装しています。 後半のレイトレーシングはかなり頑張った部分で、最後に画像が正しく出力されたときは若干感動しました。 こちらも、担当編集の方の校正が入っていないので怪しい文章やもしかしたら誤った情報が入ってい
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
TL;DR: The YJIT team wants to explore using Rust to help develop YJIT. The rest of CRuby will continue to build without Rust tools and building YJIT will remain optional. We’re currently exploring the possibility of porting YJIT to Rust and working on a small proof of concept that should be ready next month. The motivation behind this is that we are facing challenges in terms of code maintainabili
TL;DR; We are changing std::sort in LLVM’s libcxx. That’s a long story of what it took us to get there and all possible consequences, bugs you might encounter with examples from open source. We provide some benchmarks, perspective, why we did this in the first place and what it cost us with exciting ideas from Hyrum’s Law to reinforcement learning. All changes went into open source and thus I can
先日リリースされたGHC 9.2.1で、64ビットArm（AArch64）向けのネイティブコード生成器（Native Code Generator; NCG）が実装された。これを機会にGHCのバックエンドについて簡単にまとめてみる。 概略 GHCでHaskellプログラムをコンパイルすると、いくつかの中間言語を経て最終的には機械語が出力される。 この工程の最後の部分を「バックエンド」と呼ぶ。 GHCには Native Code Generator (-fasm)LLVM backend (-fllvm)unregisterised via-C backend の3種類のバックエンドが存在する。このほか、バイトコードインタープリターと-fno-codeもデータ型的にはバックエンドの一種として扱われている。（参照：compiler/GHC/Driver/Backend.hs） Native C
mold: modern linker Rui Ueyama
$ ruby check.rb PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/local/bin/clang-16 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main
この記事はTensorFlow Advent Calendar 2020、17日目の記事です。この記事ではLLVMコミュニティが中心となって開発しているMLIRという新しいコンパイラ基盤の基本的な使い方を解説します。 MLIRとはMLIRとはコンパイラ基盤となるオープンソースのソフトウェアでその名はMulti-Level Intermediate Representationの頭文字を取ったものです。もともとはGoogleのTensorFlowチームが開発したソフトウェアでLLVM Foundationに2019年に寄贈されました。 コンパイラ基盤としてはLLVMがよく知られていますが、MLIRはLLVMで得られた知見をより抽象的なレベルで実現し、機械学習アプリケーションに代表されるような複雑な数値計算を様々なハードウェア上に最適な形で実行できるようにします。 例えばコンパイラが真に必要な
Note (2024, ezrosent@) While the policy on bugs and feature requests remains unchanged I've had much less time over the last 1-2 years to devote to bug fixes and feature requests for frawk. Other awks are more actively maintained, and CSV support is now a much more common feature in awk compared to when this project started; I'll update this notice if frawk's status changes. frawk is a small progr
Some time ago I was talking about an ahead-of-time Ruby compiler. We started the project with certain goals and hypotheses in mind, and while the original compiler is at nearly 90% completion, there are still those other 90% that needs to be done. In the meantime, we decided to strip it down to a bare minimum and implement just enough features to validate the hypotheses. Just like the original com
TIOBE Programming Community Index (2021年4月4日) 資料: TIOBE Software 増加傾向を続けているのはPythonだ。使われる分野も多岐にわたる。学習が比較的容易で必要とされる産業が多いということは、それだけ就職口があるということも意味している。この言語に人気が出るのは当然だ。 長期にわたって減少傾向にあるものの、Javaにも根強いシェアがある。Javaは既に企業システムの基幹部分で使われているなど、ビジネスにおいて欠かすことができない言語だ。新規開発に加えて、Javaで開発したシステムのメンテナンスや改修といったニーズもある。これも就職先が多いプログラミング言語だ。 そして現在、TIOBE Programming Community Indexの1位はC言語だ。もともとC言語は人気1位だったが、Javaの登場以降は2位に甘んじていた。し
Andrew Kelley famously (or infamously, depending on your views) said "the compiler is too damn slow, that's why we have bugs."1 As a result, one of the primary stated goals of Zig for years has been faster compile times. The Zig team has been working on extremely hard problems to make this a reality (such as yeeting LLVM, writing their own code generation backends, building their own linkers, and
TL;DR Google Summer of Code 2021 を終えました First, Final Evaluation ともに通りました、という意味 LLVM むずかしい 成果 Google Summer of Code とは 前に書いた記事を参照してください。 何をしたのか 2021/May/20 から 2021/Aug/28 くらいまで、メンターの方たちと共に LLVM へ貢献していました。 （まだマージされていないパッチがあるんですけどね…） 正確には、コーディングをはじめたのは６月くらいからみたいです。 LLVM? The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. The LLVM Compiler Infrastructure clan
Tilde, my LLVM alternative I'm Yasser and I've made it my mission to produce an alternative to LLVM, the current king of compiler backend libraries. I'm calling it Tilde (or TB for tilde backend) and the reasons are pretty simple, i believe it's far too slow at compiling and far too big to be fixed from the inside. It's been 20 years and cruft has built up, time for a "redo". As a test case i wrot
Jeff, Abdul, and Chris presented a talk about Mojo and how it relates to MLIR and LLVM, at the LLVM Developer Conference 2023. The full presentation for these slides will be coming at a later date on the LLVM YouTube channel: https://www.youtube.com/@LLVMPROJ The interactive presentation below has animations and clickable hyperlinks, or you can scroll through the slide images below, and click to e
Compilers have always been surrounded by an air of mystery and magic. This has led many of us to believe that they do things (well) that they don't, or that they don't do things (well) that they do.1 In this article is one some way a follow-up of a previous one on compiler optimization. Here, I've collected some misconceptions I've come across over the years (many of them mine), doing my best to c
We couldn't find the page. Maybe you were looking for one of these pages below?
github.com/yubrot/llrl Rust + LLVMで自作言語をセルフホスティングした話 Rust + LLVM による自作プログラミング言語処理系。大きな特徴は以下の 3 つ。 Hindley-Milner ベースの型推論による静的型付け (+型クラス) Lisp-like な S 式によるシンタックスと LLVM JIT によるマクロ 完全なセルフホスティングコンパイラ実装 目標: セルフホスティング llrl は複合的な理由で作り始めたが、とにかく一度完全にセルフホストされた言語処理系を実装したいという気持ちからセルフホスティングを最優先の目標とした。 プログラミング言語のセルフホスティングは、以下のような明確なゴールを設定できる。 何らかの既存のプログラミング言語によって自作言語コンパイラを実装する → 世代 0 自作言語、およびその標準ライブラリをコンパイラを実装
In this blog post, we're sharing how we evaluated LLVM's proposed approach at Google, outlining our initial conclusions from this process, sharing useful adoption tips, and pointing to the next steps we plan to take on this journey.
この記事は、KCS アドベントカレンダー 23 日目の記事です。 22 日目・24 日目 GPU 上で走る自作言語のコンパイラ こんにちは、lemolatoon です。 最近は、夏に自作 OS ゼミでセキュキャンに参加したりして、また低レイヤへの気持ちを高めたりしていました。 自作 OS も一段落ついた頃、MLIRというものを知り、何やら面白そうだぞということで色々調べて手を動かしたりしていたのですが、ある程度 MLIR の利点を生かしたいい感じのものができつつあるので紹介したいと思います。 まず最初に自作言語を作る手順を、LLVM IR に変換するところまで説明します。 その後、GPU 上で走らせる部分について書きます。 実装は、すべて以下のリポジトリにあります。LLVM IR への変換は少なくともch6ブランチに、GPU 上で走らせる部分の実装はlower-to-gpuブランチにありま
Introducing RealtimeSanitizer for Rust How to use LLVM’s RealtimeSanitizer in Rust today and the path towards integration into Rust January 20, 2025 · 5 min read A few months ago, I gave my first talk about Rust for audio apps at AudioDevCon in Bristol. There, I met Chris and David, who presented their work on RealtimeSanitizer (RTSan) - a tool that will be officially included in LLVM20. RTSan is
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く