7 Jan 2008, at 22:39, Andy Armstrong wrote:
I now have a dtraced bleadperl which runs no slower than the clean
version:

orig | dtrace | ratio

2.51239896 | 2.47904992 | 0.98672622
2.50696611 | 2.46995783 | 0.98523782
2.52996778 | 2.47554016 | 0.97848683
2.50457382 | 2.47788405 | 0.98934359
2.50622296 | 2.46893001 | 0.98511986

I should explain that those times are for a tight loop repeatedly
calling an empty sub.

6 Jan 2008, at 16:28, Nicholas Clark wrote:
However, the counter argument is that if it is possible to get the C
code that
is currently a speed hit re-implemented in D, then there is no speed
hit in
having every perl dtrace enabled. Which seems like a much better
thing long
term, as it would mean that any user of Perl on Solaris, FreeBSD, S
X, etc
would be able to use dtrace instrumentation immediately, and on
running
processes, even if they don't have the permission to install modules
from
CPAN. (Heck, they don't even have to be aware of modules on CPAN)

I now have a dtraced bleadperl which runs no slower than the clean
version:

orig | dtrace | ratio

2.51239896 | 2.47904992 | 0.98672622
2.50696611 | 2.46995783 | 0.98523782
2.52996778 | 2.47554016 | 0.97848683
2.50457382 | 2.47788405 | 0.98934359
2.50622296 | 2.46893001 | 0.98511986

In fact in those tests the dtraced version is running marginally
faster. I'm putting that down to a happy code alignment or somesuch.

It's using the SME_PRBE_ENABLED tests that Sun tell me were added
specifically for Perl - so they're happy that we're using them and
they work :)

I could use a little advice about how dtrace should be detected by
Configure and handled at build time. I need to

* find the dtrace executable
* use it to filter a D script into a .h
* (on Solaris but not MS) filter a D script into a .o
* link against the generated .o

I assume that all the above should be conditional on -Dusedtrace and
that Apple and Sun will set that option when they build their vendor
versions. Is that sensible?

Is there a precedent for finding an executable? Anything else I should
be thinking about?

7 Jan 2008, at 23:35, Andy Armstrong wrote:
>Default to on if -Dusedevel is present and dtrace is found, and off
>otherwise?
>
Yup, that sounds reasonable. Although I don't actually know what the
nominal effect of usedevel is :)

course I do. Ignore me. And, for good measure, "d'uh".

7 Jan 2008, at 23:42, H.Merijn Brand wrote:
If you get something that works this week, I'll put it in.
K, thanks - I'll give you a shout if I do - but don't hang on for me.

7 Jan 2008, at 23:30, Nicholas Clark wrote:
Good point.

Default to on if -Dusedevel is present and dtrace is found, and off
otherwise?

Yup, that sounds reasonable. Although I don't actually know what the
nominal effect of usedevel is :)

>That's the other thing that attracted me to an explicit switch. Isn't
>asking for dtrace support and having the build fail because it's not
>available better than hoping for dtrace support and having it omitted
>because we couldn't find the executable?
>
Is it viable to probe for a working dtrace? Do we know what is
sufficient
to make a test case that the broken ones reliably choke on?

Not yet. That's pretty much my next move.

[Clearly get it in manually first, then worry about this. Plus
Merijn is busy
with back porting currently so large Configure patches aren't a
great idea
right now]

Yeah, I thought that. I'll probably hang fire on attempting to get it
into Configure until he's finished that work.

7 Jan 2008, at 23:15, Nicholas Clark wrote:
>I assume that all the above should be conditional on -Dusedtrace and
>that Apple and Sun will set that option when they build their vendor
>versions. Is that sensible?
>
No! :-)

in that if it's the same speed, I don't see why we don't
default to
building it in on any platform where we can, and let the user have
to do
-Uusedtrace if they don't want it.

I guess I'm worried about introducing fragility into the build. There
seem to be a few different versions of dtrace floating around - some
of which are broken. There's at least one extant Sun version that
can't do the .d -.h transformation for example.

