Mlucas v19 available

[ewmayer]

Originally Posted by henryzz

Are any exponents potentially affected tested and double checked with mlucas?

The signature of the bug is an outright crash - no data corruption is involved, I can be sure of this since I hit it during a PRP run, and after fixing the bug and resuming the run, the ensuing Gerbicz check passed. But I'll be happy to post the expo to the strategic-DC thread in a couple of weeks once my run finishes, if that helps put your mind at ease.

Originally Posted by tdulcet

Thank you Loïc Le Loarer for creating this new PrimeNet script! I just updated my Install Script for Linux to use it. It will automatically set most of the --register options with the computers system info.

Thanks - I hope you and other Mlucas users fnd the new primenet.py useful.

@ewmayer I tried to download the new source tarballs, but I am getting the old MD5 checksums and not what is listed on the Mlucas README. I was going to update my scripts with the new checksums.

Grr - I uploaded the 4 code-tarballs (2 ARM binaries together with sample mlucas.cfg files from my self-tests of said binaries, 2 source-tarballs with different compression methods) one dir above where the should go, into /src rather than /src/C. I only have ftp access to that site, so unable to 'mv' them into the C-subdir. And bizarrely, when I re-upload them into the proper /src/C dir, the server isn't updating the files! See ftp log below, note the 4 files at the end are still dated 18 Jan.

By way of workaround, have uploaded a fresh version of README, which links to the 4 src-files, not the old one in src/C. Please reload README.html and try the links again.

