List Info

Thread: Math::BigInt::FastCalc v0.15
Math::BigInt::FastCalc v0.15
user name
 2007-05-27 09:43:15 

  


  

    MOIN,

A PATCH TO UPDATE MATH::BIGINT::FASTCALC IN BLEAD TO V0.15. NOTEWORTHY 
CHANGES:

* ALIAS THE _NOK() METHOD SO THAT BNOK() CAN USE IT THROUGH CALC
* ADD _NEW() TO THE XS CODE, MAKING ->NEW() FASTER. FOR SMALL NUMBERS
  IT IS ABOUT 10% FASTER, AND UP TO 25% FOR LARGE/HUGE NUMBERS. THIS
  SPEEDUP IS VISIBLE IN MATH::BIGINT, BTW, NOT JUST DEEP DOWN IN THE
  LOWER LEVEL LIBRARY. SEE ATTACHED BENCHMARK.

ONE ISSUE THAT CAME TO LIGHT IS THAT A SEEMINGLY SIMPLE OPERATION AS:

	USE MATH::BIGFLOAT;
	$X = MATH::BIGFLOAT->NEW('0.008'); $Y = MATH::BIGFLOAT->NEW(2);
	$X->BDIV(3,$Y);

CAUSES 27 CALLS TO _NEW() INSIDE CALC/FASTCALC. THIS SUGGESTS SOME 
COMPLICATED OPERATIONS INSIDE BIGFLOAT/BIGINT, WHICH SHOULD BE 
INVESTIGATED, SOWE CAN MINIMIZE THE CALLS.

ANOTHER ODDITY I NOTICED IS THAT FOR MAGIC STRINGS (LIKE MATCHES COMING OUT 
OF THE REGEXP ENGINE), THE FOLLOWING FAILED UNDER V5.8.8:


      SVPV(X, LEN);	/* CONVERT TO STRING & STORE LENGTH */
      CUR = SVEND(X);	/* POINTS TO  INSTEAD */

THIS SOLVES IT:

      CUR = SVPV(X, LEN);	/* CONVERT TO STRING & STORE LENGTH */
      CUR += LEN;

HOWEVER, I AM NOT SURE IS THIS A BUG IN PERL OR JUST MY POOR UNDERSTANDING 
OF XS.

ALL THE BEST,

TELS

-- 
 SIGNED ON SUN MAY 27 14:17:09 2007 WITH KEY 0X93B84C15.
 GET ONE OF MY PHOTO POSTERS: HTTP://BLOODGATE.COM/POSTERS
 PGP KEY ON HTTP://BLOODGATE.COM/TELS.ASC OR PER EMAIL.

 "I AM SOO CLUMSY TODAY." *CRASH*



  

  
  
   
     
    
 
        Approximate file size 3246 bytes
    

    
    
 
        Approximate file size 1084 bytes
    

    
    
 
        Approximate file size 4734 bytes
    

    
    

  

    Re:  Math::BigInt::FastCalc v0.15
  


  

     user name

     2007-05-27 10:26:40
  


  

    
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Sunday 27 May 2007 14:43:15 Tels wrote:
> Moin,
>
> a patch to update Math::BigInt::FastCalc in blead to
v0.15. Noteworthy
> changes:
>
> * alias the _nok() method so that Bnok() can use it
through Calc
> * add _new() to the XS code, making ->new() faster.
For small numbers
>   it is about 10% faster, and up to 25% for large/huge
numbers. This
>   speedup is visible in Math::BigInt, btw, not just
deep down in the
>   lower level library. See attached benchmark.
>
> One issue that came to light is that a seemingly simple
operation as:
>
> 	use Math::BigFloat;
> 	$x = Math::BigFloat->new('0.008'); $y =
Math::BigFloat->new(2);
> 	$x->bdiv(3,$y);
>
> causes 27 calls to _new() inside Calc/FastCalc. This
suggests some
> complicated operations inside BigFloat/BigInt, which
should be
> investigated, sowe can minimize the calls.

Even stranger is that when running under Calc (e.g. not
FastCalc) it becomes 
49 calls. The reason is that somewhere along the way $scale
becomes a 
BigInt object, which then gets stored as a part of a
BigFloat - this 
shouldn't even happen and I am surprised it actually works.
(The reason it 
works is probably because BigInt's overload magic is
sufficiently 
transparent enough that things just get slower, but don't
blowup).

