ruby-core

> -----Original Message-----
> From: Yukihiro Matsumoto [mailto:matz@ruby-lang.org]
> Sent: Thursday, August 01, 2002 9:03 AM
> To: ruby-core@ruby-lang.org
> Subject: Re: A truth? patch + benchmarks
> 
> Hi,
> 
> In message "RE: A truth? patch  + benchmarks"
>     on 02/08/01, "Christoph" <chr_news@gmx.net> writes:
> 
> |>  Not really sure but the values < 64 reserved for T_MASK
> |>
> |> #define T_NIL    0x01
> |> #define T_OBJECT 0x02
> |> [etc]
> |> #define T_NODE   0x3f
> |>
> |> #define T_MASK   0x3f
> |
> |Hm, what about using FL_USER7? More generally, is there any
> |unused flag left?
> 
> Unfortunately, there's no bit available for all objects.  All flag
> bits are used to represent NODEs' line number.

To bad ... but maybe we might see something like it in 2.0? (or
even better body smatter cooks something up for the current 
development line - maybe only replace the RTEST calls in the
crucial IF_NODE, WHILE_NODE ...  part?)

> 
> By the way, I still don't know why the inlined function is faster than
> the simple macro.  Does anybody reveal the secret for me?

I don't know (besides a not particular helpful  ``your compiler
always knows best'' ;-). Anyway  I run the two tests (on Mswin32)
subdividing the macro call RTEST(v) following strategy c) (of
my previous post)

PURE_TEST(v) = .. original macro call for
            ruby_verbose and ruby_debug test.

and setting  the rest of the RTEST(obj) macro calls to

static inline int
rb_truth_test(VALUE obj)
{
  if (~Qnil & obj) return 1;
  return 0;
}

Not surprisingly, this version tested as fast or faster then
any of my other test candidates.

/Christoph

Thread

Prev Next

In This Thread

Prev Next

[#290] — Florian Frank <flori@...>

[#291] Kernel Thread implementation — Matthew Bloch <mattbee@...>

[#297] GC longjmp macros — Michal Rokos <m.rokos@...>

[#298] Is there a bug in Matrix or Complex? — Jim Freeze <jim@...>

[#308] Q: OSSL in std. distr? — Michal Rokos <m.rokos@...>

[#309] Progress on incremental GC? — "Timothy J. Wood" <tjw@...>

[#314] resolv.rb on 1.6.7 — Dave Thomas <Dave@...>

[#316] Embeding Ruby in C++ code. — Kostas Katsamakas <kmak@...>

[#318] C and Ruby... — Kostas Katsamakas <kmak@...>

[#321] Ruby module, Warn(ing) interface — Michal Rokos <m.rokos@...>

[#326] Implications of a #force_free method in Object? — Matthew Bloch <mattbee@...>

[#328] Int vs Long — Michal Rokos <m.rokos@...>

[#329] Int vs Long #2 — Michal Rokos <m.rokos@...>

[#337] Int vs Long (2nd part) — Michal Rokos <m.rokos@...>

[#340] Int vs Long #3 — Michal Rokos <m.rokos@...>

[#345] Bug in gc.c or misunderstanding on my part? — "Timothy J. Wood" <tjw@...>

[#349] Array#select — Michal Rokos <m.rokos@...>

[#353] File (struct stat handling) — Michal Rokos <m.rokos@...>

[#355] Array and .*ALLOC.* changes — Michal Rokos <m.rokos@...>

[#358] node.h for eval.c — Michal Rokos <m.rokos@...>

[#363] Ruby embedding limitations — "Timothy J. Wood" <tjw@...>

[#367] RE: Welcome to our (ruby-core ML) You are added automatically — Girish Sharangpani <girishs@...>

[#372] rb_class_path — Michal Rokos <m.rokos@...>

[#376] Virtual host and port number in CGI — Raymond Blum <raymond@...>

[#382] Port match to new dup, clone framework — Michal Rokos <m.rokos@...>

[#387] rb_str_replace — Michal Rokos <m.rokos@...>

[#392] io.c read_all — Michal Rokos <m.rokos@...>

[#393] in dln.c — Michal Rokos <m.rokos@...>

[#394] in file.c — Michal Rokos <m.rokos@...>

[#395] CVS version and win32 naming — "Rich Kilmer" <rich@...>

RE: A truth? patch + benchmarks

Thread

In This Thread

[#355] Array and .ALLOC. changes — Michal Rokos <m.rokos@...>