My thinking is that if it's on by default then broken dtrace implies
broken Perl.

>Is there a precedent for finding an executable? Anything else I
>should
>be thinking about?
>
I can't spot anything in generic Configure that is searching for
executables.
But I would assume that if it's in PATH, it's there. Else the user
needs to
re-run with a better PATH set up.

That's the other thing that attracted me to an explicit switch. Isn't
asking for dtrace support and having the build fail because it's not
available better than hoping for dtrace support and having it omitted
because we couldn't find the executable?

8 Jan 2008, at 14:22, Andy Dougherty wrote:
To find an executable from within Configure, you can use the UU/loc
utility shell script put there by Configure. The syntax is

[snip]

Thanks Andy - that's going to be a big help. The "did we get the right
dtrace" problem is a slight concern. We could run it and see what it
does - but what if dtrace is a script that someone's created to delete
a bunch of files (for example). Hmm.

Also, would you want just a shell variable (probably $dtrace
containing
the full path to the dtrace executable) or do you also want a C-level
#define?

I only need the dtrace executable at build time so just a shell var is
fine, thanks.

I can probably whip up a skeletal metaconfig unit and simple Configure
patch that won't interfere with Merijn's current metaconfig merge
work,
but I don't have dtrace, so I'd need a lot of help filling in the
gaps.

Thanks for the offer. I may come back to you on that. Right now I'd
like to do a little more research to see if I can come up with a safe
way of testing that we have the right dtrace.

Tue, Jan 08, 2008 at 02:27:58PM +0000, Andy Armstrong wrote:

Thanks Andy - that's going to be a big help. The "did we get the right
dtrace" problem is a slight concern. We could run it and see what it
does - but what if dtrace is a script that someone's created to delete
a bunch of files (for example). Hmm.

You have the same problem if someone has written a script called cc or
ld or

But how about something like -Dusedtrace=/path/to/dtrace if the user
wants to specify it, but have it default to the known location of dtrace
as installed by their S vendor otherwise?

9 Jan 2008, at 13:42, Andy Armstrong wrote:
I'm now getting a lot of help from the Sun people including a shell
account on a Solaris box to test against. They've said I can have
access to pretty much any dtrace enabled Solaris I need.

Actually the shell account came from Bryan Allen at pobox.com.

9 Jan 2008, at 13:22, Andy Dougherty wrote:
Anyway, there's also apparently the issue that not all 'dtrace's are
equivalent. I don't know if there are "new" and "old" versions, but
there
are apparently at least two flavors.

In short, if possible, actually testing whether 'dtrace' works before
using it makes sense, if that testing can be done without too much
pain.

I'm now getting a lot of help from the Sun people including a shell
account on a Solaris box to test against. They've said I can have
access to pretty much any dtrace enabled Solaris I need.

So I'm hopeful that with their help I can navigate the minefield of
dtrace versions.

As far as I can see the dtrace executable is always called /usr/sbin/
dtrace. Certainly that's the standard location on both Solaris and Mac
S. If FreeBSD ends up with it somewhere else we can probably just
hard wire that too. I think I'd rather go with a hard wired location
and have it fail safely than just poke around looking for any dtrace
on the path and risk collateral damage.

>But how about something like -Dusedtrace=/path/to/dtrace if the user
>wants to specify it, but have it default to the known location of
>dtrace
>as installed by their S vendor otherwise?
>
Yes, something like that is what I had in mind. (I'll, of course,
need to
find out what those "known locations" are, but that's a detail to be
filled in later.) The ability to override with a command line
option is a
general feature of nearly all Configure variables, so that comes
along for
free.

Yup, good plan. So I think /usr/sbin/dtrace -or- whatever the user
specifies is the way forward right now.

My idea is this: First, honor a command line. Next, look in known
locations for the particular operating system. Finally, look in
$PATH.

I'd skip PATH on the basis of the understanding I have right now.