LLR Version 3.8.20 released - Page 3

DeleteNull · 2017-04-13, 11:29

I have downloaded the source code (LLR 3.8.20) from Jean Penne's site.
After an update of cpuid.h, cpuid.c, gwnum.c (gwnum directory) now LLR recognizes Ryzen and is using FMA3.

It's a bit faster than default A10, but Ryzen has very slow memory modes. So we have to wait till the BIOS can handle much faster memory to get the full speed.

diep · 2017-12-30, 11:19

hello,
I have same issue like pinhodecarlos - it is at linux box and LLR is restarting from scratch.

After it has saved its own inifile, i killed all sllr64 then i modified the PgenLine numbers in the inifiles it saved, for every core (each core of course has its own directory) and then i restarted it.

It resumes then the number it was busy which is line 2 of the file instead of the line number i had set it to (149,149,149,149,1001,988,945,983).

How do i have it restart at the point i want it to start, other than make new inputfiles?

Maybe save file overwrites line number and if it can't find a correct save file it starts at linenumber 1.

Gonna kill all LLR's again, and then kill all save files, then modify linenumbers then restart it. If that doesn't work i don't know.

Kind Regards,
Vincent

diep · 2017-12-30, 11:26

Seems to work now correct after i deleted all z* files and then restarted. Seems to restart at correct line now.

diep · 2017-12-30, 11:33

Attached the C file i use to split inputs to several files so that many cores start and stop roughly at the same time for an inputfile :)

diep · 2017-12-30, 11:36

Another attempt to upload a file...

Attached the C file i use to split inputs to several files so that many cores start and stop roughly at the same time for an inputfile :)

Happy5214 · 2018-08-13, 19:31

Hey! I was looking at the code, and I think it's a mess. I was always taught that importing .c files directly was bad form. What's the rationale behind that?

Also, if rebirther would be so kind to provide his updated Visual Studio environment files for x86-64 so they can be integrated into the official source distribution, that'd be awesome. The source ZIP still uses a VC++ 6 environment, which is probably fine for 32-bit but useless for 64-bit.

rebirther · 2018-08-13, 19:37

Quote:

Originally Posted by Happy5214

Hey! I was looking at the code, and I think it's a mess. I was always taught that importing .c files directly was bad form. What's the rationale behind that?

Also, if rebirther would be so kind to provide his updated Visual Studio environment files for x86-64 so they can be integrated into the official source distribution, that'd be awesome. The source ZIP still uses a VC++ 6 environment, which is probably fine for 32-bit but useless for 64-bit.

What do you need? Console or GUI? Also which files need an update?

Happy5214 · 2018-08-13, 19:50

Both if it's not too much to ask for. Updated sources would help, as I had compilation errors.

Jean's source has VC++ 6 project files (.dsp, etc.). My copy of VS 2013 upgraded them, but I'm not sure they're completely right. In particular, VS defaulted the build to 32-bit instead of 64-bit.

I'm a Linux guy, so I'm a bit out of my element here. But I'm trying to clean up the cross-platform code, so having a good Windows base will help.

rebirther · 2018-08-13, 20:00

Quote:

Originally Posted by Happy5214

Both if it's not too much to ask for. Updated sources would help, as I had compilation errors.

Jean's source has VC++ 6 project files (.dsp, etc.). My copy of VS 2013 upgraded them, but I'm not sure they're completely right. In particular, VS defaulted the build to 32-bit instead of 64-bit.

I'm a Linux guy, so I'm a bit out of my element here. But I'm trying to clean up the cross-platform code, so having a good Windows base will help.

Try this:
1. switch platform to 64bit / 32 bit
2. link the correct gwnum lib 64bit/32bit
3. in properties go to C/C++ -->commandline -->add /DX86_64 in more options for 64bit

I will send you a link for the console the complete source (64bit modified).

2017-04-13, 11:29	#23
DeleteNull Mar 2017 Germany, Wolfsburg 4₁₆ Posts	I have downloaded the source code (LLR 3.8.20) from Jean Penne's site. After an update of cpuid.h, cpuid.c, gwnum.c (gwnum directory) now LLR recognizes Ryzen and is using FMA3. It's a bit faster than default A10, but Ryzen has very slow memory modes. So we have to wait till the BIOS can handle much faster memory to get the full speed. Last fiddled with by DeleteNull on 2017-04-13 at 12:14

2017-12-30, 11:19	#24
diep Sep 2006 The Netherlands 1100100111₂ Posts	hello, I have same issue like pinhodecarlos - it is at linux box and LLR is restarting from scratch. After it has saved its own inifile, i killed all sllr64 then i modified the PgenLine numbers in the inifiles it saved, for every core (each core of course has its own directory) and then i restarted it. It resumes then the number it was busy which is line 2 of the file instead of the line number i had set it to (149,149,149,149,1001,988,945,983). How do i have it restart at the point i want it to start, other than make new inputfiles? Maybe save file overwrites line number and if it can't find a correct save file it starts at linenumber 1. Gonna kill all LLR's again, and then kill all save files, then modify linenumbers then restart it. If that doesn't work i don't know. Kind Regards, Vincent Last fiddled with by diep on 2017-12-30 at 11:21

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LLR Version 3.8.19 released	Jean Penné	Software	11	2017-02-23 08:52
LLR Version 3.8.15 released	Jean Penné	Software	28	2015-08-04 04:51
LLR Version 3.8.11 released	Jean Penné	Software	37	2014-01-29 16:32
LLR Version 3.8.9 released	Jean Penné	Software	37	2013-10-31 08:45
llr 3.8.2 released as dev-version	opyrt	Prime Sierpinski Project	11	2010-11-18 18:24

2017-12-30, 11:26	#25
diep Sep 2006 The Netherlands 1447₈ Posts	Seems to work now correct after i deleted all z* files and then restarted. Seems to restart at correct line now.

2017-12-30, 11:33	#26
diep Sep 2006 The Netherlands 327₁₆ Posts	Attached the C file i use to split inputs to several files so that many cores start and stop roughly at the same time for an inputfile :)

2018-08-13, 19:31	#28
Happy5214 "Alexander" Nov 2008 The Alamo City 991 Posts	Hey! I was looking at the code, and I think it's a mess. I was always taught that importing .c files directly was bad form. What's the rationale behind that? Also, if rebirther would be so kind to provide his updated Visual Studio environment files for x86-64 so they can be integrated into the official source distribution, that'd be awesome. The source ZIP still uses a VC++ 6 environment, which is probably fine for 32-bit but useless for 64-bit.

2018-08-13, 19:50	#30
Happy5214 "Alexander" Nov 2008 The Alamo City 991₁₀ Posts	Both if it's not too much to ask for. Updated sources would help, as I had compilation errors. Jean's source has VC++ 6 project files (.dsp, etc.). My copy of VS 2013 upgraded them, but I'm not sure they're completely right. In particular, VS defaulted the build to 32-bit instead of 64-bit. I'm a Linux guy, so I'm a bit out of my element here. But I'm trying to clean up the cross-platform code, so having a good Windows base will help.