I bought an M1 MacBook Air in November of 2020, and while in general I’ve had no performance issues with it, the one thing I’ve noticed is that downloads with NZBGet are noticeably slower than they were on my Intel Mac. This includes hacking, using a loophole, or other methods not publicly advertised by the usenet provider. No promoting of 'backdoor' access into usenet providers' networks. We do not allow attempts to request/offer/buy/sell/trade/share invites or accounts. We will even add flair to your username after verification. Message the mods and let them know who you are. ![]() However we want to verify the identity of anyone posting on behalf of a company/project. ![]() No discussion of specific media content names, titles, etc. We only have a few, but they are important. Please read over the rules before contributing. We are a thriving community dedicated to helping users old and new understand and use usenet. On the other side 64bit code takes more space in CPU cache which is very limited and that can have a negative impact on performance.Welcome to the usenet subreddit. The download code (yEnc, CRC computing) doesn't user 64bit numbers. I have both 32bit and 64bit binaries for Linux only but I don't have a real x86 machine with Linux and making tests in a VM isn't very precise.Įven if using the same compiler and same standard library - you can never tell which one of 32bit binary or 64bit binary is faster without benchmarking.Ħ4bit program can compute 64bit numbers faster but not every program works with 64bit numbers. I can't make such a test on Windows (only 32 bit binary) or Mac (only 64 bit binary). How is the speed on x86 32bit versus 64-bit? I don't know how much impact libraries have on NZBGet performance. When you compile directly on machine you probably have glibc. It however didn't work with aarch64 toolchain. For all architectures in lunux installer I use uclibc standard library. There is still a difference between aarch64 and armhf builds. The two versions were build using different compilers versions and use different standard libraries.Ĭan you also test the aarch64 version I've built using the same compiler (as armhf version from installer)? It's not a complete installer, you have to take the binary from archive and put it into your existing installation. In that case you compare not only 32bit vs 64bit. The storage is the bottleneck, and 64bit is slower, which I cannot explain, because CPU-load was low. Makefile.am:22: warning: source file 'daemon/extension/NzbScript.cpp' is in a subdirectory, Makefile.am:22: warning: source file 'daemon/extension/CommandScript.cpp' is in a subdirectory, Makefile.am:22: warning: source file 'daemon/extension/FeedScript.cpp' is in a subdirectory, Makefile.am:22: warning: source file 'daemon/connect/WebDownloader.cpp' is in a subdirectory, Makefile.am:22: warning: source file 'daemon/connect/TlsSocket.cpp' is in a subdirectory, However,Īutomake: this behaviour will change in future Automake versions: they willĪutomake: unconditionally cause object files to be placed in the same subdirectoryĪutomake: You are advised to start using 'subdir-objects' option throughout yourĪutomake: project, to avoid future incompatibilities. For now, the corresponding outputĪutomake: object file(s) will be placed in the top-level directory. Makefile.am:22: but option 'subdir-objects' is disabledĪutomake: warning: possible forward-incompatibility.Īutomake: At least a source file is in a subdirectory, but the 'subdir-objects'Īutomake: automake option hasn't been enabled. Makefile.am:22: warning: source file 'daemon/connect/Connection.cpp' is in a subdirectory, /lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from. /lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from. ![]() /lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from. UNAME_VERSION = #4 SMP Sun Jul 9 19:19:37 CEST 2017Ĭonfigure: error: cannot guess build type you must specify aclocalĬonfigure.ac:602: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body Pertinent to in order to provide the needed Send the following data and any information you think might be If the version you run (posix/config.guess) is already up to date, please It is advised that youĭownload the most up to date version of the config scripts from This script, last modified, has failed to recognize posix/config.guess: unable to guess system type
0 Comments
Leave a Reply. |