Another year's over, my friend,
and once again fools can pretend
that Translations with Borders
of quite simian orders
didn't MpT heads to no end.
An exploration of language technologies, translation education, practice and politics, ethical market strategies, workflow optimization, resource reviews, controversies, coffee and other topics of possible interest to the language services community and those who associate with it. Service hours: Thursdays, GMT 09:00 to 13:00.
The beautiful Manchester Central Library, venue for the EC tender workshop! |
Content of a test corpus before a stub document was added. Viewed in the Resource Console. |
The test corpus with the document list shown in my project; only the stub document is displayed, but all the indexed content shown above is also available in the Concordance and Translation Results. |
Content copied from the memoQ preview: the red box is placed at the currently selected segment. |
" ... 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."
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
The course will be taught by me an Professor David Hardisty, with whom I have spent most of this year so far exploring innovative speech recognition and editing workflows, which will also be an important part of this course. It's a pleasure to work with David, because not only does he have a strong commitment to the success of his students, but he has a marvelous talent for taking my concepts and recasting them in a way that work really, really well for undergraduate and graduate students at all levels.
- The functional modules of the memoQ translation environment and how these work together;
- Common workflows for translation and editing tasks;
- Making use of legacy translations and data from other environments;
- Collaboration with users of other translation environments (SDL Trados Studio, OmegaT, etc.);
- Tips for problem-solving and added value for translation customers.
RIP Chris Irwin, a friend and example to many |