Threading enabled performance impact

[Lord0]

Hi there,

I know that using a perl configured/compiled with threading enabled can
have performance implications, many of them negative. I have heard glib
statements like "Ya, running perl with threading enabled slows
performance by 10%-15%" etc. Does anybody have any metrics for this?
Basically we have an on going debate in work as to whether we should
recompile without thread support, which we aint using, in order to
improve performance.....

Cheers

Lord0

http://ltierney.demon.co.uk

 

[A. Sinan Unur]

I know that using a perl configured/compiled with threading enabled can
have performance implications, many of them negative. I have heard glib
statements like "Ya, running perl with threading enabled slows
performance by 10%-15%" etc. Does anybody have any metrics for this?
Basically we have an on going debate in work as to whether we should
recompile without thread support, which we aint using, in order to
improve performance.....

The answer to this question is extremenly dependent on hardware, OS, Perl
version etc etc.

Have you tried actually measuring the difference, if there is any?

Sinan

 

[Chris]

Hi there,

I know that using a perl configured/compiled with threading enabled can
have performance implications, many of them negative. I have heard glib
statements like "Ya, running perl with threading enabled slows
performance by 10%-15%" etc. Does anybody have any metrics for this?
Basically we have an on going debate in work as to whether we should
recompile without thread support, which we aint using, in order to
improve performance.....

Why can't you just test the code to see for yourself?

This sort of question is so system and task specific that
you won't get a useful answer until /you/ try it on /your/
system.

 

[Jeff Stampes]

I know that using a perl configured/compiled with threading enabled can
have performance implications, many of them negative. I have heard glib
statements like "Ya, running perl with threading enabled slows
performance by 10%-15%" etc. Does anybody have any metrics for this?
Basically we have an on going debate in work as to whether we should
recompile without thread support, which we aint using, in order to
improve performance.....

The advice others are giving you to "Go try it and see" is sound advice, but unlike the
givers of said advice, I'm aware (painfully aware) that doing so is a lot harder than it
sounds at times.

If the current version of perl you are using is located on a network server, then you need
the new version installe don the same server to make a meaningful comarison. If that
server is owned by your I.T. group, it's not as easy:

"Hey, can you recompile this for us? Without threading this time. And any modules
compiled with it, we need recompiled as well. No, don't remove the old one, we might want
to use it still. Yes, we might be asking you to do this all for naught. No, we have no
clue what the performance difference is. Yes, I asked, and the helpful folks an clpm told
me to go find out for myself. Yeah, I guess they aren't too helpful sometimes"

If you are NOT using threading, what are the things that consume extra cycles using a
threaded perl? Is everything 10-15% slower? Is it memory allocation? Forking? Spawning
processes?

"Try it yourself and tell us what happened" is dandy advice. But in a corporate
environment, sometimes you need to collect data *before* you can try something, because
you need cooperation from others to perform the experiment, and they need persuading, and
want to see some data.

OP asked for some data or metrics to help sell this idea at work. If you don't have data
or metrics to point him to, your contribution is respected. but probably not very helpful.

~Jeff

 

[Lord0]

Jeff you hit the nail on the head! You could have been describing my office.

Maybe my original question was poorly phrased: I am looking for "ammo" for
use as leverage, one way or another, in this, as yet without metrics
conversation I have been having with my co-workers r.e. perl compiled to use
threads. Thought somebody may have performed similar investigations.

Lord0

http://ltierney.demon.co.uk

 

[A. Sinan Unur]

....

If the current version of perl you are using is located on a network
server, then you need the new version installe don the same server to
make a meaningful comarison. If that server is owned by your I.T.
group, it's not as easy:

Don't you have an account on the server? Install your own copy of Perl.

"Hey, can you recompile this for us? Without threading this time.
And any modules compiled with it, we need recompiled as well. No,
don't remove the old one, we might want to use it still. Yes, we
might be asking you to do this all for naught. No, we have no clue
what the performance difference is. Yes, I asked, and the helpful
folks an clpm told me to go find out for myself. Yeah, I guess they
aren't too helpful sometimes"

That is simply a stupid statement: Admitting our uncertainty over
whatever performance difference might exist between the two versions is
*very* helpful. If it will make you happier, here:

"Compile Perl without threading support to get at least a 25% performance
gain".

Are you happier now? Despite the fact that you know there is absolutely
no factual basis behind that claim?

If you are NOT using threading, what are the things that consume extra
cycles using a threaded perl? Is everything 10-15% slower?

The only performance difference claim was made by the OP. The rest of us
admit we have no idea if there is an appreciable difference in
performance without actually measuring it.

