Hello,
I'm setting up a new server on 5.4 and noticed this in the perl.spec file:
* Mon Jul 21 2008 Stepan Kasal - 4:5.8.8-14.el5 - add two patches, which... - Resolves: #435505, #431041 - remove %%define threading, the non-threading variant is not supported, Related: 435376
That comment wasn't there when I set up a server on 5.2 a few months back and the %define threading option was still in the perl.spec file, making it easy for me to create my own non-threaded perl.
I want a non-threaded perl because the mod_perl folks say that the performance is better on a non-threaded perl.
I believe I can compare the spec files and figure out where to edit the new spec file, but I wondered about that "not supported" comment.
Is there something "bad" about the non-threading variant?
Thanks!
Take care,
Kurt Hansen khansen@charityweb.net
At Mon, 30 Nov 2009 16:16:43 -0500 CentOS mailing list centos@centos.org wrote:
Hello,
I'm setting up a new server on 5.4 and noticed this in the perl.spec file:
- Mon Jul 21 2008 Stepan Kasal - 4:5.8.8-14.el5
- add two patches, which...
- Resolves: #435505, #431041
- remove %%define threading, the non-threading variant is not supported, Related: 435376
That comment wasn't there when I set up a server on 5.2 a few months back and the %define threading option was still in the perl.spec file, making it easy for me to create my own non-threaded perl.
I want a non-threaded perl because the mod_perl folks say that the performance is better on a non-threaded perl.
I believe I can compare the spec files and figure out where to edit the new spec file, but I wondered about that "not supported" comment.
Is there something "bad" about the non-threading variant?
Probably the same thing that is bad about a single core processor. Which are pretty much no longer available (except for processors meant for little SBC/Embedded systems). I suspect that either RH or (more likely) the Perl people don't want to have to support two versions of Perl, one with and one without threading.
Thanks!
Take care,
Kurt Hansen khansen@charityweb.net _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
At Mon, 30 Nov 2009 16:16:43 -0500 CentOS mailing list centos@centos.org wrote:
<snip>
Is there something "bad" about the non-threading variant?
Probably the same thing that is bad about a single core processor. Which are pretty much no longer available (except for processors meant for little SBC/Embedded systems). I suspect that either RH or (more
I'll call you on that. A *lot* of people, both at home and in offices, are running single core systems, and will be for years. Most folks can't afford to upgrade every year or two... and since *most* folks are running office software, browsing the Web, and doing email, don't *need* to.
Besides, this *is* Linux we're talking about, which runs on *everything*, including 386's....
mark
At Mon, 30 Nov 2009 15:47:24 -0700 (MST) CentOS mailing list centos@centos.org wrote:
At Mon, 30 Nov 2009 16:16:43 -0500 CentOS mailing list centos@centos.org wrote:
<snip> >> Is there something "bad" about the non-threading variant? > > Probably the same thing that is bad about a single core processor. > Which are pretty much no longer available (except for processors meant > for little SBC/Embedded systems). I suspect that either RH or (more
I'll call you on that. A *lot* of people, both at home and in offices, are running single core systems, and will be for years. Most folks can't afford to upgrade every year or two... and since *most* folks are running office software, browsing the Web, and doing email, don't *need* to.
All I meant was it is hard to get a *new* single core processor. Yes, there are lots of *old* single core systems that will continue in service for years. I was going to get a single-core Semperon from Newegg for my new system, but before I could raise the money to get one, Newegg discontinued the only remaining AMD single core processor they carried (all of the Intel ones are multi-core). I did find one from a discount/closeout place with some in stock (and they had a counter showing how many were left in stock).
Besides, this *is* Linux we're talking about, which runs on *everything*, including 386's....
Sure, although most distros don't provide stock kernels for anything less than a '586.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Heller wrote:
Probably the same thing that is bad about a single core processor. Which are pretty much no longer available (except for processors meant for little SBC/Embedded systems). I suspect that either RH or (more likely) the Perl people don't want to have to support two versions of Perl, one with and one without threading.
Single core CPUs may be rare but single core VMs probably represent the dominant number of deployments out there as it's much more efficient scheduler wise to go with more single CPUs than fewer multi CPU VMs.
Not that I have any problem running multithreaded apps on a single CPU, I do it all the time. It is kind of unconventional using a load balancer to spread load specifically for optimal hypervisor scheduling though(traffic is load balanced regardless).
nate
Robert Heller wrote:
Probably the same thing that is bad about a single core processor. Which are pretty much no longer available (except for processors meant for little SBC/Embedded systems). I suspect that either RH or (more likely) the Perl people don't want to have to support two versions of Perl, one with and one without threading.
Single core CPUs may be rare but single core VMs probably represent the dominant number of deployments out there as it's much more efficient scheduler wise to go with more single CPUs than fewer multi CPU VMs.
<snip> Good point. In fact, where I was working earlier this year, they had several long phone calls with VMware's support, who advised them explicitly to allocate as few cores as possible, because one VM might wait a *lot* longer if it was looking for 4 or 8 cores, while other VMs were using several, whereas if it only wanted 2, or 1, it would get its time slice a lot sooner.
mark
Robert Heller wrote:
At Mon, 30 Nov 2009 16:16:43 -0500 CentOS mailing list centos@centos.org wrote:
Hello,
I'm setting up a new server on 5.4 and noticed this in the perl.spec file:
- Mon Jul 21 2008 Stepan Kasal - 4:5.8.8-14.el5
- add two patches, which...
- Resolves: #435505, #431041
- remove %%define threading, the non-threading variant is not supported, Related: 435376
That comment wasn't there when I set up a server on 5.2 a few months back and the %define threading option was still in the perl.spec file, making it easy for me to create my own non-threaded perl.
I want a non-threaded perl because the mod_perl folks say that the performance is better on a non-threaded perl.
I believe I can compare the spec files and figure out where to edit the new spec file, but I wondered about that "not supported" comment.
Is there something "bad" about the non-threading variant?
Probably the same thing that is bad about a single core processor. Which are pretty much no longer available (except for processors meant for little SBC/Embedded systems). I suspect that either RH or (more likely) the Perl people don't want to have to support two versions of Perl, one with and one without threading.
Actually, I'm pretty sure that this is a decision by RH alone. If anything, the "Perl people" advised against it. Everything I've read by perl developers is that threading is a performance hit in perl unless you've written your program specifically to take advantage of threading. Most perl programs don't, so it would be better for those who use perl the most if the default version were the non-threaded one. However, I realize that choosing the threaded version almost assuredly is preferred by a majority of RH users. It has been clear by choices RH has made over the years with respect to perl that heavy users of perl in Apache are not a core constituency of RH. Those of us who do use perl extensively on RH distributions have to adapt. I only wish RH made it easier.
I do know, though, that there is a set of perl modules, called bioperl, used extensively by folks analyzing the human genome. Plus, they even have a pretty large cluster at the National Institutes of Health running on CentOS. I wonder if a lot of those modules are optimized for threaded perl?
The program that I use the most, mod_perl, which is a persistent perl interpreter in Apache, was not written to take advantage of threading. The mod_perl developers report that you can get a 20-30% increase in performance by using a non-threaded perl vs a threaded one.
No-one's brought up any problems with the non-threaded one, so I think I'll go ahead with my own spec file and rebuilding perl.
Thank you!
Take care,
Kurt Hansen khansen@charityweb.net
-
Kurt Hansen -
m.roth＠5-cent.us -
nate -
Robert Heller