5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【最速へ】LowLevelVirtualMachine【LLVM】

1 :デフォルトの名無しさん:2008/05/23(金) 22:00:55
Native用言語向け仮想機械、LLVM(低水準仮想機械)について語りませう。
いくら探しても無いので立てました。

本家: ttp://llvm.org/
参照: ttp://ja.wikipedia.org/wiki/Low_Level_Virtual_Machine



2 :デフォルトの名無しさん:2008/05/23(金) 22:08:39
まだ早い
終了

3 :1:2008/05/23(金) 22:15:09
とりあえずLinuxにて素数計算を書いてコンパイルした感想。
現時点ではまだ通常のバイナリと同じか寧ろ遅いようです。
しかも、一つの生成した実行ファイルにVMと本体が同居している
せいかファイルサイズが異様にデカい…。
しばらくは様子見と言った感じですかね。生ぬるく見守っていきましょう。

4 :デフォルトの名無しさん:2008/05/23(金) 22:40:23
これって何ができるの?
汎用的なjvm?

5 :デフォルトの名無しさん:2008/05/23(金) 22:41:09
LLVM インタープリタは別にはやくないべ
llvm-gcc で普通に native code にコンパイルしたら?
OS X 上で 32 bit モードだと llvm-gcc のほうが普通の gcc より全然早かったけど。
http://accc.riken.jp/HPC/HimenoBMT/index.html
でやりました。

6 :デフォルトの名無しさん:2008/05/23(金) 22:47:38
CやC++やらFortranとか、もともとNative向けに作られている言語向けのVMで、
JavaVMと同じく実行時の最適化を行う。おまけに実行時に条件分岐が
どちらに飛びやすいか、どの命令が使われやすいかなどProfileを取ってバイナリ
自身を書き換え、使えば使うほど勝手に速度を増すらしい。

7 :デフォルトの名無しさん:2008/05/23(金) 23:34:03
LLVMの実用例ってどんなのあるんだろうな

AppleがLeopardでグラフィックス層に採用したが、
GMA950なMacではBlenderが意味不明なほど重くなってる
(Tiger起動時は無問題)
利点がさっぱりわからん

8 :デフォルトの名無しさん:2008/05/23(金) 23:43:01
>>7
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/771003390931

Apple はこれの為にわざわざ LLVM の ARM バックエンドを作ったらしいね

http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-January/007813.html

こういう感じで開発機と本番機のアーキテクチャが違う場合は恩恵が大きい
というか、ナイスアイデアだと思った

9 :デフォルトの名無しさん:2008/05/23(金) 23:56:48
あー、仮想化としての意味合いが強いのか。なるほどthx

10 :デフォルトの名無しさん:2008/05/24(土) 00:27:36
OpenGLのJITをLLVMのJITに置き換えただけでは?

11 :1:2008/05/24(土) 01:27:32
とりあえず50万までの素数計算したときの計測値を貼ってみる。それぞれ10回。
比較対象はLLVM-GCC(ver 2.1)とGCC(ver 4.3)。
対象言語はC++、基本比較回数41,539回。
一応、中枢処理はinline関数版とマクロ版のを用意。
check:41539,score:755 clock/ms

LLVM-GCC版
inline関数 :マクロ
 4240  :1315
 4280  :1265
 4190  :1245
 4200  :1235
 4150  :1255
 4210  :1355
 4280  :1255
 4220  :1305
 5    :1275//恐らく何らかのミス
 4190  :1185

通常GCC版
inline関数..:マクロ
 755  .:1255
 825  .:1165
 705  .:1125
 695  .:1145
 695  .:1095
 675  .:1135
 635  .:1145
 855  .:1285
 995  .:1255
 845  .:1175
Clock関数で測定したんで、値が低いほど早いです。ソースはやや長いので書き込み不可。

12 :1:2008/05/24(土) 01:42:09
>>11
>check:41539,score:755 clock/ms
はゴミなんで気にしないでください。

13 :デフォルトの名無しさん:2008/05/24(土) 03:49:25
(llvm-)gcc の最適化オプションは?

14 :1:2008/05/24(土) 08:10:25
>>13
共に-O3です。
inline版はtemplateを多用して
いたんですが、コンパイラ的に
inline展開した中間コードを
吐くのは苦手なのかな?



