Anzeige:
Ergebnis 1 bis 8 von 8

Thema: Java und 4-fach CPU

  1. #1
    Registrierter Benutzer Avatar von BlueJay
    Registriert seit
    27.08.2004
    Beiträge
    825

    Java und 4-fach CPU

    Hallo Leute,

    da ist so ein Java-(Kommandozeilen)-Programm, was einen "normalen" Rechner cpu-mäßig voll auslastet. (100%).
    Es sind hauptsächlich fette Schleifen mit logarithmischen Formeln( Simulation).

    Dieses wurde auf ein System mit 4 CPUs (Windows 7 mit frisch installierter JRE(64bit) von Sun) kopiert (jar-File).

    Die große Enttäuschung kam, als es nicht wesentlich schneller lief.
    Die CPUs teilten sich zwar brav die Arbeit, waren insgesamt nur zu 25% ausgelastet.

    Warum war das Programm nicht schneller? Wieso räkelten sich die CPUs in dem Rechner rum, obwohl genug Arbeit anlag?

    so long,
    BlueJay
    Eigentlich ganz einfach, wenn man's weiss!

  2. #2
    Registrierter Benutzer Avatar von mwanaheri
    Registriert seit
    28.10.2003
    Ort
    Bayreuth
    Beiträge
    569

    mögliche Ursachen

    Hmmm, da fällt mir spontan nur ein, dass die CPUs nicht schnell genug was zum Berechnen bekamen. Bremser könnten z.B. ein Datei-IO sein oder auch ein knapper genutzter Arbeitsspeicher.
    Das Ziel ist das Ziel.

  3. #3
    Registrierter Benutzer Avatar von John W
    Registriert seit
    29.01.2010
    Beiträge
    211
    Ich schätze mal, dass der Code sequenziell abläuft und nicht parallel, dann bringen dir auch 1000 Kerne nix.
    Praktisch muss ein Programm Threading-Funktionalität aufweisen, um mit mehr Cores auch schneller laufen zu können.

  4. #4
    Registrierter Benutzer Avatar von BlueJay
    Registriert seit
    27.08.2004
    Beiträge
    825
    Hallo,

    Tendenziell würde ich auch zu Johns Aussage neiden, aber :

    was ich so aus der Systemleistung gesehen habe:
    1-Core: Belastung 100% (glatte Linie), Speicher: 0.75GB

    4-Core: Belastung Core1: 10-bis 80%, Core2: bis 0-50%, Core3 und 4 maximal 20%, Mittelwert:25%, Speicher: 1.5GB

    d.h. Core 2 bekommt etwas zu tun ab.

    Das Programm selbst gibt alle 10 000 Berechnungen eine Statuszeile aus, ist recht flott, solange es nicht mit Logarithmen oder Trigonometrie hantieren muss.

    Gruß,
    Ulrike
    Geändert von BlueJay (28-01-2011 um 09:16 Uhr)
    Eigentlich ganz einfach, wenn man's weiss!

  5. #5
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Wenn das Programm nur einen Thread hat, kann es nicht gleichzeitig auf mehreren Cores ausgeführt werden. Ein Verteilungseffekt kann aber dennoch entstehen, weil u.U. Betriebsystem oder Hardware die Cores abwechselnd beschicken.

    Zum Beispiel alle X Cycles auf einen anderen Core verlagern, eventuell um die thermische Belastung gleichmäßiger zu verteilen.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  6. #6
    Registrierter Benutzer Avatar von BlueJay
    Registriert seit
    27.08.2004
    Beiträge
    825

    Threads und Ärger mit der Priority

    Hallo,

    ich stricke gerade das Kernstück, was wirklich nur aus 1 Thread, indem eine fette Doppel-Loop steht, besteht, auf Multi-Threads um. Erster Eindruck: sogar auf der 1-Core-Gurke geht es jetzt ab wie Schmitz' Katze, vorher:43s, nachher: 1s.

    Nachteil: Obwohl die Rechenthreads mit LOW_PRIORITY und das GUI mit HIGH_PRIORITY laufen, blockiert die Anwendung, bis die Berechnungen fertig sind.

    Hier mal der Code:

    GUI:
    Code:
     public juliapanel() 
     { 
       feddich=0;
        jul=new fracfunct();
        set_size(panelx,panely);
        refresh=new Thread(this);
        refresh.setPriority(Thread.MAX_PRIORITY);
        refresh.start();
      }
    
      public void run()
      { 
        while (refresh!=null)
        { repaint();
          if (tg.activeCount()==0) if (feddich==1) // tg ist eine ThreadGroup
          { feddich=2;
            manjulia.main.popup(""+(System.currentTimeMillis()-start)/1000+"s");
          }
          try { Thread.sleep(100); }   // 0.1s Sendepause
          catch (InterruptedException e) { break; }
        }
      }

    ... und hier der "Rechenknecht":
    Code:
    public void mach_bild()
      { 
        feddich=1;
        begrenzer=false;
        if (gb!=null) gb.dispose();
        gb=buffima.getGraphics();
        gb.setColor(Color.GRAY);
        gb.fillRect(0,0,sxmax,symax);
        start=System.currentTimeMillis();
     
        tg.setMaxPriority(Thread.MIN_PRIORITY); // sollte alle Threads in dieser Gruppe ausbremsen
        Thread[] th=new Thread[symax];
        for (int i=0; i<symax; i++)              // symax ist irgendwas von 400 bis 3000
        { final int ii=i;
          th[i]=new Thread(tg,"zeile")
                { 
                   @Override  public void run() { mach_zeile(ii); }
                };
          th[i].start();
        }
      }
    Ich bin nicht sooo fit in Threads, wo ist da mein Denkfehler?

    Gruß,
    Ulrike
    Eigentlich ganz einfach, wenn man's weiss!

  7. #7
    Registrierter Benutzer Avatar von John W
    Registriert seit
    29.01.2010
    Beiträge
    211
    Die grafische Oberfläche immer dispatchen: http://download.oracle.com/javase/tu...ncy/index.html
    Prioritäten sind meist unsinnig (will heißen: Hab ich nie gebraucht); theoretisch könntest du für jede Aufgabe, die unabhängig von den anderen ist, einen Thread erstellen.

  8. #8
    Registrierter Benutzer Avatar von BlueJay
    Registriert seit
    27.08.2004
    Beiträge
    825
    Hallo John,

    Menuleisten und der ganze Pipapo läuft natürlich im Event Dispatcher Thread ab, dieser Panel und der refresh-Thread ebenfalls, die tg-Gruppe hingegen nicht. (gecheckt mit SwingUtilities.isEventDispatchThread()).

    Vielleicht ist auch eine Priority von 10 zu gering gegenüber dem Ansturm von 400 bis 1000 Threads mit 1.

    Aber das Konzept mit der SwingWorker-Class scheint interessant zu sein.
    Da ist aber erstmal Lesen angesagt.

    Gruß,
    Ulrike
    Eigentlich ganz einfach, wenn man's weiss!

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •