IRC channel logs

2013-11-16.log

back to list of logs

<unknown_lamer>mark_weaver: if you happen to have that NaN unboxing patch that works against *any* revision, or even needs brushing off... I'd like to check it out
<unknown_lamer>I suspect I'd be able to update it against any changes between whenever it was made and the current stable-2.0 head
<mark_weaver>heh, impatient :)
<mark_weaver>unknown_lamer: okay, I need your email address
<unknown_lamer>clinton@unknownlamer.org
<unknown_lamer>I just want to check to see if it's a path worth pursuing
<unknown_lamer>I got the gc to be a little better with real time things by changing the time comparisons in libgc to use wall instead of cpu time
<mark_weaver>I'll send you the last two revisions of the patch. one that handles addresses with the high bit set (needed on some platforms), and one which doesn't. these patches are against guile-master in the July 29-30 timeframe, before the stack VM was removed.
<mark_weaver>I warn you though, adapting the patch to the current stable-2.0 may not be entirely trivial, since I added some more assembly bits for fast math since doing these patches.
<unknown_lamer>it's worth a shot at least
<unknown_lamer>if you happen to have a rev that it does apply against handy I can always revert for the performance test
<unknown_lamer>(should be pretty obvious... either that 8M per second of garbage is coming from floats or it's coming from something else!)
<mark_weaver>well, my best recommendation would be to go back to a guile-master revision from around that time (July 29)
<unknown_lamer>works for me
<mark_weaver>unknown_lamer: okay, the email has been sent to your MX.
<unknown_lamer>danke
<mark_weaver>good luck!
<mark_weaver>unknown_lamer: I should mention that those two revisions use considerably different methods for tagging. the latter patch is cleaner in some ways, but the earlier patch might be faster. also, it's quite possible that the tag checks could be tuned to be faster. it is very preliminary work.
<mark_weaver>I was doing some brainstorming on how best to do the tag checks, and that's a work-in-progress.
<mark_weaver>also, I was experimenting with combining tag checks of multiple arguments into a single test, in the hopes of reducing the number of branch mispredictions, but later testing revealed that that idea might have been a lose.
<mark_weaver>(both of the patches try to do the clever combined tests)
<mark_weaver>unknown_lamer: I can see that 93da406f331a1849f05e63387442b9aaf33f9540 is the revision that the patches were made against.
<unknown_lamer>thanks much
<mark_weaver>(I merged some of the big parts of those patches into master after that, e.g. 00472a22bbbbbeaf2c0e61520d4f155ace05e41c which contains the bulk of those patches)
<mark_weaver>(Add 'scm_i_from_double' and use it)
<mark_weaver>so the patches would be a lot smaller now.
<mark_weaver>iirc, both of those patches passed "make check". the first one certainly did.
<mark_weaver>going offline for a bit. happy hacking!
<unknown_lamer>sneek: later tell mark_weaver the patch applied with a bit of minor hacking, and yow! time spent in gc every 20 secs in my demo is down from 800+ms to about 15ms (only running at all every other period about). Still not much improvement with stutter, so I guess it's statprof time... still, NaN boxing looks like a great idea...
<sneek>Okay.
<unknown_lamer>sneek: botsnack
<sneek>:)
<unknown_lamer>sneek: later tell mark_weaver (and that gc time is constant, no matter how many particles I create!)
<sneek>Okay.
<gzg>sneek: source
<sneek>Last time I checked source is at http://git.savannah.gnu.org/gitweb/?p=guile.git
<gzg>Aw. Anyone know where the bot's source is hosted?
<ijp>google bobot++
<Madsy>In scm_misc_error, the "args" parameter is a SCM list of objects to print, right?
<Madsy>So I can pass SCM_BOOL_F there?
<Madsy>Or SCM_UNSPECIFIED
<Madsy>unknown_lamer: 15ms blocking in the GC? That's not bad at all. And it still stutters?
<civodul>Hello Guilers!
<Madsy>hey civodul
<Madsy>I use scm_open_file() to get a port to a file. How can I read in the entire file as a SCM string?
<Madsy>There must be a better way than using scm_read_char() in a loop, or scm_c_read()
<dsmith>Madsy, istr using read-delimited with a delimiter of ""
<civodul>Madsy: in Scheme that would be (call-with-input-file file get-string-all)
<dsmith>I don't remember the modules right now. Look around in ice-9. Or even the manual!
<civodul>you could mimic that in C, perhaps
<Madsy>dsmith: And read-string
<Madsy>I just looked up the wrong section in the manual
<Madsy>Ah, crap. read-string doesn't have a C function
<dsmith>Doesn't mean you can't call it from C
<Madsy>scm_read_string_x_partial seem to do the same thing
<Madsy>Okay, I can use read-string with scm_call_1
<civodul>or scm_get_bytevector_all
<civodul>not ideal
<Madsy>In the C interface when using scm_call, are all the standard modules always considered loaded?
<Madsy>Or do I have to load ice-9 rdelim before my C code can depend on read-string?
<dsmith>Madsy, make sure you do a scm_variable_ref on the results of scm_lookp or scm_c_lookup
<Madsy>dsmith: I use scm_c_public_ref which dereferences implicitly, I think
<dsmith>Yep
<Madsy>Hm.. "Error while printing exception". Does that mean something went wrong while inside the smob print handler?
<Madsy>Nevermind, that doesn't make sense since I didn't print it. Maybe the REPL tried to interpret the string somehow.
<Madsy>Hm.. nope.
<mark_weaver>Madsy: scm_call doesn't care what modules are imported. that only matters when looking up symbols in the current module. scm_call takes an actual procedure object, not a symbol, so it doesn't care.
<sneek>mark_weaver, you have 2 messages.
<sneek>mark_weaver, unknown_lamer says: the patch applied with a bit of minor hacking, and yow! time spent in gc every 20 secs in my demo is down from 800+ms to about 15ms (only running at all every other period about). Still not much improvement with stutter, so I guess it's statprof time... still, NaN boxing looks like a great idea...
<sneek>mark_weaver, unknown_lamer says: (and that gc time is constant, no matter how many particles I create!)
<mark_weaver>nice!
<mark_weaver>Madsy: the error while printing exception is likely because an error happened which caused a backtrace to be printed, and then something went wrong while trying to print the stack. most likely, some SCM object on the stack in invalid in a bad way (like a bad pointer), or a smob whose printer caused an error to occur.
<mark_weaver>unknown_lamer: I was looking at my notes, and I see that I had ideas for a better tagging scheme for NaN boxing with the type tags all together in the high bits.
<mark_weaver>unknown_lamer: out of curiosity, which of the two patches did you use? and what "minor hacking" was needed? I'm pretty sure at least one of those passed "make check" for me, as-is.
<Madsy>mark_weaver: Yeah I found it. I had a wrong position argument to scm_misc_error
<Madsy>Eq is the same as using == to compare SCM pointers, right? So I can test SCM values against SCM_EOL with == ?
<mark_weaver>ah yes. so the thing is, if you throw an exception for a standard 'key', then you should follow the conventions for what 'args' should be. each 'key' has a convention for what 'args' should be passed, which the exception handler will expect.
<mark_weaver>Madsy: you can't use == because SCM values are not guaranteed to be comparable that way. in fact it is possible to build guile such that SCM values are structs (or unions? I forget)
<mark_weaver>use 'scm_is_eq'
<mark_weaver>but for SCM_EOL, it's better to use 'scm_is_null', so that it will test for #nil also (and it does so efficiently, but masing out one bit and then doing ==)
<mark_weaver>*masking
<Madsy>Right, thanks
<mark_weaver>welcome!
<mark_weaver>Madsy: btw, the code in Guile always uses SCM_UNPACK to convert a SCM to scm_t_bits (an unsigned integer), and SCM_PACK to convert back again. Those macros abstract away whatever type is being used for SCM in the current build.
<mark_weaver>if you're curious, this is all defined in tags.h. search there for SCM_DEBUG_TYPING_STRICTNESS.
<mark_weaver>to convert between non-immediate SCM values and pointers, use SCM2PTR and PTR2SCM.
<synacktic>Would using ports be considered idiomatic, given that they're stateful?
<mark_weaver>synacktic: we use ports quite often, at least for things like files, sockets, and pipes. but I suppose it depends what you were thinking of using them for.
<mark_weaver>the scheme community, and even the guile community, has quite a bit of diversity within it regarding how strongly people try to avoid mutable state.
<synacktic>mark_weaver: I want to write a simple (recursive descent) parser, but for nested pairs the calling function needs to know where the called function left off. With ports it's trivial because the state of the port changes, but I'm not sure how it would be done using, say, just strings.
<mark_weaver>personally, I'd use ports to make parser, and for strings you can use string ports.
<synacktic>Alright, thanks
<mark_weaver>some among us might try to write a haskell-style parser instead, but I think that's probably a minority.
<synacktic>Does Haskell have an elegant solution?
<Madsy>The only elegant Haskell code there is, is code that doesn't do anything ;-)
<mark_weaver>well, I haven't looked in a long time, but the simple method I saw was that a parser would take a string (which in haskell is a stream of characters), and return a list of pairs, where each pair is a parsed result and the rest of the stream.
<synacktic>Ah, that was what I was thinking of doing
<mark_weaver>as I recall, there's a paper about it, called something like "replacing failure with a list of successes"
<mark_weaver>if you wanted to go that route, I'd recommend using SRFI-41 streams.
<mark_weaver>(which was added to Guile core in 2.0.9)
<mark_weaver>SRFI-41 includes a handy "port->stream" procedure.
<synacktic>It doesn't seem like the nicest solution, tbh
<mark_weaver>well, like I said, I'd probably just use ports.
<mark_weaver>that's the usual way of doing things in the scheme community, anyway.
<mark_weaver>and using SRFI-6 string ports when needed.
***aidalgol` is now known as aidalgol