15 :デフォルトの名無しさん:2008/05/24(土) 08:34:39
う〜ん、姫野ベンチでは LLVM のほうがはやかったので、1さんがどんなソースなのか興味ありますね。どっかのアプロダに置いてくれませんか?

16 :1:2008/05/24(土) 12:12:19
>>15
元々ベンチ用コードじゃないんで
読みづらいかもしれませんが、
時間があれば夜上げておきますよ。
あまりアップローダ使わないんで、
よろしければ、良さげなところを
教えて下さいな。

17 :デフォルトの名無しさん:2008/05/24(土) 12:56:49
ttp://codepad.org/ とかじゃダメ?


18 :1:2008/05/24(土) 22:43:54
http://codepad.org/aLVS4Jld
こんなんでいいのかな?

いくつか、自作ヘッダincludeしてあるけど、
処理その物とは直接関係なかったから上げてはないよ。

あと、正直ベンチ計測したのは2週間くらい前でLinux用のコードを
どこにやったか見当たらなかったんだ。ゴメン。

だから代わりに、その後、VCの比較用にWindows向けに弄ったやつを
載せさせてもらうよ。基本的には変わらないはずだから許してね。
(もしかしたら、バグ取りの途中のヤツかも…)

それとコードはかなり汚いし、アホだけど、一応処理系毎の最適化を
調べる目的で書いたんだ。その辺に関してはスルーしてね。

19 :デフォルトの名無しさん:2008/05/25(日) 01:54:14
そのコードで inline 版とマクロ版がそんなに違うのはやっぱり何かが変なんではないかと思うな ... というか inline/マクロのちがいというより std::vector<int> と int[] の違いなのか。

20 :デフォルトの名無しさん:2008/05/25(日) 12:26:55
過去スレ
http://pc11.2ch.net/test/read.cgi/tech/1166508605/

21 :1:2008/05/25(日) 19:27:01
>>19
今回は、配列版だけしか使ってないよ。
そういえば、VCでVectorと配列で測ったら
Vector版の方が早かったよ。スレ違いでは有るけど
何でだろうね。

(以降は名無しに戻ります)

22 :デフォルトの名無しさん:2008/05/26(月) 00:02:56
>>21
あげてくれたソースコードではコマンドラインオプションで「マクロ」を選ぶと int[] になってて、「インライン」だと vector<int> になってたけど ???

23 :デフォルトの名無しさん:2008/05/26(月) 02:55:49
>>22
ホント?コード上はoptionの3bit目を基準に書いてたんだけど、
optionの指定も分岐も問題なさそうだよ?
環境依存か何か書いたかなぁ。

24 :デフォルトの名無しさん:2008/05/26(月) 03:35:11
あ、なるほど、読み間違ってました、失礼。

25 :デフォルトの名無しさん:2008/05/26(月) 08:18:39
#include <stdio.h>
#define TARGET 1000000
int primes[TARGET];

int main(){
int n=0;
int i;
primes[n++]=2;
for(i=3;i<TARGET;i++){
int k;
for(k=0;k<n;k++){
if((i%primes[k])==0) break;
}
if(k==n){
primes[n++]=i;
}
}
printf("total: %d primes¥n",n);
return 0;
}
だけでやってみました。Core Duo 2GHz です。
llvm-gcc-4.2 , gcc-4.2 で -O4 でコンパイルして time ./a.out で計っただけです。結果は llvm-gcc が 21.5 秒、gcc が 23.3 秒、まああんまり変わらないですが。

やっぱ 1 さんのは inline 展開がされてないんではないかと気になりますね。

26 :デフォルトの名無しさん:2008/05/26(月) 19:59:04
なるほどね。もしかして、GCCだと__attribute__でinline指定しないと
ダメなのかな?あとで、>>25さんのコードも含めてやってみるよ。
ところで、面白い記事があったから貼っとくね。
http://lucille.atso-net.jp/blog/?p=430
どうやら、物によっては30%も加速するんだって。どんなコードだろ?

27 :デフォルトの名無しさん:2008/05/26(月) 23:48:53
>>26
僕はその記事をまえにみたときに自分で姫野ベンチやってみたんですが、
x86 ではたしかにかなり加速しましたよ。なぜか x86-64 ではあまり加速しなかったんですが。1 さんの Linux box は もしかして 64 bit ?

