.bash_profileの条件分岐 カレントディレクトリによるPATH優先順位変更

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]

以前の記事”[AI] ローカルLLM検証 llama.cppのmake時にSegmentation fault:11発生 macOS”で.bash_profileを書き換え、PATHの優先順位を変えました。

何らかの弊害があるだろうと思っていましたが、早速問題が表出しました。

pythonコマンドで/usr/local/binにある普段使いのPython3.10.4ではなく、/usr/binにあるPython3.9.6(macOSのデフォルト)が呼び出されるようになりました。

ChatGPTに解決方法を教えてもらい、以下のように.bash_profileを書き換えました。

PROMPT_COMMAND="check_for_llama_cpp"
check_for_llama_cpp() {
    # grepファイルを読み込めるようにする
    export PATH=/usr/bin:$PATH

    if ls | grep -q "llama.cpp"; then
        # 'llama.cpp' を含むディレクトリの場合
        export PATH=/usr/local/bin:$PATH
        export PATH=/usr/bin:$PATH
    else
        # それ以外のディレクトリの場合
        export PATH=/usr/bin:$PATH
        export PATH=/usr/local/bin:$PATH
    fi
}

これでllama.cppをビルドする時だけPATHの優先順位が変わり、/usr/binが優先されます。カレントディレクトリが変わる度にPROMPT_COMMANDによるチェックが入る仕組みです。その度にPATHデータが増えていきますが、パフォーマンスに影響はないでしょう。

[AI] ローカルLLM検証 CodeLlama系日本語学習モデル その3 Mac M2 Proで動作確認

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
実行方法:llama.cpp

記事その1ではWindows11PCで検証しましたが、GGUF形式であればMacでも動作可能なので早速試してみました。Metalを使用しています。

4bit量子化したGGUF形式のモデルはサイズが4.08GBですから、RAM16GBでも問題なさそうです。

質問によっては無回答で終了することもあるものの、それなりに考えたプロンプトであればSwiftUIの簡単なコードについては正しい答えが返ってきました。

ただし量子化の影響なのか、下図のような簡潔な正答になることもあれば、勝手にチャットのようになったり、誤答を返すことも多く、結構不安定です。

量子化していないGGUF形式のモデルで検証したいところです。

./main -m models/ELYZA-japanese-CodeLlama-7b-instruct-q4_K_M.gguf --temp 1.0 -ngl 1 -t 10 -f ./prompt_jp.txt

参考サイト

[AI] ローカルLLM検証 llama.cppのmake時にSegmentation fault:11発生 macOS

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]

LLMのランタイムであるllama.cppのmake時にセグフォ11が発生しました。

コンパイラがclangなのが問題なのかと考え、gccとg++に置き換えましたがダメでした。

Xcode内にあるclangのシンボリックリンクをgcc、g++にリネームして/usr/local/binに置いても状況は変わらず。

InstalledDirが/usr/local/binなのが問題。Xcode内のclangを認識させる必要がある。

/usr/binにあるgccとg++(共に中身はclang)を認識させるようにすると、やっとmakeできました。.bash_profileの行を一部入れ替えて/usr/binの優先順位を上げています。

# /usr/binの優先順位を上げる
export PATH=/usr/local/bin:$PATH
export PATH=/usr/bin:$PATH
これでmakeできるようになった

llama.cpp開発者がMacユーザーはCコンパイラをデフォルトのままで使用するものと想定しているために起こったトラブルでした。

gcc、g++についてclangではなく正規ファイルを使っているMacユーザーの存在は考慮していません。23年4月までのllama.cppでは正規ファイルでもビルド可能でした。ただし、その頃はモデル形式がGGMLだったため、現在のGGUFタイプのモデルは使用不可です。

make中のトラブルをデバッグする手段がなく途方に暮れましたが、Cコンパイラが動作するタイミングでセグフォ11が発生していることから推測して何とか解決できました。

gcc、g++の正規ファイルを使用しているMacユーザーのLLM使いは案外少ないのか、llama.cppのGitHubやStackOverFlowでこのような話題はありませんでした。

このトラブルの解決に丸一日費やしてしまいました。

[AI] ローカルLLM検証 CodeLlama系日本語学習モデル その2 VRAM消費量、消費電力

