It has been so long now since 64-bit versions of the Windows operating system were introduced, allowing access to more RAM and adding other efficiencies to the systems we use. So imagine my surprise today when, after a recent memoQ build upgrade, all Hell broke loose in the midst of a time-critical project, with crashes every five or ten minutes
Of course all this happened as I was doing a time-critical translation, dictating at top speed to meet a tight deadline for a last-minute legal matter.
So I send a quick cry for help to support@kilgray.com, and in a short while I got a question back, asking whether I was running in 32-bit or 64-bit mode. "What a silly question," I thought. "64-bit, of course!" Wrong, actually.
I don't know why, but it seems that memoQ upgrades are currently configured to run in 32-bit mode. And depending on what kind of work you are doing, that can have unfortunate results. Working with my version of Dragon NaturallySpeaking today it was an absolute disaster that caused me to lose half my working time and sweat buckets right up to the delivery.
There are two executable files for memoQ in the program folder: MemoQ32.exe and MemoQ.exe, the former obviously for 32-bit systems and the latter not-so-obviously for the more typical 64-bit systems for our times.
I checked the properties of the shortcut I use to launch memoQ
and 'shore 'nuff
there was the problem. So I edited the "target" field, which tells the shortcut what to run:
and lived happily ever after for the rest of the afternoon. The worst problems I have seen with a CAT tool for a decade were resolved.
"But how do I know if I have a 32-bit or a 64-bit Windows operating system," you might ask. Good question. Most translators answer this by disemboweling a black chicken and examining its entrails, but being an advocate of better treatment for animals, particularly oppressed chickens, I researched a better way.
The answer can also be found in the Windows Control Panel in the System control. The screenshot from my Windows 7 Ultimate version is shown above; other versions may have a slightly different display, but the System control is where you should look in any case.
*******
P.S. - In my correspondence with Kilgray Support, the engineer helping me had suggested a one-off start of the memoQ.exe application (64-bit memoQ) from the program folder. I thought this was a bit of a hassle, and I questioned why he would propose such a thing and why the 32-bit application would be a default now. I received this response:
" ... this is by design: by default memoQ will start in 32-bit mode to ensure better startup and better user interface performance. But you can start memoQ 2014 R2 or memoQ 2015 in 64-bit mode, which is useful for heavy operations which requires several gigabytes of RAM."
All very well and good... those who do mostly lightweight stuff can go for the default and perhaps have a special shortcut for the "heavy lifting" memoQ version. The problem I see is that most users are not going to know what sucks up a lot of system capacity and may require the 64-bit application.
I suspect that large TMs or other big resources, things like predictive typing (commonly in use) and certainly the use of speech recognition software is going to make a crunch. I am unaware of any discussion (to date) which is publicly accessible, which will make clear the line that is crossed to require more memory access. Most of the professionals I know tend to use memoQ in a rather resource-intensive way, and I am unclear what the recommendations should be here.
P.S. #2 - Kilgray responds to questions on 64-bit versus 32-bit on the Yahoogroups forum: https://groups.yahoo.com/neo/groups/memoQ/conversations/topics/41676. Due to access difficulties with Yahoo's sucky Neo interface, some of the message thread is included here:
Dear All,
I'll try my best to clarify how memoQ relates to 32-bit and 64-bit.
1. Use 64-bit if you expect "heavy" use
memoQ is a "hybrid" application that was designed (at least from maybe version 6) to run in 64-bit mode on a 64-bit system and 32-bit on 32-bit systems. The support for 64-bit mode was added to avoid out of memory issues with "heavy" use, like importing very large documents. (I clearly remember that one of the use cases was importing large FrameMaker documents. Most probably the other most significant use case was memoQ server in general, which, depending on how it is used by how many people, may have to do many things at once and load an enormous amount of resources.)
A 32-bit application is limited to 2 GB of memory regardless of how much memory is available on the system, while a 64-bit application is practically umlimited (technically there is a limit, but it is enormous). One could argue that 2 GB of memory use is not likely in memoQ anyway, but actually there can be short spikes, during document import or when loading a translation memory, for example. There are also further details that complicate this, like memory fragmentation which are frankly too technical for me, but, as far as I understand, they mean that an "out of memory" error is still possible when there seems to be enough memory overall, but not enough "continous" memory for a specific operation.
These kinds of issues are rare in 64-bit operation and more common on 32-bit operation. This means that with 64-bit memory. This means that with 64-bit memoQ you are less likely to get out of memory errors. Use 64-bit memoQ if you expect "heavy" usage or if you have run into out of memroy errors. If you have, the error message displayed by memoQ most probably already advised you to go 64-bit.
2. memoQ is 32-bit is more snappy
Most modules of memoQ are based on the .NET framework and is written in "managed code" that runs under the Common Language Runtime of the .NET Framework. Sorry if this is too technical, but the point is that memoQ itself is (mostly) intermediary code that must be "translated" (compiled) to code that a computer can actually execute, right when the program modules are loaded to memory. The piece of software that does this compilation is called the Just In Time (JIT) compiler. It is the JIT compiler that creates either 64-bit or 32-bit machine code, as required.
The JIT compiler in recent versions of the .NET Framework simply performs way worse when creating 64-bit code than 32-bit code. (Most probably the compilation itself is slower on 64-bit than 32-bit, or it is possible that there are performance issues with the resulting "machine code" itself.) This is a widely known problem, and Kilgray has done elaborate research to confirm that this is why memoQ starts up slower (by approximately 100%) in 64-bit mode than 32-bit mode. It is also likely that some of the interface is also slower in 64-bit than 32-bit. We are also convinced that this was a very signifcant issue to the user base, and has led to unfavourable comparisons to the competition (which I think is at a dubious advantage here in the sense that they don't offer a 64-bit mode, as ar as I know). The good news is that Microsoft has been working on the problem and they have created a brand new JIT compiler for version 4.6 of the .NET Framework. So whenever memoQ gets upgraded to .NET 4.6, 64-bit will see a performance boost.
It is a myth that 64-bit most always perform better, and in the case of .NET (before version 4.6), clearly the opposite is true, at least in terms of loading and "JIT compiling" program modules. This can heavily affect startup times, for example.
Best regards,Gergely
I left out the part that is (hopefiully) obvious by now to many of you, and something I have explained here before, maybe twice or more:
As an answer to the performance (especially startup speed) concerns, in recent builds of memoQ, we turned off the autoamtic "hybrid" behaviour that detected the 32 or 64 bitness of the system, and created a separate 32-bit executable (and a start menu/screen shortcut) to start memoQ with. With this you can force memoQ to run in 32-bit mode. This is also the default in the sense that if you just click "memoQ" in your start menu/screen. you start the "forced" 32-bit mode. There is also a "memoQ (x64)" shortcut you can click to enable 64-bit mode on 64-bit systems.
Also, another piece of advice: for users with beefy systems the perforamnce degradation caused by the 64-bit JIT compiler may be completely irrelevant, as memoQ may start up for you in maybe four seconds instead of two. If you have such a machine, 64-bit might be a very good choice. And you get some protection from "out of memory" issues.
Another piece of advice: please don't switch to 64-bit mode if you do not have a beefy system and you are not having any issues with memory use. This might just slow your copy of memoQ down with no benefit in your specific case. Switch to 64-bit if you know you are affected by "out of memory" issues, or you expect some heavy use (very large resources or translatable files, etc).
Gergely
Message 3 of 3 , Today at 12:49 PM
"It is a myth that 64-bit most always perform better, and in the case of .NET (before version 4.6), clearly the opposite is true"
Really glad that, despite this, Kilgray kept the 64-bit support. The 32-bit version caused out of memory errors for most of our translators after ~15-30 minutes of use, causing a lot of confusion after 2015 hit, until we found the 64bit version :D
wolfschoe