28 :デフォルトの名無しさん:2008/05/27(火) 00:17:03
>>27
 いや、PenMなんだ。もしかしたら、アーキティクチャが影響したのかも
とも思ってたんだけどね。
浮動少数より整数演算が強いってことはSSEとか最適化かかると
逆に弱いかもしれないし。(ASMまで考えて無いからいい加減…。
今は、時間が無いから時間が空いたら色々試して報告してみるよ。

29 :デフォルトの名無しさん:2008/05/28(水) 23:35:56
あれ、Linux(Fedora)の標準リポジトリにもう入ってる?

30 :デフォルトの名無しさん:2008/06/14(土) 19:32:38
MacのOpenCLもLLVM使うらしいね。
http://lucille.atso-net.jp/blog/?p=526

31 :デフォルトの名無しさん:2008/06/15(日) 00:19:02
ttp://www.ottimo.co.jp/koike/
>OpneCLは大学や研究所関係者が泣いて喜ぶかも(笑)そしてリンク時のオプティマイズとは恐れ入りました!

32 :デフォルトの名無しさん:2008/06/15(日) 00:24:24
注目しているのはむしろ Grand Central だと思うけどな

33 :デフォルトの名無しさん:2008/07/01(火) 20:42:39
Xlibとか、Win32APIとか、埋め込みSQLなんかの
決まりきった設定系処理なんかにも効き目あるんだろうか?

34 :デフォルトの名無しさん:2008/07/06(日) 15:21:11
ttp://clang.llvm.org/StaticAnalysis.html
objcスレ向きか?

35 :デフォルトの名無しさん:2008/07/30(水) 23:57:06
しばらく前だけど、LLVM2.3のベンチマークが載っていた。

http://journal.mycom.co.jp/news/2008/07/07/016/index.html
http://www.stefankrause.net/wp/?p=9

この結果はlliを使っているようなので、
llcを使ってネイティブコンパイルした場合の結果が
気になるところだ。

LLVM2.2のベンチマークはこちら。
http://lucille.atso-net.jp/blog/?p=430

それから、LLVMの勉強会が開かれるらしい。
場所は恵比寿なので、東京近郊の人は行ってみれ。

http://groups.google.co.jp/group/llvm_study/web/%E7%AC%AC%E4%B8%80%E5%9B%9E+llvm+%E5%8B%89%E5%BC%B7%E4%BC%9A



36 :デフォルトの名無しさん:2008/08/07(木) 21:08:11
ttp://llvm.org/devmtg/2008-08/

37 :デフォルトの名無しさん:2008/08/30(土) 11:05:57
ttp://www.cups.org/articles.php?L562+TNews+P1+Qlpd+ipp
>Removed unused variables and assignments found by the LLVM "clang" tool.
>Added NULL checks recommended by the LLVM "clang" tool.

ttp://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html
>this is a basic idea of Blocks: it is closures for C.
>It lets you pass around units of computation that can be executed later.

38 :デフォルトの名無しさん:2008/10/05(日) 02:11:25
なんだか過疎ってるね
なんかネタない?

39 :デフォルトの名無しさん:2008/10/05(日) 19:14:38
ttp://llvm.org/devmtg/2008-08-23/

40 :デフォルトの名無しさん:2008/10/06(月) 02:35:16
寝る前にベンチでも取ってみようかと、Mingw32/x86のllvm-gccとllvm-ldでgzipコンパイルしたんですけど、
lliで実行すると

ERROR: Program used external function 'close' which could not be resolved!

というエラーが出ます。
ビルドがうまくいってないのかと思い、

#include <stdio.h>
#include <stdlib.h>
int main()
{
FILE *fp;
fp = fopen("out.txt", "w");
if(fp == NULL) { fprintf(stderr, "error: fopen"); exit(1);}
fprintf(fp, "hello world\n");
close(fp);
return 0;
}

みたいなコードで試してみたんですが同じエラーが出ました。
close()をコメントアウトすると動いているようです。
mingw版は外部のライブラリとのリンクはまだうまくできないんですかね?

41 :デフォルトの名無しさん:2008/10/06(月) 02:50:29
fclose

42 :デフォルトの名無しさん:2008/10/06(月) 03:27:27
>>41
ですね・・・失礼しました;;

念のため
int main() { close(0); return 0;}
というコードでも試してみたんですが、やはりリンクはできないようでした。
gzipをfopen(), fclose()を使うように書き換えてみる or gzipはあきらめるなど
また今度試してみようかと思います。

43 :デフォルトの名無しさん:2008/10/06(月) 03:43:02
MinGWはmsvcrt.dllを使っていて、そこではcloseがANSI C標準に入っていないという理由で
_open/_closeという名前になっているのが原因か?
MinGWはろくに使ったことがないけど。

44 :デフォルトの名無しさん:2008/10/06(月) 08:34:03
>>39
第1回勉強会か。英語で紹介されるとカッコいいなw
第2回ってないの?あるなら行きたいんだけど

45 :デフォルトの名無しさん:2008/10/06(月) 17:28:24
>>42
>>43の言うとおり、Win32 CRTでは、ANSI C標準に入っていない関数(UNIXで言うところの
システムコールも含む)は先頭に_をつけた関数名になる。
だから、MinGWでビルドするならすべて名前を変更しなければならない。
たぶんストリーム関数を使うように書き換えるより、open, close, read, writeあたりを
_つきに置き換える方が楽だと思う。

46 :40:2008/10/08(水) 02:35:22
>>43 >>45
ありがとうございます。一部関数を'_'つきに変えたら何とかコンパイルはできました。
ただ挙動がかなりあやしげですが・・・。たとえば引数無しで実行すると反応がなかったり。
一応解凍はできるようになったみたいなんでベンチとってみました。
計測はtimeコマンドでやりました。
結果見るとllvmでいい結果がでてますが、gccでのコンパイル、llvm-gccでのコンパイルともに
完全ではないなので参考までということで。
ちなみに
llvm-2.3(gzip-1.2.4) はgzip-1.2.4をllvm-gccでコンパイルし、lliで実行したものです。
llcでのネイティブへの変換はうまくいきませんでした。
gcc-3.4.4(gzip-1.2.4) はgzip-1.2.4をcygwinのgcc-3.4.4でネイティブバイナリにコンパイルしたものです。
cygwin(gzip-1.3.12) は配布されているcygwinのバイナリです。
==== llvm-2.3(gzip-1.2.4)
user 0m0.031s
user 0m0.031s
user 0m0.015s
user 0m0.000s
user 0m0.015s
==== gcc-3.4.4(gzip-1.2.4)
user 0m5.085s
user 0m5.054s
user 0m5.054s
user 0m5.163s
user 0m4.897s
==== cygwin(gzip-1.3.12)
user 0m4.914s
user 0m5.413s
user 0m5.038s
user 0m5.163s
user 0m5.085s
正しく計測ができていなそうですが、せっかく測ったので。

47 :40:2008/10/08(水) 02:36:36
あと、
gzip-1.2.4をllvmでコンパイルするパッチを
http://codepad.org/doeKoAQi
に、(パッチ当てた後 BUILD.sh を実行すればコンパイルできるはずです)
テストに使用したスクリプトを
http://codepad.org/T4LSsUpK
に、このスクリプトの実行結果を
http://codepad.org/RZyAm3Tb
にはりました。


48 :デフォルトの名無しさん:2008/10/08(水) 09:38:16
gcc も -O3 だけじゃなくて最適化オプションいろいろ調整すれば
もうちょっとはやくなったりするので、何を持って llvm-gcc の速度というか疑問だったりするんですが。

49 :デフォルトの名無しさん:2008/10/10(金) 07:19:30
mingwのllvm-gccとcygwinのgccで比較しちゃダメでしょ。
cygwin gccのバイナリの方がが遅いのは当たり前。

50 :デフォルトの名無しさん:2008/10/10(金) 21:50:25
うお、よく見たらCygwinと比較してるのか。ダメすぎるぞ。
確かにCygwin版ならopen(2)とかclose(2)とかがそのまま使えたかも知れないが、
それはCygwinでそのあたりの関数群をエミュレーションしてるからだ。だからむちゃくちゃ
遅くなる。
llvm-gcc版と全く同一のコードでビルドできるから、MinGW-gccでもう一度やり直し。

51 :デフォルトの名無しさん:2008/12/02(火) 23:03:18
オレ言語コンパイラをllvm対応させるとどんなよいことがありますか?

52 :デフォルトの名無しさん:2008/12/02(火) 23:10:51
Alchemy使ってFlash化できるかもしれない。
いや、俺まだ触ってもいないけど。

53 :デフォルトの名無しさん:2008/12/03(水) 01:27:06
最適化とかを自分でやらなくて済むくらいかな
でもこれはgccでも一緒か。作業的にはC++で書かれてる分LLVMのが楽そうだけど

54 :デフォルトの名無しさん:2008/12/03(水) 07:33:37
いやgccは魔境らしいからLLVMやろうぜ

55 :デフォルトの名無しさん:2008/12/14(日) 02:54:18
一応書いておくと、LLVMの開発系MLは以下で読めるよ。

ttp://lists.cs.uiuc.edu/pipermail/llvmdev/

今月分
ttp://lists.cs.uiuc.edu/pipermail/llvmdev/2008-December/date.html

56 :デフォルトの名無しさん:2008/12/17(水) 18:05:00
clangとLLVMをベースにしたOpenCLの実装が開発中らしい。

http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-December/018913.html

57 :デフォルトの名無しさん:2008/12/27(土) 19:51:36
これWindowsだとどう処理されるの?
一応実行中のバイナリは書き換えできないよね?

58 :デフォルトの名無しさん:2008/12/27(土) 19:57:26
>>57
実際のところ、実行時最適化は Windows 以外でも使われてない。

59 :デフォルトの名無しさん:2008/12/29(月) 09:28:27
やったとしても"バイナリ"を書き換える必要はないだろうけどね

60 :デフォルトの名無しさん:2009/01/13(火) 08:16:38
>>56
clangもLLVMもOpenCLも、Appleが主導してるようなものだからなぁ。
結局は積極的に利用するのはAppleくらいなものじゃないのかね。
LLVM-GCCもiPhoneくらいだろ?実際に使ってるの。

61 :デフォルトの名無しさん:2009/01/13(火) 10:56:42
その実装はAAPLとは全く別でしょ。
最近VMMに買収されたらしいよ。

62 :デフォルトの名無しさん:2009/01/13(火) 14:49:29
>>59
if(a<5&&b<10)break;
ってな条件があって成功しない
確率の方が多い時(ループ中のbreakとか)
実際の利用状況としてa<5は頻繁に成立しまう場合は
if(b<10&&a<5)break;
と書き換えてしまった方が早くならない?
とくにファイルに保存したデータの状況によって
b<10とa<5の成立頻度が変わる場合は便利な気がする。

63 :デフォルトの名無しさん:2009/01/13(火) 21:52:15
それならどのみち分岐予測が効くから違わんのでない?

64 :デフォルトの名無しさん:2009/01/14(水) 08:59:57
>>62
(直前のレスを読んだなら)>>59が言ってる"バイナリ"は、オンメモリの実行コードのことじゃないことはわかっていると思うが…
結局の所、実行ファイルを書き換える必要は無いよな

65 :デフォルトの名無しさん:2009/01/14(水) 13:49:10
そう?実行時に書き換える手間が減るからある程度は効果ありそうに思うけど

66 :デフォルトの名無しさん:2009/01/15(木) 09:33:51
実行ファイルとngenのキャッシュ的なものがごっちゃになってる気がする
独自のJITキャッシュデータの話なら、書き換えできるできないの話にはならないし
実行ファイルそのものを書き換えるという話なら、USBに入れて使えない

67 :デフォルトの名無しさん:2009/02/09(月) 19:39:06
llvm-gcc -emit-llvm -S で吐き出したコードの中に

%val = load i32* getelementptr (%struct.S* @b, i32 0, i32 0)

のような、load 命令の中で getelementptr 命令を使っている行がありました。

LLVM IR にこのような文法があるのでしょうか?
リファレンスマニュアルを見ましたがこの文法が見当たりませんでした。

68 :デフォルトの名無しさん :2009/02/09(月) 23:23:53
llvmを使って新しいカーネル作れないかな?

69 :デフォルトの名無しさん:2009/02/10(火) 18:20:42
LLVM の最適化は自動ベクトル化に対応しているでしょうか?

2つの4次ベクトルの要素をすべて取り出して、対応する要素を加算して、
加算の結果をまたベクトルに戻す処理を書いたのですが、opt -std-compile-opts
で最適化しても1つのベクトル加算に変換されていませんでした。

70 :デフォルトの名無しさん:2009/03/02(月) 14:08:49
>>67
亀レスだけど、ConstantExprのことかな?
マニュアルには載っていないので、ソースコードを読まないと分からない。
ExpressionをConstantとして扱う機能だから、
この場合はgetelementptr命令の返却値をload命令の引数にするという意味。
(ConstantExprの場合は括弧が追加される)

「include/llvm/Constants.h」と「lib/VMCore/Constants.cpp」にある
定義を読み「lib/VMCore/AsmWriter.cpp」でLLVM IRとしては
どんな文字列が出力されるのか確認すれば、分かるようになるかもね。

分からなければ、自分ではConstantExprを使わずに、
別のInstructionに分けて書けばいいと思ふ。
(この場合はgetelementptr命令の返却値を一度変数に代入する)



71 :デフォルトの名無しさん:2009/03/02(月) 14:10:14
第2回勉強会をやるみたいだね。
興味のある人は参加してみては。

http://atnd.org/events/381



72 :デフォルトの名無しさん:2009/03/02(月) 21:56:22
>>71
もう申し込んだよ。楽しみだー。

73 :デフォルトの名無しさん:2009/03/09(月) 19:22:48
HLVMのアルファ版が出たようだ。
コンパイラや言語を自作したい人は、これをベースにすると楽ができるのかも。

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-March/020729.html



74 :デフォルトの名無しさん:2009/03/14(土) 23:26:46
教えてもらいたいんだけど、
LLVMのJITって
lli + *.bcのビットコードの状態じゃないと有効じゃないの?
llcでネイティブなコードした実行ファイルの状態だと
普通のコンパイラがはいたバイナリと同じ?

75 :デフォルトの名無しさん:2009/03/15(日) 20:51:40
そう。
それにデフォルトの状態では特にJITであること生かした動作してない気がする。

76 :デフォルトの名無しさん:2009/03/16(月) 21:27:06
>>75
ありがとう。
llvm-ldで実行ファイルできるじゃん
って思ったら.bcをlliに渡すラッパーだったw

ところで、mingw用のインポートライブラリを
変換する方法ってないんですかね?


77 :デフォルトの名無しさん:2009/03/21(土) 00:11:46
勉強会age
このスレまだ100も行ってないのかyo

78 :デフォルトの名無しさん:2009/03/21(土) 00:45:56
>>73
軽く読んでみた限り思ったよりHighLevelじゃないしあんまりメリットが見えない。
OCamlはかじった程度なんで間違ってたら解説よろしく。

>>77
ユーザーの絶対数少なそうだし。
勉強会の懇親会で食中毒でも起こったら日本のLLVM関係者の1割ぐらい減るんじゃなかろうか。

79 :会場の人:2009/03/21(土) 12:37:18
>>77
もう明日か。
思いのほか人数増えちゃってgkbrしてます。入りきるかなー・・・。
色々不手際あるかと思いますがゴメンナサイ。と、今から誤っておくます。ヒー

電源タップの数がまずもって全然足りてないので、
ノートPC持ってくる人は満充電にしてきてね!

80 :デフォルトの名無しさん:2009/03/21(土) 13:55:22
>>79
電源タップもって行けば会場の電源の容量は足りますか?

81 :会場の人:2009/03/21(土) 15:01:47
電源容量は・・・調べてませんがノートくらいならまかなえると思います。さすがに。
もし火を吹いたら、消火のご協力をお願い致します。w

というか電源タップ持ってきて頂けると非常に有難い!ありがたやー!

82 :デフォルトの名無しさん:2009/03/22(日) 23:33:28
>>主催者&発表者各位
お疲れさまでした。なかなか楽しめました。ありがとう。
自分で触っている人あんまりいなかったのかなー。
>>81
おれ電源タップひそかに持っていったんだけど、いらなかったみたいねorz

83 :会場の人:2009/03/22(日) 23:52:12
>>82
ご協力頂き有難うございました!
思ってたより、ノートPC持ってきた人少なかったですねw


新しく買ったノートにLLVM入れたいんだけど、MinGWのインストーラが
ネットにつながってくれない・・・。('A`)

84 :デフォルトの名無しさん:2009/03/25(水) 01:42:48
海外出張と重なって勉強会に行けませんでした (泣
次回は参加するぞ〜。

25 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)