Windows11PCでの推論実行時のVRAM消費量と消費電力を調べました。

GPU:GeForce RTX 4070Ti 12GB
LLM : ELYZA-japanese-CodeLlama-7b
プロンプト:Swiftコードに関する簡単な補足依頼。回答まで1分10秒程度。
VRAM消費量測定:nvidia-smiコマンド
消費電力測定:SwitchBotミニプラグのアプリ画面から読み取り

VRAM消費量はほぼ12GBでフル使用でした。消費電力は最大168Wで電源ユニット750Wに対してかなり余裕がありました。

# 1秒おきにGPU使用状況を表示
nvidia-smi -l 1

[AI] ローカルLLM検証 CodeLlama系日本語学習モデル その1 動作確認

昨年の今頃はChatGPTアプリ製作、RWKVなどローカルLLMの検証に取り組んでいました。

あれから1年が経ちローカルLLMの現状を調べているとプログラミング補助に特化したLLMを見つけたので、簡単に検証してみました。ELYZA-japanese-CodeLlama-7bというモデルです。CodeLlamaはMetaが開発しているモデルになります。

Windows11PC(RAM 64GB, RTX 4070Ti 12GB)でSwiftについてプロンプトを送ったところ、1分9秒で回答がありました。残念ながら使えないコードでした。ただ、このモデルのデモサイトではGPT-4と同じく正しいコードを返してきます。パラメータを調整する必要があるみたいです。

Google ColabでV100やA100でも検証してみて、VRAM依存が明確になりましたら、RTX 4070 12GBとの2枚挿しを検討したいところです。

[AI] Claude 3 vs GPT-4 / Swiftプログラミング補助 24/03/12

話題のClaude 3 (Sonnet)を即席評価しました。

またもやGPT-4の圧勝でした。2月に評価したGeminiと同じく読解力が不足しています。なお最上級のOpusはサブスクかAPIでないと使えないようです。

OpenAIが法人営業で苦戦しているとの記事を目にしました。用途によるとは言え、買い手はAIの実力を正当に評価できているのか、はなはだ疑問です。他社サービスは文章生成では優れているのでしょうか。

インフルエンサーもインプットとアウトプットの量だけで評価しているふしがあり、質を網羅的にはほとんど見ていないですね。ちゃんと目利きができる方の出現を望みます。

プログラミング補助用途では、GPT-4の牙城は揺るぎないといったところです。

ただOpenAIには殿様商売的な姿勢が垣間見られ、アンチが多い感じがします。昨年11月、GPT-4 Turbo(gpt-4-1106-preview)のリリースについてはメールで案内がありましたが、今年1月のgpt-4-0125-previewリリースでは一切ありませんでした。この点については、かなり不満があります。

グチは置いといて、後発のGemini、Claudeはより大量な情報を処理し要約・創出するのが得意で、GPTの方はインプット側の足りない情報を補完するつまり行間を読む能力に長けている、という私なりの結論に至りました。

Claude 3 (Sonnet)※

※バージョン番号を取得する方法も含めて聞いているのだが、こちらの意図を読み取ることができない。
コード例を示している時点で指示者が中級者であることを察するべき。指示者がTextストラクチャを使えているのにその使い方を回答するのは流石にアウトです。単なる学習データ不足か。

GPT-4 : いつもながら素晴らしい回答
Gemini vs GPT-4の記事

[C++] 361 BBS閲覧アプリの製作 その34 FLTK内部ソースコード混在によるビルドエラー 原因判明 #define命令

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0, FLTK 1.3.9]

前回記事のビルドエラーについて原因が判明しました。

Fl_WebView.cppで定義していたプリプロセッサの#define命令が悪さをしていました。

#define命令 FL_INTERNALSによりmac.Hのif文で誤った分岐に誘導されていました。なぜ急にプリプロセッサが機能し始めたのか、については不明です。

とりあえずプリプロセッサは無効にしました。libfltk_webview.aファイルに静的ライブラリ化しなくても、これまで通りビルドできます。

// #define FL_INTERNALS // mac.Hのif文で誤った分岐に誘導していたため無効化

#include "Fl_WebView.H"
#include "webview.h"
#include <FL/Fl.H>
#include <FL/platform.H>
#include <stdexcept>

