csi from git version: slow?

[Al]

Hello, I've tried the git version (2024-02-23, compiled with LLVM-17 
clang, on a Debian 12 / linux 6.6.x). While csc and the executables it 
generates are a bit faster, running my program under csi is now twice as 
slow compared to the latest release (5.3.0).



Now before I engage in other investigations, like compiling with GCC, 
checking the nature of my program (sets a large number of globals by 
running some DSL-type macros hundreds of times, would be the most 
obvious distinguishing characteristic), I need to ask this first: is 
this to be expected? Are there some "development version" / debug flags 
/ expensive interpreter features that differ compared to stable? I 
customized only config.make by changing the C_COMPILER and PREFIX.



Thanks, Al

Re: "cannot coerce inexact literal to fixnum"

[Al]

On 2024-02-10 16:39, Peter Bex wrote:


Again, these could still be bignums when run on a 32-bit platform
(that's why the return type of s32vector-ref is defined as "integer" and
not "fixnum")


Hm.. does this mean that using s32vector-ref and -set! always incur 
typecheck costs, no matter how I type-declare identifiers passed to / 
from them? And, furthermore, that if replace these with custom-written 
(foreign-primitive ...)'s, having integer32 args / returns, those would 
also incur typechecks, and thus never be as efficient as C...?



I've generally taken to avoiding the s32vector-ref/set! builtins. 
Instead I mostly keep data in SRFI-4 vectors and manipulate it with 
C-backed foreign-primitives, without ever extracting to fixnums. For 
example I have things like (s32vector-move1! vec src-idx dst-idx) 
(copies an element from src-idx to dst-idx). But even for these, I 
wonder what type the indexes should be declared to minimize typechecks 
at the interface between C and Chicken...? Perhaps even how to make them 
inline-able to simple C array ops?



Best, Al