Re: Using '-1' in a method named '*'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 27, 2017 at 08:21:03PM +0100, Andy Wingo wrote: > Hi, > > On Mon 27 Feb 2017 11:06, Alejandro Sanchez writes: > > > (define v (make #:x 1)) > > > > (* -1 v) ; Does not work > > (* -2 v) ; Works fine > > I believe that Guile is doing strength reduction, transforming (* -1 v) > to (- 0 v). Woah. This is somehow... exquisite. > It could be that this is totally the wrong thing. Is (* x 2) -> (+ x x) > a valid transformation if you don't know the type of x? I don't know. What we really want to know is the meaning of '*' and '+' (is that akin to constant folding?), but yes, for that we need some info about the type of x, I guess. > I think there's currently an assumption that if you extend *, that you > will do so in a mathy way, and that you implement - + and similar. But > in this case it's not the clear right thing to do. > > WDYT? We could remove this transformation, or only apply it when type > inference has run. If overloading is allowed then yes, it seems type inference has to go in first? regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAli1Lh4ACgkQBcgs9XrR2kYpEwCdGS4EaOgUy/tBL46i2Isiz1MZ sNwAnj+JM+oX7RM6LTjC8+h6r0qnIiBO =Cc5b -END PGP SIGNATURE-
Re: GNU Guile 2.1.7 released (beta)
On Tue 28 Feb 2017 00:00, Thomas Morley writes: > The main problems/TODOs are listed here (same for guile-2.0.13 and 2.1.7): > https://ao2.it/tmp/lilypond-guile2/TODO > With no warranty for completeness. > > Let me pick some of them: > (1) > lilypond filename_名字.ly > returns > fatal error: failed files: "filename_??.ly" Interesting, I would have thought that there would be a difference between 2.0.13 and 2.1.7 due to GUILE_INSTALL_LOCALE; I assume you are in a UTF-8 locale and that file name is UTF-8? > (2) > Floating point numbers are different in some decimal digits. > Possible impact on spacing in a regression-test for utf-8. If you have more details on the floating-point issue, they are very welcome :) > (3) > Most imortant for users: > LilyPond slowed down dramatically. Today I tested a huge file: > > lilypond 2.19.52 with guile-1.8 > > real9m8.229s > user6m41.156s > sys 0m11.940s > > lilypond 2.19.56 with guile-2.1.7 > > real48m45.225s > user65m43.252s > sys 0m6.320s Do you have Guile 2.0 numbers as well? I understand that Lilypond uses the "local-eval" facility a lot for embedded Scheme. This is a facility that was indeed faster in 1.8. I would expect that 2.1.7 would be faster than 2.0, if that were the case, as 2.1.7's evaluator is faster. Hard to say, though. That interface does not get a lot of speed attention. We could take a look and see what we can do. I guess we need some profiling first. Can you run lilypond under callgrind under 1.8 and 2.1.7 and attach the generated callgrind.out.PID for each run? Run like this: valgrind --tool=callgrind --num-callers=20 lilypond foo.ly Thanks, Andy
Re: Using '-1' in a method named '*'
On Mon 27 Feb 2017 20:21, Andy Wingo writes: > Hi, > > On Mon 27 Feb 2017 11:06, Alejandro Sanchez writes: > >> (define v (make #:x 1)) >> >> (* -1 v) ; Does not work >> (* -2 v) ; Works fine > > I believe that Guile is doing strength reduction, transforming (* -1 v) > to (- 0 v). I spoke too soon. Guile 2.1.x does indeed do this at compile-time, but only if "v" is an instance of a built-in number type. Guile 2.0.x doesn't do this strength reduction at all at compile-time. It turns out there is an easier way to reproduce this bug without GOOPS: (* -1 "") scm_product was handling this case specially because of weird implementation reasons (making sure that negating the most negative fixnum was a bignum; see b5c40589). In summary I think Guile's strength reduction is fine as it relies on type inference to prove when it is safe. This is "just" a bug, albeit an annoying one that we need to fix! Andy
Re: Using '-1' in a method named '*'
On Tue 28 Feb 2017 09:54, Andy Wingo writes: > In summary I think Guile's strength reduction is fine as it relies on > type inference to prove when it is safe. This is "just" a bug, albeit > an annoying one that we need to fix! Fixed in 2.0 and master. Thanks for the report :) Andy
Re: GNU Guile 2.1.7 released (beta)
Andy Wingo writes:
> On Tue 28 Feb 2017 00:00, Thomas Morley writes:
>
>> The main problems/TODOs are listed here (same for guile-2.0.13 and 2.1.7):
>> https://ao2.it/tmp/lilypond-guile2/TODO
>> With no warranty for completeness.
>>
>> Let me pick some of them:
>> (1)
>> lilypond filename_名字.ly
>> returns
>> fatal error: failed files: "filename_??.ly"
>
> Interesting, I would have thought that there would be a difference
> between 2.0.13 and 2.1.7 due to GUILE_INSTALL_LOCALE; I assume you are
> in a UTF-8 locale and that file name is UTF-8?
>
>> (2)
>> Floating point numbers are different in some decimal digits.
>> Possible impact on spacing in a regression-test for utf-8.
>
> If you have more details on the floating-point issue, they are very
> welcome :)
>
>> (3)
>> Most imortant for users:
>> LilyPond slowed down dramatically. Today I tested a huge file:
>>
>> lilypond 2.19.52 with guile-1.8
>>
>> real9m8.229s
>> user6m41.156s
>> sys 0m11.940s
>>
>> lilypond 2.19.56 with guile-2.1.7
>>
>> real48m45.225s
>> user65m43.252s
>> sys 0m6.320s
>
> Do you have Guile 2.0 numbers as well?
>
> I understand that Lilypond uses the "local-eval" facility a lot for
> embedded Scheme.
It doesn't use it at all.
> This is a facility that was indeed faster in 1.8. I would expect that
> 2.1.7 would be faster than 2.0, if that were the case, as 2.1.7's
> evaluator is faster. Hard to say, though. That interface does not
> get a lot of speed attention. We could take a look and see what we
> can do. I guess we need some profiling first.
Moot. What used to be done with local-eval before we had to come up
with a replacement (at that time, it did not appear like the facility
would be available until the migration to Guile 2.0 was completed) is a
lambda capture: the _forms_ that would have been used in local-eval are
already with some reliability determinable at the time the environment
is captured, so instead of capturing the local environment, the forms to
be evaluated later are captured as individual lambda functions in that
environment.
The feature implemented in this manner is the #{ ... #} construct for
embedding LilyPond. It is used extensively but not likely in
performance-critical contexts.
Regular read and eval, however, is used a lot during the parsing of
files and startup of LilyPond. But at least under Guile-1.8, the
parsing and preprocessing took up a rather small part of the overall
runtime (in the order of 15% or so), so it is unlikely to be responsible
for the bulk of the slowdown.
My personal guess is that the largest performance impact at the moment
will be due to an absence of generation and installation of .go files.
Since .go files are target-dependent (if I am not mistaken) and LilyPond
is cross-compiled for a number of architectures with different byte
orders and type sizes, it seems tricky to get this under wraps.
The next largest performance impact will be redecoding issues.
> Can you run lilypond under callgrind under 1.8 and 2.1.7 and attach the
> generated callgrind.out.PID for each run? Run like this:
>
> valgrind --tool=callgrind --num-callers=20 lilypond foo.ly
>
> Thanks,
>
> Andy
--
David Kastrup
Re: Guile benchmark
Chris Vine writes: > On Mon, 27 Feb 2017 21:00:54 +0100 > Andy Wingo wrote: >> Hi, >> >> On Thu 26 Jan 2017 09:39, Rchar writes: >> > https://ecraven.github.io/r7rs-benchmarks/benchmark.html >> > Is Guile slow or fast, comparing to others? >> >> Schemes that compile to native code go faster. Guile compiles to >> bytecode right now, so it's generally (though not always!) slower than >> the native-compiling schemes. But compared to the >> bytecode-interpreter schemes it's pretty fast. > > On reading this, out of interest I wrote a very simple program solving > primes, using the basic 'seive odd divisors to square root' algorithm. > I tested guile-2.0, guile-2.2, chicken and chez scheme on it. > > guile-2.0 was a little slower than chicken with chicken compiled to C, > but guile-2.2 on that test took about 75% of the time of chicken, and > about 50% of the time of guile-2.0. chez scheme was fastest of all, > taking about 50% of the time of chicken. OK, chicken may not be the > fastest of "compile to C" schemes. Do I read this correctly that Chez took only about 30% less time than Guile 2.2? Could you try stalin, too? (Chez wins 28 comparisons, Stalin 14, so that would be an obvious target) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Guile benchmark
On Tue, 28 Feb 2017 11:28:32 +0100 Arne Babenhauserheide wrote: > Chris Vine writes: > > > On Mon, 27 Feb 2017 21:00:54 +0100 > > Andy Wingo wrote: > >> Hi, > >> > >> On Thu 26 Jan 2017 09:39, Rchar writes: > >> > https://ecraven.github.io/r7rs-benchmarks/benchmark.html > >> > Is Guile slow or fast, comparing to others? > >> > >> Schemes that compile to native code go faster. Guile compiles to > >> bytecode right now, so it's generally (though not always!) slower > >> than the native-compiling schemes. But compared to the > >> bytecode-interpreter schemes it's pretty fast. > > > > On reading this, out of interest I wrote a very simple program > > solving primes, using the basic 'seive odd divisors to square root' > > algorithm. I tested guile-2.0, guile-2.2, chicken and chez scheme > > on it. > > > > guile-2.0 was a little slower than chicken with chicken compiled to > > C, but guile-2.2 on that test took about 75% of the time of > > chicken, and about 50% of the time of guile-2.0. chez scheme was > > fastest of all, taking about 50% of the time of chicken. OK, > > chicken may not be the fastest of "compile to C" schemes. > > Do I read this correctly that Chez took only about 30% less time than > Guile 2.2? > > Could you try stalin, too? (Chez wins 28 comparisons, Stalin 14, so > that would be an obvious target) I feared that my enumeration might confuse. No, on my Haswell laptop running 64-bit linux, solving the 40,000th prime (479909) is 1.26 times faster in chez scheme than in guile-2.1.7, on the simple algorithm. (0.509 seconds versus 0.624 seconds, on a i7-4712HQ CPU @ 2.30GHz.) This is only the time taken in the body of the calculation. Start-up times and printing times and so forth are ignored. I have just tried out the same code on an older Sandybridge desktop @3.30 GHz running 32-bit linux which I can access remotely, and that had chez scheme 1.7 times faster than guile-2.1.7 so it looks to be somewhat CPU and/or cache and/or pointer-width sensitive. Anyway, it is just one benchmark. I think I am about schemed out so installing Stalin is probably not an option. Like you, I am told it is fast. Guile's selling point IMO is its libraries and its FFI. Guile 2.2 certainly seems adequately fast at run time. Possibly compile times may be an issue, I don't know. Chris
Re: GNU Guile 2.1.7 released (beta)
On Tue 28 Feb 2017 10:38, David Kastrup writes: > Andy Wingo writes: >> I understand that Lilypond uses the "local-eval" facility a lot for >> embedded Scheme. > > It doesn't use it at all. Ah, tx for the info (here and below). > Regular read and eval, however, is used a lot during the parsing of > files and startup of LilyPond. But at least under Guile-1.8, the > parsing and preprocessing took up a rather small part of the overall > runtime (in the order of 15% or so), so it is unlikely to be responsible > for the bulk of the slowdown. > > My personal guess is that the largest performance impact at the moment > will be due to an absence of generation and installation of .go files. This makes sense to me. As you know, using .go files allows you to avoid read and expansion costs at run-time. I guess Lilypond disables auto-compilation for its Scheme files also, and doesn't manually compile files / expressions? In that case you're also suffering the slower "eval" in 2.0 / 2.2 compared to 1.8 and not benefitting from the compiler. I agree that fixing that would probably be the first step for someone working on Lilypond perf. > Since .go files are target-dependent (if I am not mistaken) and LilyPond > is cross-compiled for a number of architectures with different byte > orders and type sizes, it seems tricky to get this under wraps. Yeah. In both 2.0 and 2.2 there are only four "targets" really (32-bit and 64-bit, big- and little-endian), so it's somewhat manageable. "guild compile" does support cross-compilation, and I think there are some projects that do so; but yep, wiring that up can be tricky like you say. Andy
Re: Using '-1' in a method named '*'
> On 28 Feb 2017, at 10:19, Andy Wingo wrote: > > On Tue 28 Feb 2017 09:54, Andy Wingo writes: > >> In summary I think Guile's strength reduction is fine as it relies on >> type inference to prove when it is safe. This is "just" a bug, albeit >> an annoying one that we need to fix! > > Fixed in 2.0 and master. Thanks for the report :) > > Andy Great, than you. Do you have any approximation on when a release with that fix will happen, or am I better off getting the source and building myself? I would rather not mess around with building, but I’ll bit the bullet and build myself if that’s the way to go. I am currently on 2.0.14 because my package manager only offers the latest stable release.
Re: Using '-1' in a method named '*'
Le 28/02/2017 à 15:24, Alejandro Sanchez a écrit : On 28 Feb 2017, at 10:19, Andy Wingo wrote: On Tue 28 Feb 2017 09:54, Andy Wingo writes: In summary I think Guile's strength reduction is fine as it relies on type inference to prove when it is safe. This is "just" a bug, albeit an annoying one that we need to fix! Fixed in 2.0 and master. Thanks for the report :) Andy Great, than you. Do you have any approximation on when a release with that fix will happen, or am I better off getting the source and building myself? I would rather not mess around with building, but I’ll bit the bullet and build myself if that’s the way to go. I am currently on 2.0.14 because my package manager only offers the latest stable release. I think git checkout and compiling is worth it. git clone http://git.sv.gnu.org/r/guile.git Don't forget to ./configure --prefix=/usr. Regards, Amirouche ~ amz3
[ANN] nyacc version 0.76.5 released
NYACC version 0.76.5 is released. This release contains more C preprocessor bug fixes and a C99 pretty-printer bug fix. NYACC, for Not Yet Another Compiler Compiler!, is set of guile modules for generating parsers and lexical analyzers. It also provides sample parsers and pretty-printers using SXML trees as an intermediate representation. NYACC is beta level maturity. NYACC is free software; the full source distribution is available through tarball repository: https://download.savannah.gnu.org/releases/nyacc/ git repository: git://git.savannah.nongnu.org/nyacc.git home page and project page: http://www.nongnu.org/nyacc https://savannah.nongnu.org/projects/nyacc For support see: https://savannah.nongnu.org/support/?group=nyacc
Re: Using '-1' in a method named '*'
On Tue, Feb 28, 2017 at 06:53:33PM +0100, Amirouche wrote: > > > Don't forget to ./configure --prefix=/usr. Unless you run this on a self-compiled syytem that seems like a very bad idea. You will happily overwrite a distribution provided guile and during the next system update your package manager will happily erase your custom guile and install the distribution version. Binaries installed into /usr/local (the default chosen by autoconf) will be the first binary found in the path in all distibutions I have seen so far. Cheers, Ralf Mattes > Regards, > > Amirouche ~ amz3 >
Re: Guile benchmark
Chris Vine writes: > No, on my Haswell laptop running 64-bit linux, solving the 40,000th > prime (479909) is 1.26 times faster in chez scheme than in guile-2.1.7, > on the simple algorithm. (0.509 seconds versus 0.624 seconds, on a > i7-4712HQ CPU @ 2.30GHz.) This is only the time taken in the body of > the calculation. Start-up times and printing times and so forth are > ignored. Ah, ok. Thank you! > I have just tried out the same code on an older Sandybridge desktop > @3.30 GHz running 32-bit linux which I can access remotely, and that had > chez scheme 1.7 times faster than guile-2.1.7 so it looks to be > somewhat CPU and/or cache and/or pointer-width sensitive. Anyway, it is > just one benchmark. > > I think I am about schemed out so installing Stalin is probably not an > option. Like you, I am told it is fast. Guile's selling point IMO is > its libraries and its FFI. Guile 2.2 certainly seems adequately fast > at run time. Possibly compile times may be an issue, I don't know. Factor 10 between C++ and pure Scheme is pretty awesome. Implementing algorithms in pure Python carries a penalty of easily factor 100 (though delegating anything expensive to builtin operators is fast). Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