extern "C" void my_close_win(void *win);
extern "C" void make_delegate(void *child, void *parent);

void close_cb(Fl_Widget *w, void *win) {
  my_close_win(win);
  w->hide();
}

void Fl_WebView::navigate(const char *addr) { webview_navigate(wv, addr); }

Fl_WebView::Fl_WebView(int x, int y, int w, int h, const char *title)
    : Fl_Double_Window(x, y, w, h, title) {
  Fl_Double_Window::end();
}

void Fl_WebView::draw() {
  if (wv)
    webview_set_size(wv, w(), h(), 0);
}

void Fl_WebView::init() {
    if (!shown())
        throw std::runtime_error("The window needs to be shown.");
    
    auto handle = fl_xid(this);
    wv = webview_create(false, (void *)handle);
    make_delegate((void *)webview_get_window(wv), (void *)handle);
    // Fl::add_idle(webview_run, wv); // この行をコメントアウトする
    this->top_window()->callback(close_cb, (void *)webview_get_window(wv));
}
#if !(defined(FL_LIBRARY) || defined(FL_INTERNALS)) // this part is used when compiling an application program
#  include <FL/Fl_Widget.H>

typedef struct flCocoaRegion* Fl_Region;
typedef struct CGContext* CGContextRef;
typedef struct OpaquePMPrintSettings*   PMPrintSettings;
typedef struct OpaquePMPageFormat*      PMPageFormat;
typedef struct OpaquePMPrintSession*    PMPrintSession;
typedef struct CGImage* CGImageRef;
typedef struct __CFData* CFMutableDataRef; // used in Fl_Copy_Surface.H
typedef CGContextRef Fl_Offscreen;

#else // this part must be compiled when building the FLTK libraries

※ mac.Hのif文でelseの方に誘導されていた

[C++] 360 BBS閲覧アプリの製作 その33 FLTK内部ソースコード混在によるビルドエラー

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0, FLTK 1.4.0ベータ版]

BBS閲覧アプリが急にビルドできなくなりました。

FLTKライブラリ作成用のFl_WebView.cppをプロジェクトに混在させていた問題が何らかのきっかけで顕在化したようです。これまではマグレでたまたまビルドできていました。

In file included from src/Fl_WebView.cpp:6:
In file included from /usr/local/include/FL/platform.H:26:
In file included from /usr/local/include/FL/x.H:32:
/usr/local/include/FL/mac.H:118:12: fatal error: '../src/Fl_Font.H' file not found
#  include "../src/Fl_Font.H"
           ^~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:36: obj/Fl_WebView.o] Error 1

GitHubにあるFL_WebViewプロジェクトからビルドし、生成したlibfltk_webview.aファイルを使うようにすると正常化しました。ビルドの際、GitHubのFLTK 1.4.0 最新ベータ版を使っているため、このアプリのビルドにも同バージョンを使用しました。

FLTK最新ベータ版 libファイル:fltk-build/libにあるものを使用
FLTK最新ベータ版 ヘッダファイル:fltk-src/FLにあるものを使用
libfltk_webview.aファイル:libファイルと同じディレクトリへコピーする

GUI右側中央のFl_Boxにスレッドタイトルが表示できていない不具合についてはこれから対処します。

GitHubリンク

[C++] 359 Makefileでワイルドカード使用 FLTKアプリ

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0, FLTK 1.3.9]

Homebrewのライブラリをアップデートする度にMakefileにあるバージョン番号を更新しなくて済むようワイルドカードに置き換えました。

さらにライブラリへのリンクを意味する-lを正常に動作させるため、-Lオプションに/opt/homebrew/libを追加しました。

これまでは/opt/homebrew/Cellarにある各ライブラリのlibパスをわざわざ記入していました。/opt/homebrew/libにライブラリファイルがまとめられているとは知らなかったです。

今回の修正で大分洗練されたMakefileになったように思います。

# コンパイラ
COMPILER = clang++
DEBUG = -g

# ビルドオプション
CPPFLAGS = $(shell fltk-config --use-gl --use-images --cxxflags ) -std=c++11
CPPFLAGS2 = $(shell pkg-config --cflags --libs opencv4 )
LDFLAGS = $(shell fltk-config --use-gl --use-images --ldflags ) -lc++