MacBook:src ewmayer$ ll ../*19*.t*
-rwxrwxrwx  1 ewmayer  staff  1210672 Jul  5 13:47 ../Mlucas_v19_c2simd.txz
-rwxrwxrwx  1 ewmayer  staff  1301896 Jul  5 13:47 ../Mlucas_v19_nosimd.txz
-rwxr-xr-x  1 ewmayer  staff  2819344 Jul  5 13:47 ../mlucas_v19.tbz2
-rwxrwxrwx  1 ewmayer  staff  1663952 Jul  5 13:47 ../mlucas_v19.txz
MacBook:src ewmayer$ md5 ../*19*.t*
MD5 (../Mlucas_v19_c2simd.txz) = 281361ac4eb32cc922299fc0d8916035
MD5 (../Mlucas_v19_nosimd.txz) = dab56d0566043b4081ee5048b5cc3842
MD5 (../mlucas_v19.tbz2) = 127178db00bc2852be85bcea4b10988e
MD5 (../mlucas_v19.txz) = 10906d3f1f4206ae93ebdb045f36535c
MacBook:src ewmayer$ mftp
Connected to 209.68.5.141.
220 ProFTPD Server (pair Networks, Inc FTP server) [209.68.5.141]
331 Password required for vang_mayer
Password: 
230 User vang_mayer logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd src/C
250 CWD command successful
ftp> mput ../*19*.t*
mput ../Mlucas_v19_c2simd.txz [anpqy?]? y
229 Entering Extended Passive Mode (|||6186|)
150 Opening BINARY mode data connection for ../Mlucas_v19_c2simd.txz
100% |******************************************************************************************|  1182 KiB  548.29 KiB/s    00:00 ETA
226 Transfer complete
1210672 bytes sent in 00:02 (504.38 KiB/s)
mput ../Mlucas_v19_nosimd.txz [anpqy?]? y
229 Entering Extended Passive Mode (|||7867|)
150 Opening BINARY mode data connection for ../Mlucas_v19_nosimd.txz
100% |******************************************************************************************|  1271 KiB  507.57 KiB/s    00:00 ETA
226 Transfer complete
1301896 bytes sent in 00:02 (486.17 KiB/s)
mput ../mlucas_v19.tbz2 [anpqy?]? y
229 Entering Extended Passive Mode (|||1071|)
150 Opening BINARY mode data connection for ../mlucas_v19.tbz2
100% |******************************************************************************************|  2753 KiB  662.17 KiB/s    00:00 ETA
226 Transfer complete
2819344 bytes sent in 00:04 (643.03 KiB/s)
mput ../mlucas_v19.txz [anpqy?]? y
229 Entering Extended Passive Mode (|||25712|)
150 Opening BINARY mode data connection for ../mlucas_v19.txz
100% |******************************************************************************************|  1624 KiB  619.33 KiB/s    00:00 ETA
226 Transfer complete
1663952 bytes sent in 00:02 (589.63 KiB/s)
ftp> qui
221 Goodbye.
MacBook:src ewmayer$ mftp
Connected to 209.68.5.141.
220 ProFTPD Server (pair Networks, Inc FTP server) [209.68.5.141]
331 Password required for vang_mayer
Password: 
230 User vang_mayer logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd src/C
250 CWD command successful
ftp> ls *19*.t*
229 Entering Extended Passive Mode (|||48690|)
150 Opening BINARY mode data connection for file list
-rw-r--r--   1 vang_mayer users     1210636 Jan 18 16:33 Mlucas_v19_c2simd.txz
-rw-r--r--   1 vang_mayer users     1301848 Jan 18 16:34 Mlucas_v19_nosimd.txz
-rw-r--r--   1 vang_mayer users     2769578 Jan 18 16:34 mlucas_v19.tbz2
-rw-r--r--   1 vang_mayer users     1611944 Jan 18 16:34 mlucas_v19.txz

[Nick]

Is the mput taking the whole source file path as the destination file path,
including the initial two dots?

[ewmayer]

Originally Posted by Nick

Is the mput taking the whole source file path as the destination file path,
including the initial two dots?

I thought it was, based on the fact that it echoes the precise file size transferred, e.g. "1210672 bytes sent." Never had any issues with local-path stuff like this before that I can recall, but anyhow, tried cd'ing up one dir locally, into the precise dir containing the 4 tar-files, re-did the ftp, now as 'mput *19*.*t*', same file sizes echoed, more-or-less-same upload times, but *now* the files actually get updated. WTF? If [shitty ftp utility] can't handle local-paths, then [shitty ftp utility] shouldn't tell me it's uploading files, and take the expected time to upload files, and echo exactly how-many-bytes-transferred, while not actually doing the upload, or uploading to some kind of byte-limbo at the far end. Ridiculous for such a basic Linux utility to misbehave like this, especially since one can't well change the local-dir while in an ftp session, so the need to support local-paths is obvious, for the same reason we support local-paths in a Linux term session: because we want to be able to access files in multiple locations, without having to cd into each one, and then back into the dir we are working from. Jeebus, that's the kind of stupid getting-in-the-user's-way one typically associates with Windows.

/rant

[chris2be8]

Could it have taken the file name you gave it ,including the ../, as the desired destination, and put the files one level up from where you meant to put them? That would explain things.

Also check if mftp has a lcd command. I don't have mftp installed, but ftp does have a lcd command to change local directory.

Chris

[ewmayer]

Originally Posted by chris2be8

Could it have taken the file name you gave it ,including the ../, as the desired destination, and put the files one level up from where you meant to put them? That would explain things.

Yep, that's it - I had Mike/Xyzzy (who owns the account and thus has file-move-and-delete ability, whereas I can only upload) delete the 4 copies that ended up one-dir-too-high (at same time I updated the README links to point back to src/C, correct server-side dir, rather than to the 4 one-to-high-dir files), then re-did my 'failed upload' from my local src/dir using 'mput ../[wildcarded tar-file abbreviation]', and indeed saw what you describe. How silly - in a Linux term-session if I 'cp ../[file] [destination dir]', [file] ends up in [destination dir], not in [destination dir]/.. . Why would one write the code for ftp to behave fundamentally differently?

Also check if mftp has a lcd command. I don't have mftp installed, but ftp does have a lcd command to change local directory.

Chris

Clarification - 'mftp' is my alias for ftp-under-mike's-userid-to-the-server-in-question, i.e. it's just ftp. Using lcd is a good tip - thanks.

[ewmayer]

Originally Posted by bayanne

Curiosity has got the better of me.
Will the new ARM cpu being designed to run Mac OS11 be able to run Mlucas, or is it far too early to know ...

I am keen to start porting my ARM assembly-code routines via the ARM SVE framework to the new Apple/ARM CPUs, but for the life of me cannot find basic info like an Instruction Set Reference and whether the vector-math will be 128-bit-wide like current ARMs, or 256-bits like current x86_64. Had a look here, no joy - the 2nd link sounds promising, but is just a list of typealiases:

https://developer.apple.com/document...our_macos_code

https://developer.apple.com/document...ccelerate/simd

Also, will code built using command-line gcc and llvm/clang - as I use on my venerable Core2Duo MacBook Classic - run on the new Apple-Silicon versions of MacOS, or are binaries going to be inextricably tied to the iOS/Xcode/App-dev framework?

[bayanne]

Originally Posted by ewmayer

I am keen to start porting my ARM assembly-code routines via the ARM SVE framework to the new Apple/ARM CPUs, but for the life of me cannot find basic info like an Instruction Set Reference and whether the vector-math will be 128-bit-wide like current ARMs, or 256-bits like current x86_64. Had a look here, no joy - the 2nd link sounds promising, but is just a list of typealiases:

https://developer.apple.com/document...our_macos_code

https://developer.apple.com/document...ccelerate/simd

Also, will code built using command-line gcc and llvm/clang - as I use on my venerable Core2Duo MacBook Classic - run on the new Apple-Silicon versions of MacOS, or are binaries going to be inextricably tied to the iOS/Xcode/App-dev framework?

Perhaps there will be some similarity to how procedures are run using iPad/iPhone etc ...

[chris2be8]

Originally Posted by ewmayer

Clarification - 'mftp' is my alias for ftp-under-mike's-userid-to-the-server-in-question, i.e. it's just ftp.

From the man page for ftp:

put local-file [remote-file]
Store a local file on the remote machine. If remote-file is left unspecified, the local file name is used after processing according to
any ntrans or nmap settings in naming the remote file. File transfer uses the current settings for type, format, mode, and structure.

So you can copy and rename a file in one operation. The whole man page for ftp is well worth reading if you use it at all often.

Chris

[ldesnogu]

Originally Posted by ewmayer

I am keen to start porting my ARM assembly-code routines via the ARM SVE framework to the new Apple/ARM CPUs, but for the life of me cannot find basic info like an Instruction Set Reference and whether the vector-math will be 128-bit-wide like current ARMs, or 256-bits like current x86_64.

What makes you think Apple CPU will have SVE by end of this year?

[ewmayer]

Originally Posted by ldesnogu

What makes you think Apple CPU will have SVE by end of this year?

SWAG - but if the new Apple CPUs are just running the vanilla Arm 128-bit ASIMD behind all that hoopla, hey, less work for me.

I just hope they're not gonna walled-garden it by requiring code running on it to be packaged as an iOS app, but it does rather seem like just the sort of dickish move modern Big Tech companies like to pull.

[chris2be8]

I learnt a lot about FTP by typing help when in it. That gets a list of commands and you can the ask for help on each command. Which is a bit more concise than the man page.

It's especially useful on a platform where you can't read the man page for some reason (eg z/OS). FTP is similar but not identical on all platforms.

As you may be able to tell I've had to use it on several platforms. But I prefer scp or sftp if they are available.

Chris