Still investigating the problem (which is somewhere inside
BigInt or 
BigFloat).

Tels

- -- 
 Signed on Sun May 27 15:26:38 2007 with key 0x93B84C15.
 Get one of my photo posters: http://bloodgate.com/pos
ters
 PGP key on http://bloodgate.com/te
ls.asc or per email.

 "One man in a thousand is a leader of men, the other
999 follow women"

  -- Groucho Marx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRlmjMHcLPEOTuEwVAQKeTAf/VPPKo+ZypphTrc1kU6hlLDCmEB9n
PpRp
aTqYU9hYWlGrQr0/J6ZWC4PVkq9/QtiMQCfGG8ULenCwQF+qw9nr5aFb2F4C
c4ks
pk8J5N43AXw8WTt6dRko2WbzXw6v+tHp+4eej21sIYbGUOHkKkNsWcJJxEdT
eOBm
WhRHhWEWDvSD1NxqMKT3DBTYPsS8sfXJ7Z/1AZOkXl4RzqogTgxHSItMhDPT
aloO
PFzu4rkWmWqI5nAc1jK2o4x+VX565msO2zpeo2IhlHrt133MUbJ12HjTmell
gJ4N
yEX0sVkYiQrJjH/3ibEVLBJKyCPTvQplLvxgl/BaURDjnRsmu1RPww==
=9zf4
-----END PGP SIGNATURE-----



  


  

    
  

  
  
   
     
    

  

    Re:  Math::BigInt v1.87 take 5
  


  

     user name

     2007-05-27 10:54:29
  


  

    

  


  

    MOIN,

ON SUNDAY 27 MAY 2007 15:26:40 TELS WROTE:
> MOIN,
>
> ON SUNDAY 27 MAY 2007 14:43:15 TELS WROTE:
> > MOIN,
> >
> > A PATCH TO UPDATE MATH::BIGINT::FASTCALC IN BLEAD TO V0.15. NOTEWORTHY
> > CHANGES:
> >
> > * ALIAS THE _NOK() METHOD SO THAT BNOK() CAN USE IT THROUGH CALC
> > * ADD _NEW() TO THE XS CODE, MAKING ->NEW() FASTER. FOR SMALL NUMBERS
> >   IT IS ABOUT 10% FASTER, AND UP TO 25% FOR LARGE/HUGE NUMBERS. THIS
> >   SPEEDUP IS VISIBLE IN MATH::BIGINT, BTW, NOT JUST DEEP DOWN IN THE
> >   LOWER LEVEL LIBRARY. SEE ATTACHED BENCHMARK.
> >
> > ONE ISSUE THAT CAME TO LIGHT IS THAT A SEEMINGLY SIMPLE OPERATION AS:
> >
> > 	USE MATH::BIGFLOAT;
> > 	$X = MATH::BIGFLOAT->NEW('0.008'); $Y = MATH::BIGFLOAT->NEW(2);
> > 	$X->BDIV(3,$Y);
> >
> > CAUSES 27 CALLS TO _NEW() INSIDE CALC/FASTCALC. THIS SUGGESTS SOME
> > COMPLICATED OPERATIONS INSIDE BIGFLOAT/BIGINT, WHICH SHOULD BE
> > INVESTIGATED, SOWE CAN MINIMIZE THE CALLS.
>

> EVEN STRANGER IS THAT WHEN RUNNING UNDER CALC (E.G. NOT FASTCALC) IT
> BECOMES 49 CALLS. THE REASON IS THAT SOMEWHERE ALONG THE WAY $SCALE
> BECOMES A BIGINT OBJECT, WHICH THEN GETS STORED AS A PART OF A BIGFLOAT -
> THIS SHOULDN'T EVEN HAPPEN AND I AM SURPRISED IT ACTUALLY WORKS. (THE
> REASON IT WORKS IS PROBABLY BECAUSE BIGINT'S OVERLOAD MAGIC IS
> SUFFICIENTLY TRANSPARENT ENOUGH THAT THINGS JUST GET SLOWER, BUT DON'T
> BLOWUP).
>
> STILL INVESTIGATING THE PROBLEM (WHICH IS SOMEWHERE INSIDE BIGINT OR
> BIGFLOAT).

