|
From: | Peter Bex |
Subject: | [Chicken-hackers] [PATCH] Fix (restore?) specializations from types.db when compiling core itself |
Date: | Wed, 18 Nov 2015 19:58:49 +0100 |
User-agent: | Mutt/1.5.21 (2010-09-15) |
Hi hackers, A while ago I was digging into CHICKEN's worrisome I/O performance and I noticed that read-char isn't compiled as efficiently as one would expect it to be: the argument type check isn't inlined as it should, even though there is a specialization in types.db, and it calls read-char/port which is a full CPS call. See also ticket #1219. So today I took a look into why this is happening, and the reason seems pretty simple: normally, when you have a file that contains code and type declarations plus specializations, the type is marked as "declared" rather than the default, which I guess is "inferred". Types declarations loaded via an external database should be treated identically to inline declarations, I think, but those are currently not marked as "declared". The missing marking causes the code in "initial-argument-types" and "variable-result" (in scrutinizer.scm) to use the "*" wildcard rather than the actual declared type. This somehow means specializations won't be triggered. I'm not 100% sure why that's the case. There was another ticket made by Felix, #745, which indicates that really we want a user definition to invalidate type specialization for a procedure of the same name. This was closed after I noted that specializations already don't occur. However, the current behaviour is more of an accident than an actual feature: the specializations list on the identifier isn't removed, and in fact, if the procedure's type is declared inside the file, this will cause the specializations to be triggered again, even if the type is different (I think). So I re-opened #745 as this will need a "proper" fix, obliterating the specializations and declared procedure type. The first attached patch simply adds the "declared-type" variable mark to all types that were loaded via an external database. Adding this also found some inconsistent types between types.db and the definitions in library.scm and tcp.scm, so I've fixed those as well (the third patch). The second patch simply copies the body of read-char/port into read-char, exactly like we already do in write-char and write-char/port. I'm not sure that's the best solution, but it's better than the current situation. Attached is also a diff of the benchmarks, and you can clearly see the benefit this has in the difference between "test" and "master" on the kernwyk-wc and kernwyk-cat benchmarks, as I hoped it would. The slatex benchmark doesn't show much of an improvement, but it does a lot more than just reading, of course. I can't really explain the differences in the other benchmarks, but I guess some of those are just noise, or the result of changing stacks due to the specializations in library.scm. Cheers, Peter
0001-Mark-external-type-declarations-as-declared.chicken-5.patch
Description: Text Data
0002-Avoid-CPS-call-in-read-char-to-read-char-port.chicken-5.patch
Description: Text Data
0003-Fix-a-few-incorrect-type-declarations.chicken-5.patch
Description: Text Data
0001-Mark-external-type-declarations-as-declared.master.patch
Description: Text Data
0002-Avoid-CPS-call-in-read-char-to-read-char-port.master.patch
Description: Text Data
0003-Fix-a-few-incorrect-type-declarations.master.patch
Description: Text Data
benchmarks.diff
Description: Text Data
signature.asc
Description: Digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |