Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Sat, 31 Dec 2011 00:55:30 +0000 (UTC)
From: "Steven Rowe (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1511554630.54947.1325292930655.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1997056230.43669.1324700071782.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (LUCENE-3667) Consider changing how we set the
 number of threads to use to run tests.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177859#comment-13177859 ] 

Steven Rowe commented on LUCENE-3667:
-------------------------------------

Another anecdotal result, on a 4 core (8 "cores" w/ Hyperthreading) Intel Core i7-2600@3.4GHz, 8GB RAM, Windows 7:

{{time ant clean compile test }} on trunk @ r1225617:

{noformat}
BUILD SUCCESSFUL
Total time: 9 minutes 38 seconds

real    9m39.762s
user    0m0.091s
sys     0m0.090s
{noformat}

Same command after {{svn update}}'ing to r1225973:

{noformat}
BUILD SUCCESSFUL
Total time: 7 minutes 24 seconds

real    7m25.952s
user    0m0.060s
sys     0m0.138s
{noformat}
                
> Consider changing how we set the number of threads to use to run tests.
> -----------------------------------------------------------------------
>
>                 Key: LUCENE-3667
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3667
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Assignee: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-3667.patch, LUCENE-3667.patch, LUCENE-3667.patch, LUCENE-3667.patch, LUCENE-3667.patch
>
>
> The current way we set the number of threads to use is not expressive enough for some systems. My quad core with hyper threading is recognized as 8 CPUs - since I can only override the number of threads to use per core, 8 is as low as I can go. 8 threads can be problematic for me - just the amount of RAM used sometimes can toss me into heavy paging because I only have 8 GB of RAM - the heavy paging can cause my whole system to come to a crawl. Without hacking the build, I don't think I have a lot of workarounds.
> I'd like to propose that switch from using threadsPerProcessor to threadCount. In some ways, it's not as nice, because it does not try to scale automatically per system. But that auto scaling is often not ideal (hyper threading, wanting to be able to do other work at the same time), so perhaps we just default to 1 or 2 threads and devs can override individually?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org