About analysis speed

[hope366]

Using katago_20211025_trt64.exe used in lizzieyzy, one is normal lizzie and the other is lizzieyzy2.4.5, the situation when the same phase diagram is analyzed is shown in the screenshot below.
Both threads used are numSearchThreads = 16.
Both analysis widths are analysisWideRootNoise = 0.04.
The GPU is RTX 2060.
In terms of analysis speed, regular lizzie is about 1.5 times faster than lizzieyzy. It seems that the difference is always maintained at this level. Also, although the blue points and the displayed candidate moves are similar, there are some differences. What is the reason for these differences?

[yzyray]

Lizzieyzy calculate speed by total increased visits(include invisible but exclude symmetric candidates) in 4 seconds divided by 4.
Official lizzie calculate speed by total increased visits(include only visible candidates if i record correctly) in 1 seconds divided by 1.
So I'm confused too....why it is always 1.5x difference.Can you try benchmark by katago benchmark in command line?

[yzyray]

There is one thing could make speed different,lizzieyzyz can override numSearchThreads parameter by 'Params' button in toolbars,if this option is checked.

[hope366]

Microsoft Windows [Version 10.0.19043.1288]
(c) Microsoft Corporation. All rights reserved.

C:\Users\hiro7>cd C:\Users\hiro7\Downloads\igo\Lizzie-6.5-40b-trt\katago-v1.10.0->trt8.2-cuda11.2-windows-x64

C:\Users\hiro7\Downloads\igo\Lizzie-6.5-40b-trt\katago-v1.10.0-trt8.2-cuda11.2-windows-x64>katago benchmark -model kata1-s1015.gz
2021-10-29 15:15:19+0900: Loading model and initializing benchmark...
2021-10-29 15:15:19+0900: Testing with default positions for board size: 19
2021-10-29 15:15:19+0900: nnRandSeed0 = 12971964846668986618
2021-10-29 15:15:19+0900: After dedups: nnModelFile0 = kata1-s1015.gz useFP16 auto useNHWC auto
2021-10-29 15:15:19+0900: Initializing neural net buffer to be size 19 * 19 exactly
2021-10-29 15:15:21+0900: TensorRT backend thread 0: Found GPU NVIDIA GeForce RTX 2060 memory 6442123264 compute capability major 7 minor 5
2021-10-29 15:15:21+0900: TensorRT backend thread 0: Initializing (may take a long time)
Could not open file C:\Users\hiro7\Downloads\igo\Lizzie-6.5-40b-trt\katago-v1.10.0-trt8.2-cuda11.2-windows-x64/KataGoData/trtcache/kata1-b40c256-s10150379520-d2474366098_gpu_75_19x19-exact_batch32_fp16 - does not exist or invalid permissions?: start to generate file
2021-10-29 15:17:45+0900: TensorRT backend thread 0: Model version 10 useFP16 = true
2021-10-29 15:17:45+0900: TensorRT backend thread 0: Model name: kata1-b40c256-s10150379520-d2474366098

2021-10-29 15:17:45+0900: Loaded config C:\Users\hiro7\Downloads\igo\Lizzie-6.5-40b-trt\katago-v1.10.0-trt8.2-cuda11.2-windows-x64/default_gtp.cfg
2021-10-29 15:17:45+0900: Loaded model kata1-s1015.gz

Testing using 800 visits.
If you have a good GPU, you might increase this using "-visits N" to get more >accurate results.
If you have a weak GPU and this is taking forever, you can decrease it instead to >finish the benchmark faster.

Your GTP config is currently set to trtUseFP16 = auto

Your GTP config is currently set to use numSearchThreads = 16
Automatically trying different numbers of threads to home in on the best (board size 19x19):

2021-10-29 15:17:45+0900: GPU -1 finishing, processed 5 rows 5 batches
2021-10-29 15:17:46+0900: nnRandSeed0 = 1315600918807091433
2021-10-29 15:17:46+0900: After dedups: nnModelFile0 = kata1-s1015.gz useFP16 auto useNHWC auto
2021-10-29 15:17:46+0900: Initializing neural net buffer to be size 19 * 19 exactly
2021-10-29 15:17:47+0900: TensorRT backend thread 0: Found GPU NVIDIA GeForce RTX 2060 memory 6442123264 compute capability major 7 minor 5
2021-10-29 15:17:47+0900: TensorRT backend thread 0: Initializing (may take a long time)
2021-10-29 15:17:48+0900: TensorRT backend thread 0: Model version 10 useFP16 = true
2021-10-29 15:17:48+0900: TensorRT backend thread 0: Model name: kata1-b40c256-s10150379520-d2474366098

Possible numbers of threads to test: 1, 2, 3, 4, 5, 6, 8, 10, 12, 16, 20, 24, 32,

numSearchThreads = 5: 10 / 10 positions, visits/s = 341.89 nnEvals/s = 292.31 nnBatches/s = 117.45 avgBatchSize = 2.49 (23.5 secs)
numSearchThreads = 12: 10 / 10 positions, visits/s = 673.08 nnEvals/s = 583.87 nnBatches/s = 98.35 avgBatchSize = 5.94 (12.0 secs)
numSearchThreads = 10: 10 / 10 positions, visits/s = 587.85 nnEvals/s = 494.84 nnBatches/s = 99.99 avgBatchSize = 4.95 (13.8 secs)
numSearchThreads = 20: 10 / 10 positions, visits/s = 790.69 nnEvals/s = 695.79 nnBatches/s = 68.55 avgBatchSize = 10.15 (10.4 secs)
numSearchThreads = 16: 10 / 10 positions, visits/s = 779.53 nnEvals/s = 691.54 nnBatches/s = 86.56 avgBatchSize = 7.99 (10.5 secs)
numSearchThreads = 24: 10 / 10 positions, visits/s = 820.37 nnEvals/s = 738.94 nnBatches/s = 53.83 avgBatchSize = 13.73 (10.0 secs)

Ordered summary of results:

numSearchThreads = 5: 10 / 10 positions, visits/s = 341.89 nnEvals/s = 292.31 nnBatches/s = 117.45 avgBatchSize = 2.49 (23.5 secs) (EloDiff baseline)
numSearchThreads = 10: 10 / 10 positions, visits/s = 587.85 nnEvals/s = 494.84 nnBatches/s = 99.99 avgBatchSize = 4.95 (13.8 secs) (EloDiff +185)
numSearchThreads = 12: 10 / 10 positions, visits/s = 673.08 nnEvals/s = 583.87 nnBatches/s = 98.35 avgBatchSize = 5.94 (12.0 secs) (EloDiff +231)
numSearchThreads = 16: 10 / 10 positions, visits/s = 779.53 nnEvals/s = 691.54 nnBatches/s = 86.56 avgBatchSize = 7.99 (10.5 secs) (EloDiff +276)
numSearchThreads = 20: 10 / 10 positions, visits/s = 790.69 nnEvals/s = 695.79 nnBatches/s = 68.55 avgBatchSize = 10.15 (10.4 secs) (EloDiff +271)
numSearchThreads = 24: 10 / 10 positions, visits/s = 820.37 nnEvals/s = 738.94 nnBatches/s = 53.83 avgBatchSize = 13.73 (10.0 secs) (EloDiff +275)

Based on some test data, each speed doubling gains perhaps ~250 Elo by searching deeper.
Based on some test data, each thread costs perhaps 7 Elo if using 800 visits, and 2 Elo if using 5000 visits (by making MCTS worse).
So APPROXIMATELY based on this benchmark, if you intend to do a 5 second search:
numSearchThreads = 5: (baseline)
numSearchThreads = 10: +185 Elo
numSearchThreads = 12: +231 Elo
numSearchThreads = 16: +276 Elo (recommended)
numSearchThreads = 20: +271 Elo
numSearchThreads = 24: +275 Elo

From the benchmark test results I am using 16 threads. In the benchmark test, it is 779 visits/s with 16 threads, which is almost the same as that of the normal lizzie in the image attached above.
It is unclear why lizzieyzy changes around 500 visits/s.

There is one thing could make speed different,lizzieyzyz can override numSearchThreads parameter by 'Params' button in toolbars,if this option is checked.

Thank you. Like PDA and WRN, it can be changed with one touch, so I think it is a very convenient function.

[yzyray]

Can you try to set numSearchThread to 16 in lizzieyzy frame by params button,see if it changes speed.

[hope366]

Yes, I tried it.
The speed seems to be changing around 550 visits / s.
It seems that there is almost no change from before.

[yzyray]

Are you using the same java environment for both lizzie and lizzieyzy?It should be same if using jar version lizzieyzy.
How is the GPU load when using lizzieyzy,you can see it from GPU-Z or simply 'nvidia-smi' in command

[hope366]

Using GPU-Z, we checked how the GPU is loaded when using each lizzie. There was a clear difference in the values, so I'll do some research to see if there might be a difference in the GPU field in config.txt.

As for java, I verified this by removing the jre folder from lizzieyzy, but I didn't see any change.
I have java(TM) SE Development Kit 14.0.1 (64-bit) installed on my PC, so I assume this works when using either lizzie.

[yzyray]

The gpu clock seems very different...this must be the reason.
If you are using exe version lizzieyzy,try to use 'lizzie-yzy2.4.5-shaded-win64.jar' instead.
When I generate the exe file,it has an option of process priority,maybe it has some side efffects.

[yzyray]

Or maybe my maven or compile java version is too old,I can update and package a new jar about tomorrow.

[hope366]

I've tested with jar files, and I've tried with exe files, but lizzieyzy still seems to be slow.

I have looked at the config.txt file and it appears to be the same for the GPU part. I have done previous experiments by moving only the katago executable, but I tried a new experiment by moving the entire katago folder used by the regular lizzie to lizzieyzy. However, there was almost no change in the analysis speed, and it seems that the config.txt file is not the cause.

Or maybe my maven or compile java version is too old,I can update and package a new jar about tomorrow.

Thank you very much for your prompt action.

[yzyray]

I've updated maven and jdk,complied 4 jars.
-jdk1.8 means complied with jdk1.8
-jdk11 means complied with jdk11
-modify means a little code modify maybe effect sub process.
lizzie-yzy2.4.5-shaded-jdk1.8.zip
lizzie-yzy2.4.5-shaded-jdk11.zip
lizzie-yzy2.4.5-shaded-jdk1.8-modify.zip
lizzie-yzy2.4.5-shaded-jdk11-modify.zip

[hope366]

