Microsoft drops 64-bit OneDrive into the pool: Windows on ARM fans need not apply. As usual Microsoft has released a 64-bit preview of its OneDrive sync client for Windows, citing "large files" and "a lot of files" as a driver for the update. The update has been among user wishes for a while, with a 2016 whinge topping the charts ahead of arguably more useful feature requests such as syncing over a local LAN or ( …
Does it need 64 bit? It's a sync tool. It might be moving large files but it doesn't have to open them, and even if it did it doesn't need to be in one big gulp.
The Visual Studio IDE is still 32 bit. While it might not be everyone's cup of tea, it's not the fact that it's 32 bit that's the issue, is it? Horses for courses.
>It might be moving large files but it doesn't have to open them, and even if it did it doesn't need to be in one big gulp.
But that requires design. I suspect the sync tool uses 'simplistic' code and so needs the full 64-bit unsigned integer space for the pointer to the current position in file etc.
On amd64 architecture 64-bit applications perform better due to doubling the amount of registers. There may be a small hit by the larger pointer type but it's usually negligible.
Also, with 64 bit address space there's more room for ASLR and that's a security benefit.
And if we can get rid of all 32-bit applications on 64-bit windows we can probably kick WOW64 in the gutter. Although I'm sure MS will still use it for obscure reason that is not immediately obvious.
A sync tool, does not need to address 64bit memory addresses.
It has no need to load the whole file in memory. A 32bit app is still able to use 64bit arithmetic for offsets points into files greater than 4GB as it sync fragments. After all the network MTU is 1500 bytes typically so a sync tool has to slice up a file for syncing.
If anything the problem these days is memory bloat with sync tools and chat applications thinking its okay to consume > 1GB of memory to run what 10 years ago took 10MB on Windows 2000 or XP.
This is people failing to understand 64bit apps are actually for memory addressing. If the sync tool needs more than 4GB or for that matter more than 50MB I would think its best to leave it well alone as its not fit for purpose as a background lightweight utility.
Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha.
Ha.
Ha ha.
But seriously, OneDrive is currently using nearly 2% of my six-core system and best part of a GB of RAM just ticking over. In contrast, DSynchronize (which is great, by the way, if a little quirky) is using 0% and 6.7MB [sic]. And they're realtime-syncing exactly the same files (just to different places).
OneDrive on my Mac regularly kicks up to over 100% CPU usage and makes the fans spin. This week it has steadfastly refused to synchronise anything upwards and I've had to revert to manually uploading files via the web interface to SharePoint.
OneDrive is a crock of sh*te regardless of how many bits it uses to address file and code space.
Micros~1 is apparently still up to their "let background processes spin instead of going into a wait state" tricks again...
I discovered DECADES ago, in the Win 95 beta [aka 'Chicago'], that if you wanted to have a background process NOT eat 100% of the CPU [it was monitoring system resources like memory usage if I remember correctly], you had to enter a bonafide WAIT STATE and not just call "yield()" or some other similar function. Earlier 16-bit windows had cooperative tasking via the message loop, which avoided the problem.
With background threads (without a message loop) I especially had this same issue, as my threads that polled things would eat 100% CPU unless I forced them NOT to. Usually 'wait on a mutex' or 'wait for file I/O' was sufficient to prevent that from happening, with a slight cost in performance. You could specify a timeout on the wait so you could still poll things, too. THAT solved it, more or less.
Some time in the Windows 10 beta this problem creeped into NEARLY ALL of the TIFKAM code, or at least that's how it appeared to me when running it in a VM [in fact the TIFKAM stuff related to the Start Thing was partifularly bad about it, and several such applications appeared to actually fight one another while attempting interprocess communication]. I screamed loud about it, had arguments over why it was happening, and only deaf ears and somewhat condescending attitudes resulted.
Making the fans spin also means that laptop batteries drain unnecessarily, and that CPU clock throttling won't behave correctly. One Drive on your Mac apparently has this same problem. Maybe not all OSs or not all CPUs have this problem. But for the ones that do, it's very very very irritating.
And, from what you said, it appears as if nobody in Redmond has learned anything about such things, either
>> people failing to understand 64bit apps are actually for
At one site with a "mission critical" driver, currently 32 bit.
User often request application upgrades to 64 bit.
The matter is dropped after they learn the price of the new 64 bit version of the driver.
It has always been interesting to hear peoples ideas about what 64 bit is, why they need it.
I'm pretty sure there's a slight performance benefit to working with 64-bit values when you're running in amd64 mode, which is probably offset a bit by the fact that you HAVE to now work with 64-bit addresses. In my experience, the 64-bit executables are slightly larger and require slightly more RAM, but seem to perform [with my code, anyway] at about the same speed.
Maybe there's an algorithm or two that can significantly benefit from either 32-bitness or 64-bitness, but I haven't found it. Still, if you have a system with less than 4G of RAM on it, you're probably better off running a 32-bit OS unless you have some compelling reason not to.
And the beauty of 32-bit code is that the same binary generally runs on both the 32-bit AND 64-bit version of that OS. It makes distribution of the code a little easier.
(but I had to load 64-bit Linux on a ~4G box because things like Android Studio basically demand it nowadays...)
the problems I've seen on ARM vs x86 vs amd64 are compiler related.
As an example (for gcc anyway), the default character type is signed on x86 and amd64, but UNsigned on ARM.
Occasionally this causes problems with bit-wise operations and comparisons. Your program may no behave *exactly* the same. Similarly for 32-bit vs 64-bit, where in some cases the default size of 'int' actually makes a difference.
To fix the problem, you can try using standardized C types like 'int8_t' instead of 'char', for all variables, so that there are NO unnecessary surprises. Yeah, you might have to edit your code. A bit.
Otherwise, C is C and C++ is C++. But then again, Micros~1 doesn't JUST use C and C++ these days. They (unfortunately) have that "CLR" thing formerly known as ".Not" that (for some reason) they insist on using EVEN FOR C++, and the lingos like VB and C-pound that rely on it.
It is a fair bet that the CLR itself is ALSO a major stumbling block to ARM programs running properly, regardless of the many re-writes it's apparently undergone since TIFKAM was first foisted upon us (and ARM was proposed as a supported platform).
(and don't EVEN get me started on UWP or anything newer coming down the pike...)
ARM based Windows isn't real, it's advertising for when Microsoft needs a new PR relating to ARM, then back in the box with it. Very similar to this very Reg article trying to conceal MS advertising as news.
As for the ARM32/64 developers, how many need to rewrite, REALLY rewrite? I can see your point for more GFX oriented software (as always), but for anything else I'm essentially envisioning GIT pull followed by cmake... "Ported!"
A sync client shouldn't have to be 64-bit. But I do have to admit I was shocked when I booted up Win10 in a VM and saw all this 32-bit cruft still running at bootup, I just assumed the out-of-the-box software would all be 64-bit. Just as an FYI, a Ubuntu system out of the box has ZERO 32-bit apps or libraries. And it's not like you go to install some apps afterword and it starts pulling those 32-bit libs in either, unless you run Wine or Steam you can probably keep the system entirely 64-bit (not that it's that big a deal to have some 32-bit libs installed...)
The quickest way to end up with some 32-bit libs on there, install Steam or Wine, and they depend on a healthy pile of 32-bit libraries. Steam -- not sure, people complained in the past a few bits of the steam runtime itself may still be 32-bit, but also for running 32-bit Windows games via Proton, as well as whatever native Linux games there are in steam that are 32-bit only. For Wine, I think if you ONLY needed to run 64-bit apps you could get by without 32-bit libs; but who does that anyway?, even most 64-bit apps have a 32-bit installer.
Windows 10 version 1607. Almost 4 years ago. Though it's optional and defaults off, for compatibility with old apps that might assume the 260 limit would always be there. Link below tells you how to enable it.
Also, Windows NT has supported file names up to 32767 characters from the start, but only if the app does a bunch of horrible things. (The app has to call Windows APIs with Unicode path strings only, using absolute paths only, and it had to prefix the path with "\\?\").
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
A more important issue than - will or will Microsoft not producea 64 bit OneDrive client - is this:
When will Microsoft get it into their thick corprate skull - STOP TRYING TO FORCE IT ON TO PEOPLE!
They are OUR computers and OUR data, not yours Microsoft. Get and keep your grubby thieving hands off!
Before they make it 64-bit, maybe they could make it fucking work properly for fucks sake!
- if it comes across a 'clash', sometimes it just stops all syncing
- sometimes it even remembers to put a little cross on the cloud tray icon to tell you there's been a clash of some sort
- if you use the default to integrate into Office apps, it tries to save to the cloud first, so if you save as a different file type (such as PDF), the file just doesn't show in file explorer, until it syncs, which on a medium spec computer and 100,000 files could be several minutes if not longer
- if you delete a load of files, but your sync has stopped (because you didn't recently restart your computer and stuck to the 'fast startup' default), then start the onedrive sync later, it might decide to put all the deleted files back because I don't believe that the sync client or the OS maintain a proper journal of when things happen.
- if you dare to use the option to open a file directly from 'the cloud' and multiple people edit it, it might even not generate a clash and create two versions of the file, if your lucky.
- It might take several tens of minutes to find a change. It should know the change because the OS just did a file save.
- changes are never merged when there's a clash, despite it offering the option
- sometimes it works fine, no problem
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2021
