From 6e65b8a81716ec86c9ba6e915e5cc4e4f133fbc3 Mon Sep 17 00:00:00 2001 From: John Date: Tue, 11 Apr 2023 00:36:00 +0200 Subject: [PATCH] Updated preloader to use multithreading Tested on Windows - a small performance hit during loading is not avoidable but this is the fastest method I found On Linux - madvise needs a test if it's working. otherwise readahead() needs to be implemented in the TODO region --- llama_util.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/llama_util.h b/llama_util.h index 2d7448bde..d791b83f7 100755 --- a/llama_util.h +++ b/llama_util.h @@ -225,13 +225,19 @@ struct llama_mmap { perror("sysconf"); return; } + #ifdef _WIN32 HANDLE hProcess = GetCurrentProcess(); WIN32_MEMORY_RANGE_ENTRY range; range.VirtualAddress = addr; range.NumberOfBytes = length; - // if (!VirtualLock(addr, length)) { }; // no benefit. for systems with too little RAM we should lock a part and restrict the preload to that new length if (!PrefetchVirtualMemory(hProcess, 1, &range, 0)) { }; // Prefetches part of the data and signals readahead to the file system + #else + // todo + //if (posix_madvise(addr, length, POSIX_MADV_WILLNEED) == -1) { }; + // readahead() should be the equivalent method for Linux. I don't think madvise will cause a full fetch + // the multi threaded read below is pseudo sequential, it also needs a test without OS level readahead in place (worst case set threads to 1 in linux or return) + #endif if (n_threads > 32) n_threads = 32;