THE ATTACHED PATCH (PLEASE APPLY ON TOP OF TAKE 4, WHICH I ATTACHED AGAIN IN 
CASE IT GOT LOST) FIXES THE PROBLEM. WHEN THE PASSED $A WAS AN OBJECT, IT 
WOULD CREATE OBJECTS INSIDE CALC E.G. YOU GOT AN ARRAY REF WHICH CONTAINED 
A MATH::BIGINT ISTEAD OF A NORMAL INT.

SO INSTEAD OF:

	[ 33 ]

YOU HAD:

	[ MATH::BIGINT->NEW(33) ]

TRULY AMAZING IS THAT THIS DID NEVER CAUSE ANYTHING TO BLOW UP BECAUSE THE 
OVERLOADED MATH WAS SO PERFECT. IT JUST WASTED A LOT OF MEMORY AND CPU TIME 
AS THE BIGINT-PARTS "INFECTED" EVERY OTHER PART IT CAME INTO CONTACT WITH 
TO BE A BIGINT, TOO, AND SO IT WOULD SPREAD FROM NUMBER TO NUMBER.


HERE IS THE BENCHMARK:

BENCHMARK: RUNNING BDIV(3,4), BDIV(3,NEW(4)) FOR AT LEAST 5 CPU SECONDS...
 BDIV(3,4):      5S (5.34 USR +  0.00 SYS =  5.34 CPU)  4366.85/S (N=23319)

 BDIV(3,NEW(4)): 5S (5.26 USR +  0.00 SYS =  5.26 CPU)  468.06/S (N=2462)
TELINUX:~/PERL/MATH/MATH-BIGINT-1.87> PERL -ILIB T.PL
BENCHMARK: RUNNING BDIV(3,4), BDIV(3,NEW(4)) FOR AT LEAST 5 CPU SECONDS...
 BDIV(3,4):      6S (5.26 USR +  0.00 SYS =  5.26 CPU)  4318.06/S (N=22713)

BDIV(3,NEW(4)):  5S (5.29 USR +  0.00 SYS =  5.29 CPU)  4194.33/S (N=22188)


ALL THE BEST,

TELS

-- 
 SIGNED ON SUN MAY 27 15:44:14 2007 WITH KEY 0X93B84C15.
 GET ONE OF MY PHOTO POSTERS: HTTP://BLOODGATE.COM/POSTERS
 PGP KEY ON HTTP://BLOODGATE.COM/TELS.ASC OR PER EMAIL.

 "ANY SUFFICIENTLY RIGGED DEMO IS INDISTINGUISHABLE FROM AN ADVANCED
 TECHNOLOGY." 

  -- DON QUIXOTE, SLASHDOT GUY

  

  
  
   
     
    
 
        Approximate file size 2619 bytes
    

    
    
 
        Approximate file size 10844 bytes
    

    
    

  

    Re:  Math::BigInt v1.87 take 5
  


  

     user name

     2007-05-27 10:54:29
  


  

    

  


  

    MOIN,

ON SUNDAY 27 MAY 2007 15:26:40 TELS WROTE:
> MOIN,
>
> ON SUNDAY 27 MAY 2007 14:43:15 TELS WROTE:
> > MOIN,
> >
> > A PATCH TO UPDATE MATH::BIGINT::FASTCALC IN BLEAD TO V0.15. NOTEWORTHY
> > CHANGES:
> >
> > * ALIAS THE _NOK() METHOD SO THAT BNOK() CAN USE IT THROUGH CALC
> > * ADD _NEW() TO THE XS CODE, MAKING ->NEW() FASTER. FOR SMALL NUMBERS
> >   IT IS ABOUT 10% FASTER, AND UP TO 25% FOR LARGE/HUGE NUMBERS. THIS
> >   SPEEDUP IS VISIBLE IN MATH::BIGINT, BTW, NOT JUST DEEP DOWN IN THE
> >   LOWER LEVEL LIBRARY. SEE ATTACHED BENCHMARK.
> >
> > ONE ISSUE THAT CAME TO LIGHT IS THAT A SEEMINGLY SIMPLE OPERATION AS:
> >
> > 	USE MATH::BIGFLOAT;
> > 	$X = MATH::BIGFLOAT->NEW('0.008'); $Y = MATH::BIGFLOAT->NEW(2);
> > 	$X->BDIV(3,$Y);
> >
> > CAUSES 27 CALLS TO _NEW() INSIDE CALC/FASTCALC. THIS SUGGESTS SOME
> > COMPLICATED OPERATIONS INSIDE BIGFLOAT/BIGINT, WHICH SHOULD BE
> > INVESTIGATED, SOWE CAN MINIMIZE THE CALLS.
>

