End of Barrel Files: New Modularization Techniques with Sheriff
mruby/cの安定版1.0リリースに先立ち、Rubyおよびmrubyの開発者で、ITOCの顧問でもあるまつもとゆきひろさんに、mruby/cプロジェクトへの期待、今後の方向性などについて東専門研究員とともにお話いただきました。 （インタビュー日：2016年12月12日） ― 本日はよろしくお願いいたします。 ITOCではmruby/cや SciRubyなどRubyに関連した研究開発に取り組んでいます。Rubyを利用されることの多い県内企業の皆さんからはRubyやITOCの研究開発に多くの期待が寄せられています。 まつもとさんは国内外で多数講演され、多くの方とお話される機会をお持ちだと思いますが、国内外でのRuby、mrubyの拡がりについてどのように感じていらっしゃいますか？ まつもと：Rubyは、すでに多くのユーザーに利用されており、今更、新たに拡がりを感じるレベルではないですね。 m
最近mrubyにコミットしているので自分の活動をまとめます。 mrubyを小さくした話 mrubyでは、文字列の扱いはシンプルにchar*を構造体でラップしていました。 struct RString { MRB_OBJECT_HEADER; mrb_int len; union { mrb_int capa; struct mrb_shared_string *shared; } aux; char *ptr; }; そのため1つの文字列毎に、構造体分と文字列分の2回のmalloc/freeが発生していました。 ここでCRubyのRStringを見てみます。 #define RSTRING_EMBED_LEN_MAX ((int)((sizeof(VALUE)*3)/sizeof(char)-1)) struct RString { struct RBasic basic; union {
リンク先には，次のような記述があります． Looks like on ARM architecture, GCC and other compilers may mis-optimize memcpy and assume certain memory alignment, whichcreates errors on unaligned access. To avoid this, either don't use memcpy, or, cast the pointers to char* to disable this misoptimization. More details here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html 意訳) ARM みたいに memcpy で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く