# includeパス(-I)
INCLUDE = -I./include -I/opt/homebrew/Cellar/libpng/*/include -I/opt/homebrew/Cellar/fltk/*/include \
-I/opt/homebrew/Cellar/opencv/*/include -I/opt/homebrew/Cellar/opencv/*/include/opencv4 \
-I/Library/Frameworks/Python.framework/Versions/3.10/include/python3.10 \
-I/Volumes/DATA_m1/code/cpp/mylib/include

# リンク(-l)
LINK = -lz -lpng -lopencv_core -lopencv_imgcodecs -lopencv_highgui -lopencv_imgproc -lpython3.10

# ライブラリパス(-L)
LIBRARY = -L/usr/local/lib -L/opt/homebrew/lib \
-L/Library/Frameworks/Python.framework/Versions/3.10/lib \
/Volumes/DATA_m1/code/cpp/mylib/lib/Split.a

# ソースファイル
SRCDIR = ./src
SRCS = $(shell find $(SRCDIR) -type f)

# オブジェクトファイル
OBJDIR = ./obj
OBJS = $(addprefix $(OBJDIR), $(patsubst ./src/%.cpp,/%.o,$(SRCS)))

# 実行ファイル
TARGETDIR = ./bin
TARGET = ImageInspector
	
# cppファイルからoファイル作成 $<:依存ファイル
$(OBJDIR)/%.o: $(SRCDIR)/%.cpp
	$(COMPILER) $(CPPFLAGS) $(CPPFLAGS2) $(INCLUDE) $(DEBUG) -o $@ -c $<

# アプリファイル作成関連
POSTBUILD  = fltk-config --post

# oファイルから実行ファイルとappファイル作成
$(TARGET):$(OBJS)
	$(COMPILER) -o $(TARGETDIR)/$@ $(OBJS) $(LINK) $(LIBRARY) $(LDFLAGS)
	cp $(TARGETDIR)/$(TARGET) $(TARGET)
	$(POSTBUILD) $(TARGET)
	mkdir $(TARGET).app/Contents/Resources
	cp ./images/$(TARGET).icns $(TARGET).app/Contents/Resources
	plutil -insert 'CFBundleIconFile' -string $(TARGET).icns $(TARGET).app/Contents/Info.plist
	rm -f $(TARGET)

# 全ソース強制コンパイル
.PHONY:all
all: clean $(TARGET)

# 全ファイル削除
.PHONY:clean
clean:
	rm -rf $(OBJS) $(TARGETDIR)/$(TARGET) $(TARGET).app

[C++] 358 FLTKアプリ ビルド時のトラブル png.h

[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0, FLTK 1.3.9]

アイコン画像作成アプリを久しぶりにビルドすると、png関連のシンボルが見つからずエラーを吐くようになりました。

これまでlibpngのpng.hへアクセスしていたのが、FL/images/png.hを読み込むようになってしまったために起こったトラブルでした。

ヘッダファイルのincludeを絶対パスにすると直りました。

Homebrewのライブラリをアップデートするとバージョン番号が変わるのでMakefileを更新する必要がありますが、それとは関係なく起こったレアなトラブルだったため原因究明に時間が掛かりました。

ld: Undefined symbols:
  _fltk_png_create_info_struct, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_create_read_struct, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_destroy_read_struct, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_get_channels, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_get_image_height, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_get_image_width, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_get_x_pixels_per_inch, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_get_y_pixels_per_inch, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_init_io, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_read_png, referenced from:
      getInfoPNG(char const*) in processImage.o
  _fltk_png_set_sig_bytes, referenced from:
      getInfoPNG(char const*) in processImage.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:53: ImageInspector] Error 1
#ifndef PROCESSIMAGE_H
#define PROCESSIMAGE_H

#include <array>
// FL/imagesのpng.hを避けるため絶対パスに変更
#include "/opt/homebrew/Cellar/libpng/1.6.42/include/libpng16/png.h"

std::vector<std::string> split(std::string, char);
std::string join(const std::vector<std::string>& , const char*);

int checkImage(const char*);
std::array<int,5> getInfoPNG(const char*);

#define SIGNATURE_NUM 8

#endif