I have tried all four types of jar files and they look almost the same as existing jar files in terms of analysis speed.
I have noticed one thing. When lizzieyzy uses the pondering on state for about 10 seconds, the number of GPU clocks decreases from 1800MHz to 1200HZz. Pondaling is the same for 10 seconds in a row or intermittently for a total of 10 seconds. In short, the load on the GPU will automatically decrease after about 10 seconds have passed since the GPU is heavily loaded. The analysis speed will decrease accordingly.
This is a feature common to all five jar files, including existing jar files.
With normal lizzie (an improved version of lizzie that I usually use https://github.com/hope366/Lizzie-improvements/releases/tag/v3.0), the high load condition of 1800MHz continues forever.

[yzyray]

Which version of maven and jdk do you use to generate jar files for https://github.com/hope366/Lizzie-improvements/releases/tag/v3.0

[hope366]

maven is "apache-maven-3.6.3-bin".
For java, "jdk-14.0.1" and "jre1.8_271" exist in the Program Files folder.
Looking at the program list in the control panel, it looks like the following regarding java. maven is not in the program list.

[yzyray]

try this,I packaged your code https://github.com/hope366/Lizzie-improvements
hope it also has the issue....then it's my environment problem...
lizzie-0.7.3-shaded.zip

[hope366]

I tried lizzie-0.7.3-shaded.zip.
The high load condition continues at all times in any situation.

[yzyray]

Really confused,just try to reset all code about start engine process to same with official lizzie....hope it works
test1.zip

[hope366]

I tried test1.zip, but as before, the GPU clock suddenly dropped after a heavy load of about 10 seconds ...
I asked people other than me to try this phenomenon, but it seems to be almost the same.
By the way, does your environment always have a high load on the GPU?

[yzyray]

My GPU clock with offical lizzie or your lizzie or lizzieyzy is almost the same....around 1050Mhz...but my gpu is only MX250...always use remote engine.2080 on ubuntu,doest have any issue but it is runing under ssh connection so I think it does not helps.

[yzyray]

Do you have any computer with 3060 laotop GPU,I have one but never run katago or lizzie,can try it tommorrow.

[hope366]

I only have one machine with a 2060, so I'm reaching out to more people to verify this issue.

[yzyray]

I'm also tring to get some lizzieyzy users to try official lizzie.

[yzyray]

I've asked 4 lizzieyzy users,with 2060,2060s,2080,3060.None of them have occured gpu clock dropped after few seconds.
I can hardly find out the probem now,so I want to try simply start katago engine process with out getting any input/output.
test2 will start a engine process with out get any output stream,due to no output need manually press space after you think engine is loaded.
test3 will start a engine process with out get any input/output stream,and bunlded with a tensorrt exe file can auto analyze after loaded.
test2.zip
test3.zip

[hope366]

In test2, when I start lizzieyzy, no candidate is displayed on the board, but if I hold down the space key, it puts a load on the GPU, and it seems that analysis work is being done internally. However, the number of GPU clocks was 1865MHz only for the first 10 seconds, then 1365MHz was maintained for about 10 seconds, and then there was no load. And I couldn't close lizzieyzy and ended up closing it from the task manager.

For test3 and katago_tensorRT.exe, the space key cannot be used to switch the analysis on and off, and the analysis is automatically continued. However, as for the analysis speed, it remains in a high load state for the first 10 seconds and after that, the load became low.

By the way, I also verified katago 1.9.1 opencl and leelazero 0.17. The result is exactly the same as katago1.10.0, with normal lizzie forever under heavy load, but with lizzieyzy only the first 10 seconds or so under heavy load.
I haven't collected the verification results of many people yet, so there may be a problem with my environment.

[yzyray]

I have recieved the same issue report several monthes ago once,that was a machine with four GPUs and only GPU one behave like yours,can not solve either.I thought it was multi GPUs issue.but now I think it should be some strange bug with lizzieyzy.
Can you check your katago's process priority,does it change when GPU clock dropped?

Or if you have any anti-virus software.
I have pushed a new branch 'process',cleaned up maven settings,it can be simply 'mvn package' without errors like official lizzie.Still with many warnings but it should be fine.

[hope366]

Katago's process priority remained "normal" both under heavy load and when the clock count dropped.
The antivirus software uses Avast.

[hope366]

Compiled lizzieyzy-process.
It seemed to fail with a lot of errors, but lizzie-0.7.4-shaded.jar was generated.
lizzie-0.7.4-shaded.jar will continue to be heavily loaded on the GPU. In other words, the problem so far has been solved. However, the GUI design is that of regular lizzie, not lizzieyzy.

[yzyray]

GUI should still looks like lizzieyzy,and file name is lizzie-yzy2.4.5-shaded,I have updated process branch again,more clean up with maven

[hope366]

There seems to be a problem with my compilation method.
As you say, it was compiled as a GUI for lizzieyzy. There were no errors at compile time.
However, using the generated lizzie-yzy2.4.5-shaded.jar still does not solve the problem of falling into a low load state after a high load state of about 10 seconds.

[yzyray]

OK,then the reason must not be compile environment.Can you try official lizzie 0.6 release.That is the point I forked lizzie and start modify,maybe only work with leela zero.

[hope366]

That was good news.
In addition to dm.dll...

• Installation of CPU version KataGo in addition to OpenCL and TensorRT
• Compress to .zip instead of .rar.
• Menu and other Japanese display

I'm used to PCs and English notation to some extent, so I can use it as it is without much trouble, but many Go users in Japan are old and often have PCs with low specifications.
Therefore, I would like to inform you that the above requests have been raised.

[yzyray]

OK,I can update zip verion packages and all-in-one package with cpu version KataGo,but I dont know Japanese ....and this is my first time attempt to modify a software,so many codes are messy,I think even a Japanese is not easy to translate the menu and other stuff....

[hope366]

Even though I am a beginner in computer programming, I can now translate normal lizzie into Japanese with just a few instructions. However, lizzieyzy has a lot of items, and I think the code is probably complicated, so I don't think it's easy to translate into Japanese. Chinese is a hassle to decipher, but English shouldn't be too difficult once you get used to it ... at least I think so.We hope that many Japanese users will become accustomed to English and master lizzieyzy.
Anyway, I am very grateful to you for responding to my request so far.

[hope366]

In a post a while back, I said that normal lizzie and lizzieyzy sound different from the PC when analysis is on, which was my mistake.
The sound was different because there was a difference in the value of each numSearchThreads.
In the improved version of lizzie, "16" is set based on the result of the benchmark test. I thought that lizzieyzy also set it to "16", but it seems that he forgot to change it to "16" when he upgraded from 2.4.4 to 2.4.5.
I'm sorry for making a misleading report.

[yzyray]

Unfortunately ,I've found the bug have not been totally fixed,If a new dialog(like menu->file->open from online) or tips(like click menu->analze->auto analyze when no next move or delete a branch) is shown and which have not extends lizzieframe(like dialog super(owner) and owner is lizzieframe),after ten or more seconds,the GPU clock will decrese and even close the dialog/tips the GPU clock seems never return high....It happens on all lizzie based jars,lizzie-imrovement/lizzieyzy/patched_0.7.4
Can you try if this will happen on your machine too?
And I also find some other program can help maintain GPU clock,like a browser,so when I test this issue,always close all other programs.

[yzyray]

I have a strange solution...start another jar which has only one JFrame with bug fix codes,and set it invisible.Then no matter how lizzie show tips dialogs..GPU clock never decreased.But it is much too lame....

[kaorahi]

Do you mean that we need something like kaorahi/lizzie@93628753 for all dialogs?

[yzyray]

Do you mean that we need something like kaorahi/lizzie@9362875 for all dialogs?

Yes,but for JDialogs,super(Lizzie.frame); will works,for JOptionPane,JOptionPane.showConfirmDialog( Lizzie.frame,
does not woks.

[yzyray]

There is another solution,In my previous debug the GPU clock decrease has a premise which is continuously refresh lizzie.frame for a few seconds.
when parseing engine's output info move .... after get new candidates infos,it will refresh lizzie.frame once.
So a dialog/frame/JOptionPane with out bug fixs codes is shown and at same time the engine is pondering,after a few seconds GPU clock decresed.
Maybe another solution is when a new dialog/frame/JOptionPane is shown,we stop ponder automaticly.

[yzyray]

I have only test not panel UI mode previously,just now I tested panel UI mode,GPU clock never decreased no matter which dialog/JOptionPane is shown

[kaorahi]

Only "normal UI" has createBufferStrategy(2). What if you delete this line in gui/LizzieFrame.java?

[yzyray]

The issue seems vary unstable,after reboot and without any start other program,I have found panelUI will also make GPU clocck decreased...even without any dialogs and if remove createBufferStrategy(2) in lizzieframe for normal UI,it will behave like panel UI, GPU clock decreased without any dialogs.

[yzyray]

I've found the condition of how to make panel UI trigger the issue.It is use view->simplify.
In default view panel UI doesnt have this issue,but in simpilfy it has.

[yzyray]

Another clue is when I open a chrome based browser and start lizzie with -Dsun.java2d.opengl=true the GPU clock is low at start without waiting for a few seconds.
When I dont open browser the option -Dsun.java2d.opengl=true will make lizzie maintain the gpu clock high forever with any dialogs with or without createBufferStrategy panel UI or normal UI.

[yzyray]

I think the issue only affect the GPU used to diaplay lizzie,based on test on a laptop can change mode bettween one discrete GPU and two GPUs（the other one is integrate GPU）
And a bug reported long time ago,a machine with 4 GPUs,only first GPU clock is low when runing lizzieyzy.In other case such as runing katago through other GUI 4 GPUs clock is all high.

[kaorahi]

Hmm... Does "analyze-update-interval-centisec" in config.txt affect the issue?

[hope366]

I tried it with lizzie-improvement, but regardless of the type, when I displayed the dialog window anyway, the GPU clock number dropped about 15 seconds later.
"Analyze-update-interval-centisec" tried 1,20,50,100 etc., but it doesn't seem to be effective.

[yzyray]

Yes,changed "Analyze-update-interval-centisec" does not help,even I set to 100,and I tested another lizzie-forked program mylizzie,also have the issue.

[yzyray]

I did a simple test,even with this simple code,the issue remains,just one java file:
frame.createBufferStrategy(2); Can solve the issue in this test,even with shown JOptionPane or JDialog.

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.IOException;

import javax.swing.JDialog;
import javax.swing.JFrame;
import javax.swing.JOptionPane;

public class MainClass {
	  public static void main(String[] args) {
		  JFrame frame= new JFrame();
		  frame.setSize(200,200);		 
		  frame.setVisible(true);
		  frame.createBufferStrategy(2);	//with this line,the issue disappeared	  
		  String engineCommand="\"katago\\katago.exe\" gtp -model \"weights\\g170e-b15c192-s1672170752-d466197061.bin.gz\" -config \"katago\\default_gtp1.cfg\"";
		  try {
			Process process =Runtime.getRuntime()
			  .exec(engineCommand);			
			Thread.sleep(3000);

            Runnable runnable2 =
                new Runnable() {
                  public void run() {
                	  BufferedInputStream inputStream= new BufferedInputStream(process.getInputStream());
                	  try {
                	      int c;
                	      StringBuilder line = new StringBuilder();
                	      while ((c = inputStream.read()) != -1) {
                	        line.append((char) c);
                	        if ((c == '\n')) {
                	        	if (line.toString().startsWith("info")) {
                	        		frame.repaint();
                	        	}
                	          line = new StringBuilder();
                	        }
                	      }
                	    } catch (IOException e) {
                	      e.printStackTrace();
                	    }
                  }
                };
            Thread thread2 = new Thread(runnable2);
            thread2.start();
			 
			sendCommand(new BufferedOutputStream(process.getOutputStream()),"kata-analyze 10");
			JOptionPane.showMessageDialog(
					  null,
		                "test"); //show JOptionPane will not decrease GPU clock in this simple code test
			  JDialog dialog= new JDialog();
			  dialog.setSize(200,200);		 
			  dialog.setVisible(true); //show dialog will not decrease GPU clock in this simple code test
		  } catch (Exception e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	  }
	  
	  private static void sendCommand (BufferedOutputStream stream,String command) throws IOException {
		  stream.write((command + "\n").getBytes());
		  stream.flush();
	  }
}

[kaorahi]

You captured a great hint that looks strange. createBufferStrategy(2) does nothing except for waste of some resources in both patched_0.7.4 and your test code, I suspect. Right? (We have no getBufferStrategy().)

[kaorahi]

Your test code seems to call JOptionPane.showMessageDialog, frame.repaint, etc. outside EDT. Is this ok? Should we use SwingUtilities.invokeLater like featurecat/lizzie#782?

[hope366]

When the dialog window is displayed with "Normal UI" or "View-> Simplify Mode of the panel UI", the number of clocks decreases in 10 seconds or so, but move the mouse cursor around the check box in the dialog window Continuing, the number of clocks seems to remain high.

[yzyray]

Your test code seems to call JOptionPane.showMessageDialog, frame.repaint, etc. outside EDT. Is this ok? Should we use SwingUtilities.invokeLater like featurecat/lizzie#782?
I changed code to use SwingUtilities.invokeLater,all issue remains.

Code

import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.IOException;

import javax.swing.JDialog;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
import javax.swing.SwingUtilities;

public class MainClass {
public static void main(String[] args) {
JFrame frame= new JFrame();
frame.setSize(200,200);
frame.setVisible(true);
frame.createBufferStrategy(2);
String engineCommand=""katago\katago.exe" gtp -model "weights\g170e-b15c192-s1672170752-d466197061.bin.gz" -config "katago\default_gtp1.cfg"";
try {
Process process =Runtime.getRuntime()
.exec(engineCommand);

		Thread.sleep(3000);

        Runnable runnable =
            new Runnable() {
              public void run() {
            	  BufferedInputStream inputStream= new BufferedInputStream(process.getInputStream());
            	  try {
            	      int c;
            	      StringBuilder line = new StringBuilder();
            	      while ((c = inputStream.read()) != -1) {
            	        line.append((char) c);
            	        if ((c == '\n')) {
            	        	if (line.toString().startsWith("info")) {
            	        		SwingUtilities.invokeLater(
            	        		        new Runnable() {
            	        		          public void run() {
            	        		        	  frame.repaint();
            	        		          }
            	        		        });                	        		
            	        	}
            	          line = new StringBuilder();
            	        }
            	      }
            	    } catch (IOException e) {
            	      e.printStackTrace();
            	    }
              }
            };
        Thread thread = new Thread(runnable);
        thread.start();
  		sendCommand(new BufferedOutputStream(process.getOutputStream()),"kata-analyze 10");
    	SwingUtilities.invokeLater(
		        new Runnable() {
		          public void run() {    		      
		    			JOptionPane.showMessageDialog(
		    					  null,
		    		                "test");
		    			  JDialog dialog= new JDialog();
		    			  dialog.setSize(200,200);		 
		    			  dialog.setVisible(true);
		          }
		        });		
	  } catch (Exception e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
  }
  
  private static void sendCommand (BufferedOutputStream stream,String command) throws IOException {
	  stream.write((command + "\n").getBytes());
	  stream.flush();
  }

}

You captured a great hint that looks strange. createBufferStrategy(2) does nothing except for waste of some resources in both patched_0.7.4 and your test code, I suspect. Right? (We have no getBufferStrategy().)

Yes,We have no getBufferStrategy() but there may have some deep level issue to do with hardware acceleration opengl or something(just guessing,I dont have any knowlage about this)...so without the createBufferStrategy(2) GPU clock decreased.Currently createBufferStrategy(2) is the only code could help maintain GPU clock...

[yzyray]

I tested another my machine,does not have the issue at all with all kinds of lizzie based jars.
I also have found a lizzieyzy user with this issue.
Here is the list of some system or hardware info of three machines:
1.my laptop with the issue: one GPU:RTX3060 laptop drivers 496.49 windows10(10.0.18363)
2.my machine without the issue: one GPU:GTX 1060 drivers 425.25 windows10(10.0.14393)
3.a lizzieyzy user with this issue: one GPU:GTX 1050ti windows10 (I have remote controled the machine but have not ware of getting more infomation...)
Maybe operating system or GPU drivers have something to do with the issue,and GPU generation may not affect.I have some trouble to update GPU driver on old system windows10(10.0.14393),and dont have enough time to reinstall system for the machine....

[hope366]

I will also give you information about my environment.
GPU: RTX2060 desktop drivers 496.49 windows10 ver.21H1 (OS build 19043.1288)

[yzyray]

I have noticed,when lizzie caused GPU clock dropped,even start a new katago engine in independent command window and pondering with 'kata-analyze' or 'genmove' the GPU clock is still low.

[yzyray]

Tried some -Dsun.java2d parameters....does not works at all
I'll give up debuging and choose the 'lame' solution:
Start another jvm and run an empty frame with code createBufferStrategy(2) in that jvm to keep GPU clock high.