"Try it yourself and tell us what happened" is dandy advice. But in a
corporate environment, sometimes you need to collect data *before* you
can try something, because you need cooperation from others to perform
the experiment, and they need persuading, and want to see some data.

And we recommended the OP to collect some data. You might want to
understand the difference between data and word-of-mouth.

OP asked for some data or metrics to help sell this idea at work.

The data and metrics depend on the OP's environment, and the application.
The OP should collect data and metrics. We just pointed this out to them.

If you don't have data or metrics to point him to, your contribution
is respected. but probably not very helpful.

*PLONK*.

Sinan

PS: I find the OP to be misguided. He would probably gain more
performance by actually looking at his code and system as a whole than
looking for a magic bullet.

 

[A. Sinan Unur]

Jeff you hit the nail on the head! You could have been describing my
office.

Maybe my original question was poorly phrased: I am looking for "ammo"
for use as leverage, one way or another, in this, as yet without
metrics conversation I have been having with my co-workers r.e. perl
compiled to use threads. Thought somebody may have performed similar
investigations.

I don't understand why you imagine that you'll be able to find a single
performance difference number that is applicable to all environments, and
all versions of Perl.

And, if you are in such a dysfunctional environment that you cannot install
another copy of Perl to test things, I am not sure what you expect us to be
able to do to figure out any differences.

If my programs were not fast enough, I would first look at my programs to
figure out what I could do improve them. That is where the biggest bang per
buck lies in terms of potential performance improvement.

And, if I were really curious, I would build Perl without thread support,
and see what happened.

Sinan

 

[xhoster]

The advice others are giving you to "Go try it and see" is sound advice,
but unlike the givers of said advice, I'm aware (painfully aware) that
doing so is a lot harder than it sounds at times.

Just making shit up is always easy. Is that what we should, because it is
easy?

If the current version of perl you are using is located on a network
server, then you need the new version installe don the same server to
make a meaningful comarison. If that server is owned by your I.T. group,
it's not as easy:

"Hey, can you recompile this for us? Without threading this time. And
any modules compiled with it, we need recompiled as well. No, don't
remove the old one, we might want to use it still. Yes, we might be
asking you to do this all for naught. No, we have no clue what the
performance difference is. Yes, I asked, and the helpful folks an clpm
told me to go find out for myself. Yeah, I guess they aren't too helpful
sometimes"

Compare that to "Can you recompile perl and all of the modules, but leave
the old there in case we need it, because some guy on the internet said
it would 13.985% faster."

If you are NOT using threading, what are the things that consume extra
cycles using a threaded perl? Is everything 10-15% slower? Is it memory
allocation? Forking? Spawning processes?

"Try it yourself and tell us what happened" is dandy advice. But in a
corporate environment, sometimes you need to collect data *before* you
can try something, because you need cooperation from others to perform
the experiment, and they need persuading, and want to see some data.

"Some guy on the internet says so" is not data. If the corporation has
such high standards, they should be willing to pay to get those standards
met.

OP asked for some data or metrics to help sell this idea at work. If you
don't have data or metrics to point him to, your contribution is
respected. but probably not very helpful.

Don't trust metrics other than the ones you obtain yourself on your actual
program on your actual verion of Perl on your actual hardware. That is the
most helpful answer.

Xho

 

[Jeff Stampes]

Jeff you hit the nail on the head! You could have been describing my office.

Maybe my original question was poorly phrased: I am looking for "ammo" for
use as leverage, one way or another, in this, as yet without metrics
conversation I have been having with my co-workers r.e. perl compiled to use
threads. Thought somebody may have performed similar investigations.

And if you found some people had, and the data showed it was generally worth an investment
of time, and there was a realistic chance of performance improvement, it's worth trying.

It's called Return on Investment research. It must be nice to exist in a world where you
don't need to justify an effort to expend corporate resources, and where they'll just do
any old thing for you just because you ask, regardless of your ability to forcast the
probability of success, but you & I don't live there, eh?

I considered earlier this year if I should ask our IT department to recompile *with*
threads, so I could begin redesigning portions of our codebase to use threading instead of
forking. I was unable to find the type of research results you're looking for, so I wish
you luck, and would request an update if you do make the switch.

Cheers,
~Jeff

 

[Jeff Stampes]

Don't you have an account on the server? Install your own copy of Perl.

Believe it or not, we don't all get to write data any place we want. Many places have
restrictions on installing *any* software without I.T. involvement. Something like perl
would seem perfectly benign, but it is very possible to risk running afoul of corporate
policy .

And to do things that spend corporate resouces (even if those resources were restricted to
disk space and CPU cylces), often requires a ROI analysis. Attempting to gather the data
to provide that analysis is a part of our jobs at times.

That is simply a stupid statement: Admitting our uncertainty over
whatever performance difference might exist between the two versions is
*very* helpful. If it will make you happier, here:

The OP didn't ask you if you were uncertain. He asked if anyone did have data. You don't
have any idea. So what? So you know for a fact that nobody knows? You know for an
absolute fact that there's no research out there anywhere that says what happened to
certain code/machine/os architectures that could provide datapoints for someone trying to
justify a decision?

Please send me a description of the education you have received. I must pursue the same
path as well so that I too, can be omniscient

"Compile Perl without threading support to get at least a 25% performance
gain".

Are you happier now? Despite the fact that you know there is absolutely
no factual basis behind that claim?

Of course not. If you answer that way, the response should be: "How do you know? Do
you have some data to show that?"

One of the joys of using the Internet as a research tool: Not only will you get data to
learn from, you get everyone's opinion, whether you ask for it or not.

The only performance difference claim was made by the OP. The rest of us
admit we have no idea if there is an appreciable difference in
performance without actually measuring it.

Speak for yourself Tonto. Maybe I know. Maybe I've done it on 15 different combinations
of OS and Hardware. Maybe I've run the whole perl test suite on threaded and unthreaded
for all of them, and presented the results to our CIO as justification for recompiling
perl in a mission critical, high volume environment. If I had, wouldn't the OP have
gained valuable information as a result of my sharing of data with him? Why should he
repeat my labors?

If every single result showed an increase in performance, would the he know something he
doesn't know now? Conversely, if every result showed a decrease in performance, would he
have a better idea of the odds of increasing performance? If one of the OS/Architecture
combos was the same as his?

And we recommended the OP to collect some data. You might want to
understand the difference between data and word-of-mouth.

I certainly do. When the OP asked for data, I didn't give him my word of mouth.

The data and metrics depend on the OP's environment, and the application.
The OP should collect data and metrics. We just pointed this out to them.

The OP was doing just that as far as I can tell. I fail to grasp the need to reply to
someone's *request for data* with a reply containing no data. Noise up, signal down.

*PLONK*.

LOL. It's awfully crowded in here. How many dial layer DVDs does it take to back up the
killfile these days?

I've grateful that I don't have to go through life believing I'm always right, and that I
listen to those whose life experience, being different than mine, may teach me something.

Sinan

PS: I find the OP to be misguided. He would probably gain more
performance by actually looking at his code and system as a whole than
looking for a magic bullet.

You have no idea of the OP's circumstances, nor what his objectives or instructions are.
Your ability to be omniscient, and psychic to boot, will never cease to amaze me.

Cheers,
~Jeff

 

[Jeff Stampes]

Just making shit up is always easy. Is that what we should, because it is
easy?

Who asked you to? I didn't see that. Of course you shouldn't. (You also should't coat
yourself in honey before entering the bear cage. Nobody asked, but while we're inventing
questions, I wanted to pre-empt that one)

Compare that to "Can you recompile perl and all of the modules, but leave
the old there in case we need it, because some guy on the internet said
it would 13.985% faster."

Compare that to "Here's the benchmarks from other people who have recompiled. Take note
of these 5, which are the same OS and architectures, in similar network environments. Is
this enough data for you make a decision for our next step?"

"Some guy on the internet says so" is not data. If the corporation has
such high standards, they should be willing to pay to get those standards
met.

So if I understand you, if you have high standards, you shouldn't ever consult anyone
else's research? A few PhD professors and I had a good chuckle over that.

Don't trust metrics other than the ones you obtain yourself on your actual
program on your actual verion of Perl on your actual hardware. That is the
most helpful answer.

And don't use anyone else's metrics as a basis for deciding what the potential "R" in ROI
is?

~Jeff

 

[xhoster]

A. Sinan Unur wrote:

Believe it or not, we don't all get to write data any place we want.
Many places have restrictions on installing *any* software without I.T.

I would think that, if you are trying to microoptimize the performance of
your companies Perl scripts, then you would *be* I.T. So of course you
wouldn't be doing it without I.T.

involvement. Something like perl would seem perfectly benign, but it is
very possible to risk running afoul of corporate policy .

And to do things that spend corporate resouces (even if those resources
were restricted to disk space and CPU cylces), often requires a ROI
analysis.

Right. And that is what we are recommending--go do the ROI analysis.

Attempting to gather the data to provide that analysis is a
part of our jobs at times.

Exactly. Go gather it.

Xho