Beta 4 now available

[Brian the Fist]

Again, files are at:

ftp://ftp.mshri.on.ca/pub/distribfol...ux-i386.tar.gz

for Linux

ftp://ftp.mshri.on.ca/pub/distribfol...beta-win9x.zip

for Windows text client

ftp://ftp.mshri.on.ca/pub/distribfol...beta-win9x.zip

for Windows screensaver

Please see the enclosed readme for what has changed. Beta 3 will no longer work (sorry folks, but this IS a beta test). For installation instructions for the screensaver, see the beta 3 thread.

For any of these betas, either download a clean copy from the website again and overwrite the files with the contents of the above archives, or at a minimum delete your filelist.txt and overwrite an existing beta 3 installation with the contents of the above archive.

At this point we are now more optimizing the algorithm than the software itself, but please do report any more bugs that you may find/think you found in this thread.

Thanks.

(the links above were broken before - should be right now)

[m0ti]

You mentioned that we're using RMSD again for scoring.

Does this mean that the client is no longer working ab inito (sp) for this protein?

[Brian the Fist]

Originally posted by m0ti
You mentioned that we're using RMSD again for scoring.

Does this mean that the client is no longer working ab inito (sp) for this protein?

That is correct - we want to look at the 'folding graphs' with an ideal scoring function now, and see a) how folded it gets in 250 generations b) how much the energies go up and down along the folding pathway c) at what point it is useless to continue to more generations (hopefully less than 250) d) etc etc.

This will help us decide how to parameterize it for the final release (which may be next if this is the last beta)

[Akkermans]

Howard,

Does this mean that we should let our PC's run for a long period to generate a large amount of structures/generations?

Cheers,
Akkermans

[Brian the Fist]

Try to get to 250 generations please, yup. Then it will restart at 1 again (like it did at generation 50 until now). And like I said, if you see any bugs on the way, let us know but we don't expect any (expect that weird one from AMD_is_logical which I cannot fix yet).

[pfb]

Something I am seeing under XP with Beta 4 is that CSRSS.EXE is taking a fair chunk of CPU time (anywhere from 10 to 25% - - via Task Manager - see below) when run as a normal console (command window) application and only goes away if I run in quiet mode (via dfGUI v2.2)...I will try as a service and see if the same problem occurs but this hasn't been observed with previous betas and I had restarted the PC before running Beta 4...

According to MS's site (http://support.microsoft.com/default...b;en-us;175788) this is may be due to 'A command window will cause the CSRSS process to use more resources on a computer running Windows NT depending on the properties that are selected for the CMD window. ' but I can't see any XP options which could cause this...

System:

Pentium 4 @ 2.7GHz, 512MB RAM
Radeon 8500 with Catalyst 3.1 drivers
Clean install of Beta4

Betas 1 to 3 and standard DF install don't cause this - only Beta 4 does...anyone else experiencing similar problems with CSRSS?

Screen shot of usage:



edit - service is the same as quiet mode...and after another reboot the problem still exists when run as a normal console application.

[mighty]

Originally posted by pfb
Betas 1 to 3 and standard DF install don't cause this - only Beta 4 does...anyone else experiencing similar problems with CSRSS?

On my system it has been that way ever since the first version I ever installed. Through all the previous proteins and through all the betas. They all take up to 10-15% CPU on CSRSS.EXE whenever I run it in ASCII mode.
The only way to get rid of that is to run it in quiet mode.

For Howard:
You say 250 generations, but in the readme from beta4 it says 300 generations. Which one is it?

Regards
Ole

PS: Running on w2k

[bwkaz]

Segfaults! Fun, fun!

I've just grabbed beta 4, decompressed a fresh (latest non-beta, that is) normal tarball, then decompressed the beta 4 tarball over top of it. When running the client, it has crashed at structs 5, 9, 23, 67, 101, 120, 119 (which was after 120 -- it must not have made it back from the backtrack point), 124, and 127, each time with the same message in error.log:

ERROR: [001.001] {foldtrajlite2.c, line 1351} Caught sig 11

I am not doing anything strange with it that I know of.

Switches are -it -rt

I realize this probably isn't a great bugreport, but I'm not sure of what to try to reproduce it (other than just run the client).

If it helps, system details:

Linux -- LFS 3.3, with some updated packages
gcc 3.2, with all packages compiled using it, so no compatibility libraries exist.
glibc 2.2.5+linuxthreads (a pthreads implementation)
kernel 2.4.20+preempt
ncurses 5.2, with the required (I think...) libncurses.so.4 symlink

The normal (non-beta) client was running the first few times it crashed, so I thought that might have had something to do with it, but stopping the normal client didn't help anything. The first four crashes were with the normal client running, the fifth through ninth were with nothing else running.

I was running the foldtrajlite executable under gdb on the last crash. A stack backtrace produced:

#0 0x08051801 in strcpy ()
#1 0x096447c8 in ?? ()
#2 0x08052956 in strcpy ()
#3 0x080549f9 in strcpy ()
#4 0x08054a10 in strcpy ()
#5 0x0837e475 in error ()
#6 0x400c6102 in __libc_start_main () from /lib/libc.so.6

So I don't think that helps much.

My guesses -- it might be something with backtracking or with loosening the "laxness", since it seems to not happen consistently. Or it might be something with the gcc version. Or it might be something with the ncurses 4 symlink (was that required or not? the normal client -- icc version -- doesn't need it, but the beta complained about a missing lib until I added it). Obviously I have no real idea, though, since my executable doesn't have debug symbols in it, so the backtrace appears to be nonsense.

I'm willing to try anything you think would help.

[Digital Parasite]

I am now running beta4 on my WinXP box (-rt -g 1).

As soon as I started the client it said 1 gen. buffered even though it started on generation 0 doing the 10000 initial structures. Shouldn't this still read 0 gen. buffered until it has finished the generation 0 and started generation 1?

Also, you said we were switching to RMSD which appears to be the case since I am now reporting 13.762 but the progress.txt file still reads: "Best Energy so far: 13.762"

For the eventual release of the new algorithm are you going to stick with RMSD or did you just switch to that for beta4 and we will be going back to best energy?

Jeff.

[Georgina]

Originally posted by pfb

Betas 1 to 3 and standard DF install don't cause this - only Beta 4 does...anyone else experiencing similar problems with CSRSS?

I am currently running on W2k server. I don't have a screen shot but i watched Task manager for a minute or so and CSRSS used between 00 and 03 CPU.

G

[Aegion]

One issue I'm still noticing with the beta is that the beta website still labels the point score we receive for our your as

# of structures generated

This is no longer accurate since the beta is now tabulating your score from the units you process. This issue will also lead to a huge number of "bug-reports" from individuals noticing disparities in their structures being counted if release to the non-beta testing public in its current form. This needs to be addressed before the beta is finished. The current # of structures generated should be replaced with the label total points or some other catchy sounding name that makes it clear that the total number of structures generated is no longer what is being counted.

[Brian the Fist]

Originally posted by Digital Parasite
I am now running beta4 on my WinXP box (-rt -g 1).

For the eventual release of the new algorithm are you going to stick with RMSD or did you just switch to that for beta4 and we will be going back to best energy?

Jeff.

We'll be going back to best energy, dont worry about that

[Brian the Fist]

Originally posted by Aegion
One issue I'm still noticing with the beta is that the beta website still labels the point score we receive for our your as This is no longer accurate since the beta is now tabulating your score from the units you process. This issue will also lead to a huge number of "bug-reports" from individuals noticing disparities in their structures being counted if release to the non-beta testing public in its current form. This needs to be addressed before the beta is finished. The current # of structures generated should be replaced with the label total points or some other catchy sounding name that makes it clear that the total number of structures generated is no longer what is being counted.

Will do.

[Brian the Fist]

Originally posted by mighty
On my system it has been that way ever since the first version I ever installed. Through all the previous proteins and through all the betas. They all take up to 10-15% CPU on CSRSS.EXE whenever I run it in ASCII mode.
The only way to get rid of that is to run it in quiet mode.

For Howard:
You say 250 generations, but in the readme from beta4 it says 300 generations. Which one is it?

Regards
Ole

PS: Running on w2k

250 generations.
readme is wrong
If csrss hogs resources when running in ASCII mode, then run in quiet mode (when not beta-testing) or use Linux . I have no control over how Windows manages its resources...

[Brian the Fist]

Originally posted by bwkaz
Segfaults! Fun, fun!


My guesses -- it might be something with backtracking or with loosening the "laxness", since it seems to not happen consistently. Or it might be something with the gcc version. Or it might be something with the ncurses 4 symlink (was that required or not? the normal client -- icc version -- doesn't need it, but the beta complained about a missing lib until I added it). Obviously I have no real idea, though, since my executable doesn't have debug symbols in it, so the backtrace appears to be nonsense.

I'm willing to try anything you think would help.

I'll try it on my box first, and if that doesn't crash I'll send you a copy with symbols not stripped out. Send an e-mail to trades@mshri.on.ca so I have your e-mail address and then I can send it to you if need be. Thanks.

[Welnic]

I think that the behavior of progress.txt needs to change a little. With the normal client even if you had the -g switch set to 100 it was still only a couple of minutes before the file was first written. Now even at the default setting, (which seems to be 5), it can be a long time after you restart in the later generations before the file gets written. Some people look at this file after foldtrajlite.lock is removed to check if the client is truly finished.

I think that when you first restart the program it should make the file right away listing the last fold that was done. I also think that it should be updated when a generation is finished.

[Brian the Fist]

Thats easy enough to change - I'll do it for the next version.

[Welnic]

Originally posted by Brian the Fist (from another thread)
We're a step ahead of you - the 3 minutes is not the limit anymore - it now 'times out' after 3 minutes or about 250000 tries (to place a residue), whichever comes first. On a 2GHz machine, these turn out to be about the same. The 250000 tries was carefully chosen based on previous observations and is not arbitrary. It will not be lowered for any reason as soing so will damage potential results.

So if you want it to try 250000 times why have the 3 minute cutoff? I admit it would be a bummer to watch it stuck for 12 minutes on a 500MHz machine, but it is also a bummer to have a 500MHz machine for folding. People just shouldn't watch.

It does seem to me that I can get more structures done by running 4 instances of the client so that it only does 62500 tries and gives up after 3 minutes. And AMD_is_logical has demonstrated that changing the clock rate works wonders for score production. I have 9 dedicated processors in my farm that I can change the clock rate on (I would imagine that I would eventually figure it out), but if you want it to try 250000 times I would rather do that as long as everyone did.

[Brian the Fist]

Yes, AMD_is_Logical has certainly discovered another way to 'cheat', in terms of pushing up the score by speeding up the clock. We will definitely make sure that doesn't stay for the final verison. I am interested however to see how his results compare to everyone elses. If you look at the graphs for his movie, the RMSD initially decreases quickly to about 6, but has not shown improvement since then. Once everyone else catches up to him, so to speak, in a couple of days, it will be interesting to see if they do any better. This will help us decide about what to use as the limit cutoff. It seems that although speeding up the clock to make it give up early may get more structures made, but hurt the results in terms of the quality of the structure. In the end, the timeout will likely depend on total number of tries only (not on real-time) and will likely depend on several factors - the length of the protein, the generation and how far along the protein chain it is getting stuck at. We shall see though, gotta analyze more data first.

[bwkaz]

All right, my segfault problem appears to have been random. The problem was that it failed to write any filenames to filelist.txt after struct 5 on the first run; every crash after that was because the program was expecting filenames to be there but there were none.

I suspected at first that the reason nothing was written was that I was LD_PRELOAD'ing the libhpi.so file from Java 1.4.1 (so that Java itself would load and work), because when I got rid of that and deleted filelist, it started working. But redeleting filelist and setting LD_PRELOAD also makes it work just fine, so it wasn't just LD_PRELOAD.

I wish I knew what caused it, but at least it works now. If anyone is seeing anything like that in the future with beta 4 (this specific problem will be handled with a more specific error message than "caught sig 11" in later client versions), check whether filelist.txt contains any filenames, or if it's just a CurrentStruc line and a digital signature (bunch of gobbledeygook characters). If it's just a CurrentStruc line and a signature, then try deleting it.

I've also been experimenting a little with quitting at strange times, like before the first struct was created, and I can't force the program to create a bad filelist anymore. I know I didn't just delete the two lines referencing the files, because I tried that again and it (that is, filelist.txt) failed the digital signature validation.

The one interesting thing was that when I hit ctrl-c at some point during the generation of struct 5, I was able to reproduce something I had forgotten about the first time through -- the ncurses stuff got deinitialized, but the foldtrajlite process never exited (until I sent it a TERM signal from another shell). But even that didn't corrupt the filelist.txt, so it's not like it was a problem, even though subsequent ctrl-c's weren't accepted.

Wish I knew what caused the first problem... oh well, though, it works now.

[Digital Parasite]

I have been running beta4 with -rt on my P3-800 WinXP box for about a day and a half now.

FYI, It seems to be taking me about 10 hours to do 5 generations, so about 2 hours/generation which means that I will finish all 250 generations in about 21 days total. Time for a faster computer...

Jeff.

[Brian the Fist]

AMD_is_logical - can you explain to me exactly what you are doing to get the accelerated performance here (I know speeding up your clock, but by how much, and anything else)? This will be useful to know when we compare your results to those of the others and help us make a final decision on how the timeout really should work.

[mighty]

Running on w2k, switches -rt. Running regular client, not as a service.
Running on an Athlon Xp 2100+ (not overclocked!)

I don't know if this is a bug, but at the end of generation 64 the client crashes every time. It writes the following on-screen and in error.log:
"FATAL ERROR: [023.024] {trajtools.c, line 2492} RLEUnPack failed, size=2, should=400*0 - likely this is caused by overclocked or faulty RAM chips, please test your RAM"

I know the message suggests faulty equiment on my part, and of course that is a possibility, but I have been running the "real" client for over a year and all the betas without any problems whatsoever.
The other things that puzzles me about the error, is the fact that after completing structure 50 of generation 64 the client goes straight to the "generation trajectory for gen 65" message. It skips the "minimizing energy" part.

I have saved all the files a point right before the crash, so whenever I re-start it makes structure 50 and then crashes. This can be repeated over and over again (have done it abour 5 times sofar).

Am currently running "MemTest" to see if I should have developed faulty RAM, but sofar no errors.

[Brian the Fist]

When exactly does it crash, at what point - at the end of making the trajectory distribution or the beginning? or the middle?

It is possible that there is a problem with the structure from the previous generation. If you like you can e-mail me the *.val , *.log.bz2, filelist.txt and the *.trj file with the highest number in it (send to trades@mshri.on.ca) and I can look and see if anything is amiss (or at least verify if I get the same error).

[tpdooley]

When I log onto the Beta High Flyer's page, it informs me that I'm in 10th place on the RMS race. And that I've contributed 2686 structures. And my team has contributed 2474 structures.
Which one of my teammembers in The Genome Collective uploaded -212 structures?

Ah.. refreshed the screen again, and my score now matches the team score.

[mighty]

Originally posted by Brian the Fist
When exactly does it crash, at what point - at the end of making the trajectory distribution or the beginning? or the middle?

It is possible that there is a problem with the structure from the previous generation. If you like you can e-mail me the *.val , *.log.bz2, filelist.txt and the *.trj file with the highest number in it (send to trades@mshri.on.ca) and I can look and see if anything is amiss (or at least verify if I get the same error).

It crashes at the start of making the trajectory distribution. Maybe 2 or 3 seconds into it. I'll will mail you the files you mention.

I also tried copying the entire client directory to another computer (866MHz Intel P3 laptop running w2k) and it made the exact same error at the exact same time, so I am almost positive it's not due to bad RAM or otherwise faulty hardware.

[Aegion]

Originally posted by tpdooley
When I log onto the Beta High Flyer's page, it informs me that I'm in 10th place on the RMS race. And that I've contributed 2686 structures. And my team has contributed 2474 structures.
Which one of my teammembers in The Genome Collective uploaded -212 structures?

Ah.. refreshed the screen again, and my score now matches the team score.

There is a delay for update the general stats while your personal stats are updated immediately. This is the reason for the discrepancy.

[Welnic]

Originally posted by mighty
It crashes at the start of making the trajectory distribution. Maybe 2 or 3 seconds into it. I'll will mail you the files you mention.

I also tried copying the entire client directory to another computer (866MHz Intel P3 laptop running w2k) and it made the exact same error at the exact same time, so I am almost positive it's not due to bad RAM or otherwise faulty hardware.

It really doesn't sound like it's bad RAM from things you said in your earlier post. But on the last test that you did bad RAM could have messed up one of the files that was saved, so at that point it would crash any computer.

[AMD_is_logical]

Originally posted by Brian the Fist
AMD_is_logical - can you explain to me exactly what you are doing to get the accelerated performance here (I know speeding up your clock, but by how much, and anything else)? This will be useful to know when we compare your results to those of the others and help us make a final decision on how the timeout really should work.

I wrote a little program that gets the time (as an integer, seconds since 1970 or some such thing) and puts it in a local variable. It then goes into an infinite loop where it sleeps for one second, adds 60 to the variable, then sets the time to that value. This runs in the background on the node. The structures seem to timeout after 4 seconds.

I have two nodes on the AMD_is_logical account. They use XP1800 CPUs and run linux. They use -rt -if -qt -p0 -g0 for flags. (The -g0 seems to protect them from that bug which we couldn't find in beta3. I am working on that bug on another node.)

I plan on being consistant with that account. If I decide to try something else, I'll do it to a different account.

[Welnic]

I like having the Best RMS (Energy) so far in progress.txt. It is nice to see that decrease over the generations.

The normal client cranks through the folds at a predictable rate, but it is a total crapshoot on the results. The beta is random on how long it takes to do the folds, but gets consistently better results as the generations build. The clients obey Fredstien's Third Law of the Conservation of Randomness.

[tpdooley]

While looking at the (details) results of the top ten beta folders, I noticed that I couldn't find a way of seeing my details after dropping off the top ten list. I'd plummeted until about generation 15, and then started climbing. So I looked at everyone else's.
We seem (with a very small sample to base this opinion on) to hit a valley between generation 15-40; and then climb awhile; hit a peek, and plummet again.
To speed the return to a decline would the following test work? - A. if the last generation was not less than the average of the last 10 generations (to allow short spikes up) - or B. if the last generation was not less than either of the 2 preceeding generations (to return to normal after we're beyond the peek), then dramatically reduce the number of time/tries testing for possibilities.
..once the client sees that it's in a decline again, return to normal.
(Just a thought about how to use AMDisLogical's approach to help speed up the wasted time climbing up to a peek).

[AMD_is_logical]

I just added two nodes (also XP1800) to my "AMD beta test account". The difference between these nodes and the ones on my other account is that here I'm using +185 in my realtime program, which gives a timeout of 2 seconds. I'm hoping that comparing results from the two accounts will give an idea of what the effect of changing the timeout is (when using a short timeout).

With this timeout, the nodes spend more time doing the minimize/trajectory stuff than actually crunching the 50 structures.

[Brian the Roman]

Howard;
once you've decided on things like initial sample size, sample size per generation, # of generations etc; will you return to a pure ab inito approach?

ms

[Brian the Fist]

Originally posted by Brian the Roman
Howard;
once you've decided on things like initial sample size, sample size per generation, # of generations etc; will you return to a pure ab inito approach?

ms

We will use 'crease energy' as the scoring function instead of RMSD, likely, if that is what you mean. We can compute teh crease energy with no knowledge of the correct folded structure so it is 'ab initio'.

[Brian the Fist]

Originally posted by AMD_is_logical
I just added two nodes (also XP1800) to my "AMD beta test account". The difference between these nodes and the ones on my other account is that here I'm using +185 in my realtime program, which gives a timeout of 2 seconds. I'm hoping that comparing results from the two accounts will give an idea of what the effect of changing the timeout is (when using a short timeout).

With this timeout, the nodes spend more time doing the minimize/trajectory stuff than actually crunching the 50 structures.

Can you do me one more small favor? From the node which generated your 5.5A movie (that is sped up, from what I understand, by a factor of 60), can you post/e-mail be the filelist.txt from it when it is on roughly structure #20 in generation 50 or higher (I assume now that it reached 250 it has reset and is going again on a new set)? I want to see the numbers in there which tell me how 'lax' the structures you are producing are. Thanks.

[Welnic]

With the new way of folding I would like to have a results.txt file. This would have the best score from each generation listed so we could make our own RMS improvement graphs for each processor.

run:1
gen0:14.267
gen1:11.398
gen2:11.243

[Brian the Fist]

Perhaps it would be better if I distributed the software we have made to generate all those graphs (since you can already download your best movie, and that is all that is required for input). I'll discuss it with the boss and maybe that'd be a better and more interesting solution.

[AMD_is_logical]

Originally posted by Brian the Fist
Can you do me one more small favor? From the node which generated your 5.5A movie (that is sped up, from what I understand, by a factor of 60), can you post/e-mail be the filelist.txt from it when it is on roughly structure #20 in generation 50 or higher (I assume now that it reached 250 it has reset and is going again on a new set)? I want to see the numbers in there which tell me how 'lax' the structures you are producing are. Thanks.

I ran the client with quiet mode off (but otherwise with the same switches). I stopped it around structure number 20 and logged the contents of the filelist.txt file. I repeated for several generations, and did the same for two other nodes as well.

I assume you just want the CurrentStruc line. (Let me know if need something else. I still have the entire contents logged.)

Here's the 60x (4 sec timeout) node that produced that structure.
It was doing generation 168.

CurrentStruc 1 20 123 168 1 6 7.291 -272.471 1497.552 207.135 11748199.000 1.400 2.600 1163.098
CurrentStruc 1 21 123 169 1 19 7.207 -284.427 978.283 241.184 9940255.000 1.400 2.600 1163.098
CurrentStruc 1 20 123 170 1 11 7.249 -469.606 1236.111 185.136 8855551.000 1.300 2.400 879.469
CurrentStruc 1 21 123 172 1 14 7.214 -100.283 2014.440 299.015 18499776.000 1.300 2.400 879.469


Here's the other 60x node. (Although it runs at the same speed, it was taking longer to do these generations.)
It was doing generation 215.

CurrentStruc 1 21 123 215 1 16 6.389 -2022.274 -804.780 -585.711 45021196.000 2.050 3.900 7156.295
CurrentStruc 1 21 123 216 1 5 6.324 -2227.056 -1304.998 -736.268 69396480.000 2.150 4.100 9464.200
CurrentStruc 1 20 123 217 1 17 6.340 -2311.714 -1109.748 -666.149 60635824.000 2.150 4.100 9464.200
CurrentStruc 1 20 123 218 1 19 6.314 -1784.907 -452.469 -521.274 37506988.000 2.150 4.100 9464.200


Here's one of the 185x (2 sec timeout) nodes that I have crunching to my other account.
It was doing gen 151.

CurrentStruc 0 21 123 151 1 5 6.055 -2247.021 -533.654 -518.490 36841944.000 1.550 2.900 1768.926
CurrentStruc 0 21 123 152 1 18 6.024 -2301.021 -432.239 -486.721 35569452.000 1.550 2.900 1768.927
CurrentStruc 0 21 123 153 1 19 5.911 -3010.360 -748.922 -651.610 63574196.000 1.500 2.800 1538.197
CurrentStruc 0 20 123 154 1 13 5.841 -2391.077 -862.600 -551.492 43018768.000 1.400 2.600 1163.098

[Brian the Fist]

Ok, that's fantastic, thanks. I was mainly interested in the last 3 numbers which let me see how 'loose' it was letting the structures get. (And thus how poor quality they will be). The starting values are 0.85, 1.5 and 500. When the first number is about 1.5 or less the structures shouldnt be too bad but when it gets to above 2.0 its probably starting to suck.

Also it appears these numbers are not changing much from generation to generation so it may not be wise to reset them to (0.85,1.5,500) at the start of each new generation, it may be best to just keep them from the previous generation. My main concern is I do not want the protein 'cutting through itself' which could happen if the structures get sloppy enough. Anyhow, I'll take this all into consideration as I decide exactly hwo the final version will work. The last piece of data I will need is to see how everyone else does compared to AMD_is_logical once you've all completed your 60x slower 250 generations.

You have all been most helpful so far, thanks.

[m0ti]

Originally posted by Brian the Fist
Ok, that's fantastic, thanks. I was mainly interested in the last 3 numbers which let me see how 'loose' it was letting the structures get. (And thus how poor quality they will be). The starting values are 0.85, 1.5 and 500. When the first number is about 1.5 or less the structures shouldnt be too bad but when it gets to above 2.0 its probably starting to suck.

Also it appears these numbers are not changing much from generation to generation so it may not be wise to reset them to (0.85,1.5,500) at the start of each new generation, it may be best to just keep them from the previous generation. My main concern is I do not want the protein 'cutting through itself' which could happen if the structures get sloppy enough. Anyhow, I'll take this all into consideration as I decide exactly hwo the final version will work. The last piece of data I will need is to see how everyone else does compared to AMD_is_logical once you've all completed your 60x slower 250 generations.

You have all been most helpful so far, thanks.

Just started Gen 75.