Re: [Chicken-users] optimizing mutually recursive loops
On Mon, Feb 16, 2009 at 8:32 AM, Alex Shinn alexsh...@gmail.com wrote: When optimizing my Chicken code for speed, I find one of the most important things is to write the code so that it gets compiled into a single C function with gotos. It's often so important to get this that I end up writing very unnatural Scheme code, including manually combining several loops into one. This can be done by the chicken optimizer, but it's not trivial - checking for a node-tree to have the proper form and rearranging everything on that level is work-intensive. I'll try to think about this a bit more. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] bytevectors
Hello, I'm working on code which uses these procedures: make-bytevector bytevector-length bytevector-ieee-double-native-ref bytevector-ieee-double-native-set! Thankfully, Larceny, Ikarus, and Ypsilon all support these. I'd like to have the code work in Chicken. Is there any equivalent to these in Chicken? I noticed that you do support SRFI-4. However, none of the above implementations seem come with SRFI-4. It looks like many implementors are converging on the 'bytevectors' api provided by R6RS. I know I know... I don't like R6RS very much either... But even Will Clinger who's very outspoken against parts of R6RS seems to be OK with the bytevectors api. So... do you think chicken can support the bytevectors api? :-) Honestly, if SRFI-4 were widely adopted, I'd gladly use it instead of R6RS bytevectors. In fact, wherever possible, I'm using SRFIs instead of R6RS (for example SRFI-1 instead of R6RS quirks). But homogeneous vectors seem to be one place where R6RS won. Ed ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: bytevectors
Eduardo Cavazos wrote: So... do you think chicken can support the bytevectors api? :-) Hmmm... After poking around some, I see that I can probably cook up a compatability layer. Something along these lines: -- (use srfi-4) (define (make-bytevector n) (make-blob n)) (define (bytevector-ieee-double-native-ref blob i) (f64vector-ref (blob-f64vector/shared blob) i)) (define (bytevector-ieee-double-native-set! blob i val) (f64vector-set! (blob-f64vector/shared blob) i val)) -- Hopefully somebody can advise on the most efficient approach. Let's suppose I take this approach, where I use Chicken blobs in place of R6RS bytevectors. There's one problem that exists. Some of the procedures in the OpenGL egg want f64vector objects. For example, this results in an error: (let ((bv (make-blob (* 16 8 (glGetDoublev GL_MODELVIEW_MATRIX bv) bv) Again for comparison, the OpenGL libraries in Larceny, Ypsilon, and Ikarus allow a bytevector to be passed to 'glGetDoublev'. I'm willing to use a customized gl egg for my purposes. This is from 'gl.scm' in the opengl egg: void glGetDoublev( GLenum pname, GLdouble *params ); What could I change that to such that blobs are allowed as the second argument? Ed ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] efficient bytevector-ieee-double-native-ref
Eduardo Cavazos wrote: (define (bytevector-ieee-double-native-ref blob i) (f64vector-ref (blob-f64vector/shared blob) i)) So the obvious problem here is the conversion is going to impact performance. If somebody who is familiar with Chicken internals can suggest a way to extract an 'f64' element from a blob directly, I think I'll be set. :-) Ed ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] efficient bytevector-ieee-double-native-ref
On 17 Feb 2009, at 3:47 pm, Eduardo Cavazos wrote: Eduardo Cavazos wrote: (define (bytevector-ieee-double-native-ref blob i) (f64vector-ref (blob-f64vector/shared blob) i)) So the obvious problem here is the conversion is going to impact performance. If somebody who is familiar with Chicken internals can suggest a way to extract an 'f64' element from a blob directly, I think I'll be set. :-) Hello! There's a few ways. For a start, you can always make shared vectors, as you do above - since they share the storage, creating them should be pretty efficient. Or you can write a C function that does tevector-ieee-double-native- ref; see the section in the manual about accessing foreign functions - a blob is passed to the C world as a pointer, and you can do ((double*)ptr)[index] in C and lo, a double will emerge. (IIRC, an f64 is a double, right?). But, in the long run, I think Something Must Be Done. Personally, I feel that bytevector is a bad idea - vector-of-bytes is just one possible interpretation of a region of memory. I like the idea of a blob that has no inherent access primitives - but that has ways of making 'aliases' to regions of it that have types. I made a proposal about this a while ago - I also wanted to avoid having to copy memory blocks returned by foreign code into blobs for use in the Chicken world; my proposal was to rewrite chicken's blobs so that they may either be a heap-allocated region (for small blobs) or an arbitrary pointer and length with a custom finalizer function (which can handle calling free() on malloc-ed blocks). Having thus abstracted out the management of the memory block, the underlying blob system could then form a basis for other large-data types - such as SRFI-4 vectors or R6RS bytevectors (if you must). These types would all keep a reference to a blob used as the backing store, then a base index and a length, so they can refer to just a subregion of the blob. It might also be worth storing a custom stride that's used as the multiplier when referencing rather than just sizeof(element), so that it'd be possible to make: 1) A vector that represents a row *or* column out of a 2D array - or any higher dimension 2) A vector that goes *backwards* without having to reverse it explicitly, by having a negative stride 3) An infinite vector of the same element (by having a zero stride and a MAXINT length) Then it'd be possible to make sub*vector/shared functions that just make a new vector referring to the same underlying blob, but having different start/length. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimizing mutually recursive loops
On 16 Feb 2009, at 5:09 pm, Tobia Conforto wrote: Alaric Snell-Pym wrote: Some would say that the matrix multiply should just be written in C and FFIed. In fact, most would just (use blas) or such. But I understand it was just an example. Well, yeah ;-) Concurrent Clean, a Haskell-like purely functional language that, unlike Haskell, implements mutating operations using uniqueness typing. I'm wondering whether we could apply a similar idea to Chicken. Do you think there is any space for improvement, where we could somehow reduce GC by declaring stuff as unique? I know I'm just hand-waving at this point, I need to think more about it. Quite possibly. In fact, Henry Baker (who wrote the paper on the Cheney MTA algorithm Chicken uses) has papers on the topic of Linear Lisp - see the references at http://en.wikipedia.org/wiki/Uniqueness_typing#Discussions_of_uniqueness_typing_in_programming_languages Any complex imperative algorithm involves a certain number of nested control structures, and before long, you need to add a single extra arc to that. This is quite true and I've found Scheme's named let an excellent syntax for this kind of algorithm. You can just write the loops in the natural order of variable declaration, and then jump back and forth as you need: Oh, I'll just restart with the 2nd outer loop here: (loop-row x (+ y 1)). In fact, I've been writing named loops in other languages too, where the language lets me do it... which means, if it has a syntax for lambdas. But they never come out as nicely as in Scheme. Yeah! I've made delightful use of escape continuations in the command line interface for Ugarit. My core command line function presents a prompt and processes what the user inputs; if this is a cd then it recurses to work in the subdirectory, while cd .. returns; other commands just tail-call the CLI function again, but quit escapes the whole lot by just calling a continuation established by a top-level let/cc. This made for a very natural structure; similar code in C I've written always seems to involve a boolean flag that requires sometimes complex handling... But written as a state machine, such extra control flow arcs are easy to add. I've been meaning for some time to experiment with writing Scheme macros that implement a state machine language designed for ease of use, and experimenting with using them. Nice! Do you have any prototype we could play with, or ideas we could discuss? No prototype, but lots of ideas: 1) Each state should be parameterised. This is a trick to convert a system of state machine plus mutable memory to just state machine - basically, you describe potentially infinite families of states in a single rule by giving the rule parameters. Rather than having mutable variables, you just pass parameters to states, and to modify them they just pass new values on to the next state (or to themselves, if looping). This reduces the state machine to a set of mutually recursive pure functions, and the uniqueness just removes the need for GC and opens up implementation as a set of registers. 2) Yet it'd also be nice to automate some of this by establishing a group of states as a form of lexical scope, declaring some state variables for that scope, and having the states within that scope, when they call each other, automatically passing any variables they don't explicitly pass. An example might make that clear. Say your state machine, from time to time, has to do something a hundred times. So you might have a parameterised state that does something N times. Say this thing has several steps - the steps would have to pass N around between themselves so the last state can jump back to the original state, passing in N-1. But that might get tiresome - it'd be nice to write: (let (N) step1: ... ... ... (goto step2) step2: ... ... ... (goto step3) step3: ... ... ... (if (zero? N) (goto ...exit...) (goto step1 N: (- N 1))) Eg, N is being automatically passed along when step2 calls step3 (the initial entry to step1, being from outside the 'scope', must pass it in explicitly, of course); but step3 explicitly gives a value for N, which is then used. I don't know if this is a good idea or not - hidden state can be bad, and it requires keyword-style arguments to states, which may be more pain than it's worth. 2) How about reuse of portions of state machines? They should allow some kind of lexical scope, too. A complex set of states should be packagable into a black box with a set of defined entry states, and dangling pointers out to exit states that must be supplied when the package is used, in effect providing enough exit continuations with the correct signatures. It's not quite like a closure, since it might have several entry states. But perhaps that's not important and it should just be called a closure? Really, I need to work on some examples and work on a syntax that's flexible
[Chicken-users] Re: efficient bytevector-ieee-double-native-ref
Eduardo Cavazos wrote: If somebody who is familiar with Chicken internals can suggest a way to extract an 'f64' element from a blob directly, I think I'll be set. :-) Aha... (let ((i 0)) (pointer-f64-ref (pointer-offset (object-pointer blob) (* i 8 Ed ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimizing mutually recursive loops
On Tue, Feb 17, 2009 at 04:27:40PM +, Alaric Snell-Pym wrote: 2) Yet it'd also be nice to automate some of this by establishing a group of states as a form of lexical scope, declaring some state variables for that scope, and having the states within that scope, when they call each other, automatically passing any variables they don't explicitly pass. ...example elided... I don't know if this is a good idea or not - hidden state can be bad, and it requires keyword-style arguments to states, which may be more pain than it's worth. Have you considered using SRFI-39 parameter objects? I think those give you precisely what you need - invisible parameters you don't need to pass every time you call a procedure that might need it. (can you tell I'm a parameter fanboy? :) ) I don't think parameterize is tail-recursive (it uses dynamic-wind), so if you expect procedure calls to be nested deeply, this might not be an option. 2) How about reuse of portions of state machines? They should allow some kind of lexical scope, too. A complex set of states should be packagable into a black box with a set of defined entry states, and dangling pointers out to exit states that must be supplied when the package is used, in effect providing enough exit continuations with the correct signatures. It's not quite like a closure, since it might have several entry states. But perhaps that's not important and it should just be called a closure? Or a module, perhaps? I guess it depends on whether it has any runtime state that it needs to keep. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth pgp9ouvcuc7m4.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimizing mutually recursive loops
Peter Bex scripsit: I don't think parameterize is tail-recursive (it uses dynamic-wind), so if you expect procedure calls to be nested deeply, this might not be an option. It is possible to have dynamic binding and tail recursion at the same time, though: see http://www.accesscom.com/~darius/writings/dynatail.html for the general scheme. -- John Cowanhttp://ccil.org/~cowanco...@ccil.org SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings Ding dong, the witch is dead. --Elliotte Rusty Harold on xml-dev ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] optimizing mutually recursive loops
On Tue, Feb 17, 2009 at 9:36 PM, John Cowan co...@ccil.org wrote: I don't think parameterize is tail-recursive (it uses dynamic-wind), so if you expect procedure calls to be nested deeply, this might not be an option. It is possible to have dynamic binding and tail recursion at the same time, though: see http://www.accesscom.com/~darius/writings/dynatail.html for the general scheme. Even if you make dynamic-wind tail-recursive (which isn't that trivial), it will still allocate storage for pending thunks. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: bytevectors
Eduardo Cavazos wrote: Hmmm... After poking around some, I see that I can probably cook up a compatability layer. Something along these lines: This is what I ended up using. I loaded into Chicken and it's handling some R6RS code of mine. These procedures are in tight loops. Chicken is keeping up with Larceny and Ypsilon so I'm guessing the overhead introduced isn't too bad. ;-) -- (use srfi-4) (define (make-bytevector n) (u8vector-blob/shared (make-u8vector n))) (define bytevector-length blob-size) (define (bytevector-ieee-double-native-ref bv i) (f64vector-ref (blob-f64vector/shared bv) (/ i 8))) (define (bytevector-ieee-double-native-set! bv i val) (f64vector-set! (blob-f64vector/shared bv) (/ i 8) val)) -- Ed ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: bytevectors
On Tue, Feb 17, 2009 at 10:51 PM, Eduardo Cavazos wayo.cava...@gmail.com wrote: -- (use srfi-4) (define (make-bytevector n) (u8vector-blob/shared (make-u8vector n))) (define bytevector-length blob-size) (define (bytevector-ieee-double-native-ref bv i) (f64vector-ref (blob-f64vector/shared bv) (/ i 8))) (define (bytevector-ieee-double-native-set! bv i val) (f64vector-set! (blob-f64vector/shared bv) (/ i 8) val)) -- That looks good. And it should also be the most efficient solution. chers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: bytevectors
Eduardo Cavazos wrote: -- (use srfi-4) (define (make-bytevector n) (u8vector-blob/shared (make-u8vector n))) (define bytevector-length blob-size) (define (bytevector-ieee-double-native-ref bv i) (f64vector-ref (blob-f64vector/shared bv) (/ i 8))) (define (bytevector-ieee-double-native-set! bv i val) (f64vector-set! (blob-f64vector/shared bv) (/ i 8) val)) -- felix winkelmann wrote: That looks good. And it should also be the most efficient solution. Cool! Here's a screenshot of the fruits of today's labors: http://proteus.freeshell.org/abstracting-screenshots/game1-turn6-chicken.png That was produced by a pure Scheme implementation of the ContextFreeArt semantics. More info about ContextFree: http://www.contextfreeart.org/ The code that rendered it also runs on Larceny and Ypsilon. If anybody is curious to see the code behind the program and the framework supporting it: http://github.com/dharmatech/abstracting/tree/master Ed ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] SDL egg: SDL_GL_SwapBuffers() not implemented?
On Feb 15, 2009, at 11:51 PM, Koen Weddepohl wrote: I managed to download the changes through chicken-setup now. sdl-gl-swap-buffers works fine, the graphics are displaying. The functions sdl-gl-set-attribute and sdl-gl-get-attribute are recognized, but when I call sdl-gl-get-attribute it doesn't seem to return the value I've set with sdl-set-attribute. I'm not sure if I'm doing something wrong, I haven't used these two functions before. Cheers, Koen Weddepohl Did you actually have to use the sdl-get-attribute and sdl-set- attribute for the graphics to display? Stephen ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