> EVEN STRANGER IS THAT WHEN RUNNING UNDER CALC (E.G. NOT FASTCALC) IT
> BECOMES 49 CALLS. THE REASON IS THAT SOMEWHERE ALONG THE WAY $SCALE
> BECOMES A BIGINT OBJECT, WHICH THEN GETS STORED AS A PART OF A BIGFLOAT -
> THIS SHOULDN'T EVEN HAPPEN AND I AM SURPRISED IT ACTUALLY WORKS. (THE
> REASON IT WORKS IS PROBABLY BECAUSE BIGINT'S OVERLOAD MAGIC IS
> SUFFICIENTLY TRANSPARENT ENOUGH THAT THINGS JUST GET SLOWER, BUT DON'T
> BLOWUP).
>
> STILL INVESTIGATING THE PROBLEM (WHICH IS SOMEWHERE INSIDE BIGINT OR
> BIGFLOAT).

THE ATTACHED PATCH (PLEASE APPLY ON TOP OF TAKE 4, WHICH I ATTACHED AGAIN IN 
CASE IT GOT LOST) FIXES THE PROBLEM. WHEN THE PASSED $A WAS AN OBJECT, IT 
WOULD CREATE OBJECTS INSIDE CALC E.G. YOU GOT AN ARRAY REF WHICH CONTAINED 
A MATH::BIGINT ISTEAD OF A NORMAL INT.

SO INSTEAD OF:

	[ 33 ]

YOU HAD:

	[ MATH::BIGINT->NEW(33) ]

TRULY AMAZING IS THAT THIS DID NEVER CAUSE ANYTHING TO BLOW UP BECAUSE THE 
OVERLOADED MATH WAS SO PERFECT. IT JUST WASTED A LOT OF MEMORY AND CPU TIME 
AS THE BIGINT-PARTS "INFECTED" EVERY OTHER PART IT CAME INTO CONTACT WITH 
TO BE A BIGINT, TOO, AND SO IT WOULD SPREAD FROM NUMBER TO NUMBER.


HERE IS THE BENCHMARK:

BENCHMARK: RUNNING BDIV(3,4), BDIV(3,NEW(4)) FOR AT LEAST 5 CPU SECONDS...
 BDIV(3,4):      5S (5.34 USR +  0.00 SYS =  5.34 CPU)  4366.85/S (N=23319)

 BDIV(3,NEW(4)): 5S (5.26 USR +  0.00 SYS =  5.26 CPU)  468.06/S (N=2462)
TELINUX:~/PERL/MATH/MATH-BIGINT-1.87> PERL -ILIB T.PL
BENCHMARK: RUNNING BDIV(3,4), BDIV(3,NEW(4)) FOR AT LEAST 5 CPU SECONDS...
 BDIV(3,4):      6S (5.26 USR +  0.00 SYS =  5.26 CPU)  4318.06/S (N=22713)

BDIV(3,NEW(4)):  5S (5.29 USR +  0.00 SYS =  5.29 CPU)  4194.33/S (N=22188)


ALL THE BEST,

TELS

-- 
 SIGNED ON SUN MAY 27 15:44:14 2007 WITH KEY 0X93B84C15.
 GET ONE OF MY PHOTO POSTERS: HTTP://BLOODGATE.COM/POSTERS
 PGP KEY ON HTTP://BLOODGATE.COM/TELS.ASC OR PER EMAIL.

 "ANY SUFFICIENTLY RIGGED DEMO IS INDISTINGUISHABLE FROM AN ADVANCED
 TECHNOLOGY." 

  -- DON QUIXOTE, SLASHDOT GUY

  

  
  
   
     
    
 
        Approximate file size 2619 bytes
    

    
    
 
        Approximate file size 10844 bytes
    

    
    

  

    Re:  Math::BigInt::FastCalc v0.15
  


  

     user name

     2007-05-28 04:46:07
  


  

    
On 27/05/07, Tels <nospam-abusebloodgate.com> wrote:
> a patch to update Math::BigInt::FastCalc in blead to
v0.15.

Thanks, applied as #31284.



  


  

    
  

  
  
   
     
    

  

    Re:  Math::BigInt::FastCalc v0.15
  


  

     user name

     2007-05-28 04:57:27
  


  

    
On Sun, May 27, 2007 at 02:43:15PM +0000, Tels wrote:

> Another oddity I noticed is that for magic strings
(like matches coming out 
> of the regexp engine), the following failed under
v5.8.8:
> 
>       SvPV(x, len);	/* convert to string & store
length */
>       cur = SvEND(x);	/* points to  instead */
> 
> This solves it:
> 
>       cur = SvPV(x, len);	/* convert to string &
store length */
>       cur += len;
> 
> However, I am not sure is this a bug in Perl or just my
poor understanding 
> of XS.

I don't know for sure, either.
If you add

   sv_dump(x);

at that point, what is the dump output for one of the magic
strings?

Nicholas Clark



  


  

    
  

  
  
   
     
    

  

    Re:  Math::BigInt v1.87 take 5
  


  

     user name

     2007-05-28 05:17:52
  


  

    
On 27/05/07, Tels <nospam-abusebloodgate.com> wrote:
> The attached patch (please apply on top of take 4,
which I attached again in
> case it got lost) fixes the problem. When the passed $A
was an object, it
> would create objects inside Calc e.g. you got an array
ref which contained
> a Math::BigInt istead of a normal int.

Thanks, applied as #31285.



  


  

    
  

  
  
   
     
    

  

    Re:  Math::BigInt::FastCalc v0.15
  


  

     user name

     2007-05-28 09:02:34
  


  

    
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Monday 28 May 2007 09:57:27 Nicholas Clark wrote:
> On Sun, May 27, 2007 at 02:43:15PM +0000, Tels wrote:
> > Another oddity I noticed is that for magic strings
(like matches coming
> > out of the regexp engine), the following failed
under v5.8.8:
> >
> >       SvPV(x, len);	/* convert to string &
store length */
> >       cur = SvEND(x);	/* points to  instead */
> >
> > This solves it:
> >
> >       cur = SvPV(x, len);	/* convert to string
& store length */
> >       cur += len;
> >
> > However, I am not sure is this a bug in Perl or
just my poor
> > understanding of XS.
>
> I don't know for sure, either.
> If you add
>
>    sv_dump(x);
>
> at that point, what is the dump output for one of the
magic strings?

Oh, this problem can only be reproduced if I put in the code
that caused 
parts inside Calc to get BigInts (so it doesn't happen in
the normal 
FastCalc testsuite). But with that code, the follow perl
snipped triggers 
it:

	use Math::BigFloat;
	$x = Math::BigFloat->new('0.008'); $y =
Math::BigFloat->new(29);
	$x->bdiv(3,$y);

And this:

      end = SvPV(x, len);
      end += len;
      cur = SvEND(x);
      if (end != cur)
        {
        printf ("end: %p, cur: %pn", cur, end);
        sv_dump(x);
        }

produces this:

	# perl -Ilib -Iblib/arch t.pl
	end: 0xb16ac0, cur: 0x669a32
	SV = PVIV(0x9c7d20) at 0x786590
	  REFCNT = 1
	  FLAGS = (PADBUSY,PADMY,ROK,OVERLOAD)
	  IV = 0
	  RV = 0xb16ac0
	  PV = 0xb16ac0 ""
	  CUR = 0
	  LEN = 0
	Argument "" isn't numeric in addition (+)
	 at /usr/lib/perl5/5.8.8/Math/BigInt/Calc.pm line 281.
	end: 0xb16ac0, cur: 0x669a12
	SV = PVIV(0x9c7d20) at 0x786590
	  REFCNT = 1
	  FLAGS = (PADBUSY,PADMY,ROK,OVERLOAD)
	  IV = 0
	  RV = 0xb16ac0
	  PV = 0xb16ac0 ""
	  CUR = 0
	  LEN = 0
	Argument "" isn't numeric in numeric eq (==)
	 at /usr/lib/perl5/5.8.8/Math/BigInt/Calc.pm line 304.

Hm. So I should have checked for SvPOK() before accessing
SvEND() I guess. 
OTOH, how is my XS code supposed to handle an overloaded
string, anyway?

Best wishes,

Tels


- -- 
 Signed on Mon May 28 13:55:41 2007 with key 0x93B84C15.
 View my photo gallery: http://bloodgate.com/phot
os
 PGP key on http://bloodgate.com/te
ls.asc or per email.

 "Call me Justin, Justin Case."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRlrhAXcLPEOTuEwVAQKpLgf7BBeGOQhjmA2NcDixev2WIy6gaD06
CdK+
k45z+bd3n64TMwCqMaKb1X+cC9Pw8bE/Fdlwf4JWLNgvBbVN5Tr8IVTcecKH
QNqA
WvWc/o+lTCa27BUSRWUklkaxlCZRd8K14ME0qGlHN50rXAwO6dO3HT3ZCMI9
Zg4E
tD72tNeN1nutZKQPBI5cgswF6TgZKz7YNbhtvfSvKOZC8NEjDgy1e2ugS1jQ
REg+
ReiaCeXaWIjLVx/r1VT1QFFQcVJpa24iE4O0U9R+dLlz3Uc+vjRdeFiMU09K
Alpm
ZwMQSg37RMu13oxpc4IXZs5sOXdbgNzR1rdE6d/sKc5Bxt66Bx/TXA==
=qzWc
-----END PGP SIGNATURE-----



  


  

    
  

  
  
   
     
    

  

    Re:  Math::BigInt::FastCalc v0.15
  


  

     user name

     2007-05-28 07:19:13
  


  

    
On 5/28/07, Tels <nospam-abusebloodgate.com> wrote:
> OTOH, how is my XS code supposed to handle an
overloaded string, anyway?

Very very carefully. 

yves
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"



  


  

    
  

  
  
   
     
    

  

    Re:  Math::BigInt::FastCalc v0.15
  


  

     user name

     2007-05-28 09:27:38
  


  

    
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Monday 28 May 2007 12:19:13 demerphq wrote:
> On 5/28/07, Tels <nospam-abusebloodgate.com> wrote:
> > OTOH, how is my XS code supposed to handle an
overloaded string,
> > anyway?
>
> Very very carefully. 

That was not very helpfull 

The OVERLOAD flag is not mention in perlatlas:

	http://bloodg
ate.com/wiki/POD:perlatlas

And neither does perldoc perlguts. perldoc perlxs contains
some stuff about 
writing overload routines yourself, but nothing about what
you do when you 
get passed an SV with OVERLOAD on.

All the best,

Tels

- -- 
 Signed on Mon May 28 14:26:23 2007 with key 0x93B84C15.
 View my photo gallery: http://bloodgate.com/phot
os
 PGP key on http://bloodgate.com/te
ls.asc or per email.

 "Boooooooring!"

  -- Dot, the Warner sister
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBRlrm23cLPEOTuEwVAQLRdQf/S61LGThEeEfCV5eqbk3GguYATGKW
9aQi
QBKiiXceZCOJx+SEftmsF4sSp7OTeomke3+sJ/U0MSAg8YN9iRsBL6YBSBRF
c4x/
jbGP3ieFixBK/JDmks8vs9HdGVXCThx3duPP1hyD0HcrTdgW2BOlhGE60PoX
zve0
8tUF2oS62011t8l87BpWnLn0/mvfgdOaPYYo9kNToGS4k2fVMAcj2LAy6WZm
GYqN
Lj61+r3RM7A+SC3J2rd4T8lX7HXBdkZiP+JAKOm7xe+PEF/uEOsXUo3sH+Br
Udwg
Dhu7VQnOU5kvlziY2vDgfCoBfGL3h5Nwhd9+PER8zRScTkH5I75jyA==
=K4zG
-----END PGP SIGNATURE-----



  


  

    
  

  
  
   
     
    






 [1-10] [11-13]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )