A truth? patch + benchmarks

["Christoph" <chr_news@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]



> -----Original Message-----
> From: YANAGAWA Kazuhisa [mailto:kjana@dm4lab.to]
> Sent: Friday, July 26, 2002 12:11 PM
> To: ruby-core@ruby-lang.org
> Subject: Re: [PATCH] object.c ruby.h (fwd)
> 
> In message <m2bs8vr1h7.fsf@zip.local.thomases.com>
> Dave@PragmaticProgrammer.com writes:
> 
> > So, perhaps, if the expression to pass to 'if', 'while', and friends
> > isn't 'true' or 'false', the interpreter should call #truth? on it
to
> > coerce it into a truth value.[1]
> >
> > If that sounds logical, then perhaps #to_truth might be a more
> > consistent name.
> 
> That's like my old proposal on.... where? :-) Matz rejected that since
> its cost may be too expensive.  So if you state it strongly, show its
> usefulness and effective implementation.

Trying to answer your first question, it seems to me that
Every time you are dealing with the Null-Pattern such a
facility might come in handy. The proliferation of the
``false'' value in Python and indirectly the existence of
the conversion methods #to_something in the NilClass are a
testimony for this.


I also cooked up simple minded an implementation. It is based on
a FL_FALSE flag (I defined it to be 1<<5 not sure if this can
case any problem?) similar to the frozen or tainted flags - that
is I added there methods (the method names ain't great ..)

#falsify : the ``truth-state'' is set to false)
#verify  : the ``truth-state'' is set to true)
#truth?  : tests the truth state.
           obj.truth? returns true if obj is
           an immediate value != false,nil (in other
           words obj is a Symbol, Fixnum or ``True'')
           or obj non immediate object and the false
           flag is not set.


A welcome side affect of this implementation is, that you
cannot change the truth-state of Fixnums and O particular
so Perl fans would be still pissed off;-)).
 

A few words about the included benchmarks.  I pitted
3 type of implementation (and two compilers Mingw32
and VC7) against each other. 

a) Stock Ruby (as of today).
b) The patched Ruby
c) The patched Ruby where I replaced the macro calls 
   RTEST(ruby_debug) and RTEST(rbuy_verbose)
   with PURE_RTEST(ruby_debug) and PURE_RTEST(ruby_verbose)
   macro call - where PURE_TEST is ``original RTEST'' macro.


The first test is a gc and memory intensive problem.
(It is a solution to Tobias Reif [ruby-talk:33425]
maximal anagram chain problem - my wordlist contains
about 230,000 English words).

In this test a) & b) perform about the same but c)
is ~ 10 percent faster.


The second test is the simple ``program flow
test'' (no gc work involved).

---
# loop.rb
require 'benchmark'
include Benchmark


i = 0
bm do |x|
  x.report do
    while (i) do
     i+= 1
     i = nil if i == 5000000
   end
  end
end 
---
 
The result are quite surprising. Both b) and c)
(which is slightly slower in this case) outperform
a) by almost 20 percent.


All in all even if the false flag scheme is
rejected it is probably a good idea to replace
some of the current RTEST(obj) macro calls
with an inlined c-function version.



/Christoph

[-- Attachment #2: bench.tar.gz --]
[-- Type: application/octet-stream, Size: 2182 bytes --]

[-- Attachment #3: patch.tar.gz --]
[-- Type: application/octet-stream, Size: 1037 bytes --]