Pages

Jul 22, 2015

Setting memoQ to run as a 64-bit application

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
and interesting views of the working translation grid like this one:

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 


Jun 14, 2015

Introduction to memoQ in Lisbon / Introdução ao memoQ em Lisboa


From July 6th to the 11th, the summer school of the New University in Lisbon will offer a week-long introductory course for memoQ 2015, which includes:
  • 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.
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 course is open to anyone (limited enrollment, 16 persons I think) and offers 24 hours of instruction in the week. It will be taught in English with summaries in Portuguese.

A description of the course in English and Portuguese is here. I am not responsible for the errors in the English. Registration information (Portuguese only, alas) is on this page. Attendees who don't read Portuguese but manage to figure out how to register nonetheless will receive a special reward during the course.

During the week, the course is offered in the evenings, leaving the days free for work or local tourism. It is recommended that translators make a pilgrimage to the monastery named after the patron saint of translation in Belém. Miracles have occurred there, carpel-tunnel syndrome has been healed and dead text has even come to life, but not even the intervention of St. Jerome can save a machine pseudo-translation. You might learn that trick from us, however. Or not.

On August 3rd a course on project management with memoQ will be offered on a similar plan.

Jun 10, 2015

The Great Translation Rate Conspiracy in France!



The French Society of Translators (SFT) is conducting another of its periodic rate surveys. Although the American ATA treads fearfully in matters of rates, deferring to corporates who prefer to keep everyone in the dark, afraid and focused on more important matters like the Kramer vs. Kramer spectacle of TransPerfect and the latest venture capital conquests of Dopeling's Stormin' CEO, European organizations occasionally pander to the masses like the sleazy socialists we all know them to be and do these surveys that injudiciously gather and publish real data from real translators in inconvenient contradiction to the usefully manufactured figures of the Common Nonsense Advisory which aforementioned corporates employ as their rightful negotiating bludgeon to keep 'em down in The Bulk Market Bog that is the world to all those who think that translation is mostly about proZtitution for the sake of Larry the Language Lizard at thepigturd and other industrial luminaries of word sausage.

The survey from those cheese-eating surrender monkeys includes 25 questions and is expected to take 20 valuable minutes of your time which might be better spent translating political propaganda praising Robert Mugabe for Translators Without Borders for free or registering to pay Lionbridge for the privilege of receiving lowball bulk market offers to churn words into sausage to feed their better bottoms' line.

The survey is open to anyone who can puzzle out its French, and those who foolishly believe in the value of free information in a free society for free-thinking translators to make informed decisions with a knowledge of current compensation statistics can support this leftist plot by clicking the link below and not selflessly sacrificing their futures for the good of their Big Bog betters: