如何确保Java线程在不同的核心上运行 [英] How to ensure Java threads run on different cores

查看:201
本文介绍了如何确保Java线程在不同的核心上运行的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在用Java编写一个多线程应用程序,以提高顺序版本的性能。它是0/1背包问题的动态编程解决方案的并行版本。我有一个Intel Core 2 Duo,在不同的分区上同时使用Ubuntu和Windows 7 Professional。我在Ubuntu中运行。

I am writing a multi-threaded application in Java in order to improve performance over the sequential version. It is a parallel version of the dynamic programming solution to the 0/1 knapsack problem. I have an Intel Core 2 Duo with both Ubuntu and Windows 7 Professional on different partitions. I am running in Ubuntu.

我的问题是并行版本实际上需要比顺序版本更长的时间。我想这可能是因为线程都被映射到同一个内核线程或者它们被分配到同一个内核。有没有办法可以确保每个Java线程映射到一个单独的核心?

My problem is that the parallel version actually takes longer than the sequential version. I am thinking this may be because the threads are all being mapped to the same kernel thread or that they are being allocated to the same core. Is there a way I could ensure that each Java thread maps to a separate core?

我已经阅读了有关此问题的其他帖子,但似乎没有任何帮助。

I have read other posts about this problem but nothing seems to help.

这是KnapsackThread类(扩展Thread)的main()和run()的结束。请注意,我使用slice和extra来计算myLowBound,myHiBound确保每个线程不会在dynProgMatrix的域中重叠。因此没有竞争条件。

Here is the end of main() and all of run() for the KnapsackThread class (which extends Thread). Notice that they way I use slice and extra to calculate myLowBound and myHiBound ensure that each thread will not overlap in domain of the dynProgMatrix. Therefore there will be no race conditions.

    dynProgMatrix = new int[totalItems+1][capacity+1];
    for (int w = 0; w<= capacity; w++)
        dynProgMatrix[0][w] = 0;
    for(int i=0; i<=totalItems; i++)
        dynProgMatrix[i][0] = 0;
    slice = Math.max(1,
            (int) Math.floor((double)(dynProgMatrix[0].length)/threads.length));
    extra = (dynProgMatrix[0].length) % threads.length;

    barrier = new CyclicBarrier(threads.length);
    for (int i = 0; i <  threads.length; i++){
        threads[i] = new KnapsackThread(Integer.toString(i));
    }
    for (int i = 0; i < threads.length; i++){
        threads[i].start();
    }

    for (int i = 0; i < threads.length; i++){
        try {
            threads[i].join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

public void run(){
    int myRank = Integer.parseInt(this.getName());

    int myLowBound;
    int myHiBound;

    if (myRank < extra){
        myLowBound = myRank * (slice + 1);
        myHiBound = myLowBound + slice;
    }
    else{
        myLowBound = myRank * slice + extra;
        myHiBound = myLowBound + slice - 1;
    }

    if(myHiBound > capacity){
        myHiBound = capacity;
    }

    for(int i = 1; i <= totalItems; i++){
        for (int w = myLowBound; w <= myHiBound; w++){

            if (allItems[i].weight <= w){
               if (allItems[i].profit + dynProgMatrix[i-1][w-allItems[i].weight]
                        > dynProgMatrix[i-1][w])
                {
                    dynProgMatrix[i][w] = allItems[i].profit +
                                      dynProgMatrix[i-1][w- allItems[i].weight];
                }
                else{
                    dynProgMatrix[i][w] = dynProgMatrix[i-1][w];
                }
            }
            else{
                dynProgMatrix[i][w] = dynProgMatrix[i-1][w];
            }
        }
        // now place a barrier to sync up the threads
        try {
            barrier.await(); 
        } catch (InterruptedException ex) { 
            ex.printStackTrace();
            return;
        } catch (BrokenBarrierException ex) { 
            ex.printStackTrace(); 
            return;
        }
    }
}



更新:



我写了另一个使用蛮力的背包版本。这个版本的同步很少,因为我只需要在单个线程的执行结束时更新bestSoFar变量。因此,除了最后那个小的关键部分之外,每个线程几乎应该完全并行执行。

Update:

I have written another version of the knapsack that uses brute force. This version has very little synchronization because I only need to update a bestSoFar variable at the end of a single thread's execution. Therefore, each thread pretty much should execute completely in parallel except for that small critical section at the end.

我运行这个与顺序蛮力并且仍然需要更长时间。我没有看到任何其他解释,因为我的线程正在顺序运行,因为它们被映射到相同的核心或相同的本机线程。

I ran this versus the sequential brute force and still it takes longer. I don't see any other explanation than that my threads are being run sequentially, either because they are being mapped to the same core or to the same native thread.

任何人都有任何洞察力?

Does anybody have any insight?

推荐答案

我怀疑这是因为所有线程使用相同的核心。调度由操作系统决定,但如果您启动操作系统的性能管理器,您应该能够看到正在发生的事情 - 它通常会显示每个内核的繁忙程度。

I doubt that it will be due to using the same core for all threads. The scheduling is up to the OS, but you should be able to see what's going on if you bring up the performance manager for the OS - it will typically show how busy each core is.

花费更长时间的可能原因:

Possible reasons for it taking longer:


  • 大量同步(必要或不必要)

  • 任务花费这么短的时间,线程创建占用了很大一部分时间

  • 上下文切换,如果你创建了太多的线程 - 用于CPU密集型任务,创建与你拥有核心的线程一样多。

这篇关于如何确保Java线程在不同的核心上运行的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