| Pages in topic: < [1 2 3 4] > | Czy MemoQ da się lubić? Thread poster: Tomasz Poplawski
|
|---|
Michal Glowacki 
Poland
Local time: 03:29
Member (2010)
English to Polish
+ ...
| Re: Re: 32 a 64 | Mar 13, 2013 |
Nie wszyscy o tym wiedzą
W sumie racja...
| | | | | Adresowanie 32-bitowe... podsystem dyskowy... | Mar 13, 2013 |
Michal Glowacki wrote: Z dobrym procesorem i wystarczającą ilością pamięci RAM takie zjawisko nie występuje. Tłumaczę nieraz pojedyncze pliki o objętości rzędu 300 stron, obciążone rysunkami i zdjęciami i wszystko działa płynnie. Intel Core i5, 12 GB RAM. Dzięki za uwagę, Andrzej. Ja też mam i5, choć tylko 6 GB RAM-u (1330 MHz, DDR3). (...) Może jestem w błędzie, ale nie sądzę, żeby robiło mi różnicę w tym przypadku, czy mam 6 czy 12 GB RAM-u.
To spokojnie pownno wystarczyć.
Studio to program 32-bitowy, więc i tak nie zaadresuje więcej niż 2 GB.
Można teorerycznie wymusić zaadresowanie 3 GB, ale to i tak nie ma sensu dla 99,9% programów, więc nigdy mi się nie chciało.
W życiu widziałem tylko dwa programy, które walnęły czołem o pułap 2 GB i się wywaliły.
Pierwszy to Autodesk Robot Structural Analysis (monster do obliczeń budowalnych metodą elementów skończonych) na jakimś dużym modelu, a drugi to Trados Studio przy generowaniu słownika AutoSuggest.
BTW, nowy memoQ uruchamia się teraz jako proces 64-bitowy, jeśli system operacyjny jest 64-bitowy.
Wszystko inne działa bez problemu i płynnie, tylko Trados po jakimś czasie zaczyna się zamulać. Może to kwestia podłączenia 3 większych pamięci i 6 glosariuszy (...)
Mozliwe, że to problem z podsystemem dyskowym, przynajmniej częściowo.
Jek masz poukładane bazy na dyskach?
Ale on takie wydajnościowe problemy może mieć z zasady przy bardzo dużych plikach, po prostu w odróżnieniu od programów, gdzie plik projektu jest bazą danych (np. DVX czy memoQ...) musi wszystko władować do pamięci i jeśli zaczyna swapować ciężkie megabajty, to jest kanal.
Ilość fizycznej pamięci ma pewien wpływ na sposób zrzucania do pliku wymiany, ale to nie jest parametr krytyczny.
Ja mam 12 GB i też się czasem dusi.
Bo Trados po prostu się będzie czasem dusil na niektórych plikach i tyle, bo taką ma koncepcję danych, a zapisywanie SDLXLIFF będzie trwało nieprzyzwoicie długo w odróżnieniu od systemów tranaskcyjnych typu DVX czy memoQ, które to robią w locie przy każdej zmianie segmentu.
M.in. właśnie to zapisywanie przez wieki mnie tak do pasji doprowadza, że absolutnie wszystkie pliki Studio, które dostaję tłumaczę w DVX, jedynym wyjątkiem jest korekta.
Poza tym, jeśli mogę przy uruchomieniu wszystkich programów (za wyjątkiem Thunderbirda, ale z uwzględnieniem memoQ) odpalić także dość zasobożerną grę, to Trados tym bardziej powinien sobie radzić.
Jest, ehm, liderem na rynku, to se może nie radzić, ludzie i tak to kupią 
PS
Pliki trzymasz w LAN czy lokalnie?
Praca przez LAN nigdy nie była dobrą stroną Tradosa, niektóre operacje mogą być nawet o dwa rzędy wielkości wolniejsze.
Zdrówkot
GG
| | | | Michal Glowacki
Poland
Local time: 03:29
Member (2010)
English to Polish
+ ...
| Dyski i inne | Mar 13, 2013 |
Jek masz poukładane bazy na dyskach?
Wszystkie zasoby dla Tradosa, memoQ i inne są na partycji C, tak samo jak wszystkie programy. Dysk klasyczny, 7200 obr./min.
M.in. właśnie to zapisywanie przez wieki mnie tak do pasji doprowadza, że absolutnie wszystkie pliki Studio, które dostaję tłumaczę w DVX, jedynym wyjątkiem jest korekta.
O ile otwarcie Tradosa samego nie zajmuj tak dużo, jak niektórzy mi donosili, to faktycznie zapisywanie plików jest czasochłonne. Robię to samo, ale z memoQ.
Ale on takie wydajnościowe problemy może mieć z zasady przy bardzo dużych plikach (...)
Cała paczka ma 11,2 MB, a sam plik źródłowy ok. 2,5 MB. Jedyne co, to odwołania do jakiś szablonów, których nie mam na dysku, co wydłuża czas jego otwarcia w Wordzie. Plik stworzony w AuthorIt.
Pliki trzymasz w LAN czy lokalnie?
Wszystko jest lokalnie na dysku.
Dodam, że choć memoQ do idealnych nie należy, to nigdy nie sprawia mi takich problemów. Przez jakiś czas wyrzucał błędy przy korzystaniu ze skrótów klawiaturowych do filtrowania zawartości, ale poza tym to działa bezbłędnie. Nie jestem jakimś zaciekłym przeciwnikiem Tradosa, ale znacznie bardziej wolę memoQ, bo wiem, że mogę po prostu pracować i nie przejmować się niczym poza samym tłumaczeniem.
Pozdrawiam,
Michał
| | | | | 4 GB RAM i więcej | Mar 13, 2013 |
Michal Glowacki wrote: System operacyjny 32, czy 64 bit? Zaskakuje mnie to pytanie  32-bitowy Windows nie obsługuje więcej niż około 3,2 GB, więc wkładanie większej pamięci nie miałoby żadnego sensu.
To nie do końca prawda, bo:
- to zależy od chipsetu/biosu, np. notebooki serii X60 czy T60 Lenovo zobaczą najwyżej 3 GB, większość komputerów rzeczywiście 3,25 GB, ale są też takie, co widzą 3,5 GB lub nawet więcej, ale to już zwykle wyspecjalizowane chipsety serwerowe.
- niektóre 32-bitowe serwery Windows (od Enterprise w górę) widzą nawet ponad 4 GB pamięci fizycznej tj. w Windows 2003 do 64 GB, o ile pamiętam (tak, wiem, że tu się czepiam, bo normalny człowiek nie ma w domu Enterprise...)
Zdrówkot
GG
| | |
|
|
|
Michal Glowacki
Poland
Local time: 03:29
Member (2010)
English to Polish
+ ...
| Czepianie się ;) | Mar 13, 2013 |
(...) tu się czepiam (...)
Otóż to
Michał
| | | | | Nie wszystkie jajeczka do jednego koszyczka... | Mar 13, 2013 |
Michal Glowacki wrote: Jek masz poukładane bazy na dyskach? Wszystkie zasoby dla Tradosa, memoQ i inne są na partycji C, tak samo jak wszystkie programy. Dysk klasyczny, 7200 obr./min.
No to stawiałbym prowizorycznie na to.
Spróbuj wrzucić do testów jakieś bazy na dysk USB lub szybkiego pendrajwa.
To ograniczy ruchy głowic na C: i powinno przyśpieszyć.
Jak zadziała, dołóż drugi dysk fizyczny, a potem trzeci
To taka podstawowa zasada optymalizacji dostępu do baz danych na klasycznych dyskach mechanicznych.
Im więcej niezależnych głowic, tym lepiej wymiata.
Ja mam bazy read only lokalnie na oddzielnym dysku fizycznym (nie na C:, to byłoby pierwsze wąskie gardło ze względu m.in. na swap...), a bazy do zapisu i projekty na sieci (RAID) po gigabitowym Ethernecie.
Trochę przez ten LAN zwalnia, ale dzięki DVX mogę współdzielić takie bazy z żoną lub np. otworzyć ten sam projekt na dwóch komputerach.
Wrócę do tematu później...
Zdrówkot
GG
[Edited at 2013-03-13 14:06 GMT]
| | | | Michal Glowacki
Poland
Local time: 03:29
Member (2010)
English to Polish
+ ...
Dzięki za uwagi!
Spróbuj wrzucić do testów jakieś bazy na dysk USB lub szybkiego pendrajwa.
Muszę spróbować, zdecydowanie.
Jak zadziała, dołóż drugi dysk fizyczny, a potem trzeci
W obecnej konfiguracji jest to raczej niemożliwe, bo pracuję z laptopa, do którego podłączam monitory itd. Następna maszyna to będzie pewnie już kombinacja SSD i HDD albo tylko SSD, zależnie od tego jak to się będzie rozwijać. Powinno pomóc.
Pozdrawiam,
Michał
| | | | Andrzej Lejman
Poland
Local time: 03:29
Member (2004)
German to Polish
+ ...
Rzeczywiście, sporo na pewno zależy od konfiguracji, wydajności itp. dysków.
Wcześniej pracowałem na laptopie z dwoma tradycyjnymi dyskami, nie było źle, ale czasem czekałem nieznośnie długo np. na zwykle rozwinięcie menu po kliknięciu pliku.
Potem zmieniłem dysk systemowy na SSD i różnica była widoczna natychmiast. Żadnych opóźnień, mulenia, nic.
Teraz mam dysk tradycyjny, ale z buforem SSD 24 GB (układ fabryczny) + drugi na karcie pa... See more Rzeczywiście, sporo na pewno zależy od konfiguracji, wydajności itp. dysków.
Wcześniej pracowałem na laptopie z dwoma tradycyjnymi dyskami, nie było źle, ale czasem czekałem nieznośnie długo np. na zwykle rozwinięcie menu po kliknięciu pliku.
Potem zmieniłem dysk systemowy na SSD i różnica była widoczna natychmiast. Żadnych opóźnień, mulenia, nic.
Teraz mam dysk tradycyjny, ale z buforem SSD 24 GB (układ fabryczny) + drugi na karcie pamięci 4 GB (większa karta nie ma sensu, bo i tak adresuje tylko ok. 4 GB).
I jak pisałem wcześniej, wszystko śmiga bez problemu. A zapisanie nawet dużego pliku w Studio to kilka(naście sekund), więc chyba to nie jest problem?
Pozdrawiam
A. ▲ Collapse
| | |
|
|
|
Michal Glowacki
Poland
Local time: 03:29
Member (2010)
English to Polish
+ ...
Ja planuję taki sam układ, ale mój laptop jeszcze nie dożył końca, poza zwalnianiem Tradosa przy dużych plikach nie wykazuje żadnych oznak starzenia. U mnie zapis też trwa od kilku do kilkunastu sekund - może to nie problem, ale jest to irytujące, jeśli chcę często zapisywać plik. Wszystko inne śmiga bez problemu.
Biorąc pod uwagę to wszystko - cały czas wolę memoQ, bo z nim nie trzeba się zastanawiać, czy następnym razem nie lepiej pójść w SSD ... See more Ja planuję taki sam układ, ale mój laptop jeszcze nie dożył końca, poza zwalnianiem Tradosa przy dużych plikach nie wykazuje żadnych oznak starzenia. U mnie zapis też trwa od kilku do kilkunastu sekund - może to nie problem, ale jest to irytujące, jeśli chcę często zapisywać plik. Wszystko inne śmiga bez problemu.
Biorąc pod uwagę to wszystko - cały czas wolę memoQ, bo z nim nie trzeba się zastanawiać, czy następnym razem nie lepiej pójść w SSD Śmiga, nie wymaga zapisywania plików i jest dużo łatwiejszy w obejściu.
Pozdrawiam,
Michał ▲ Collapse
| | | |
Andrzej Sawicki wrote: Z tego, co znam -- Trados 2007, Studio 2011, IBM TM, Idiom Workbench, Google, Passolo, Tstream Editor, SDLX, Excel -- MemoQ ma najmniej wnerwiających niedoróbek i bardzo dobrą widoczność elementów pomocniczych. Nie jest idealny, ale co najmniej warty poznania na poważnie.
W moim pojęciu memoQ to najpiękniejsza rzecz, jaka się pojawiła w oprogramowaniu CAT od jakichś 10-15 lat tj. od DV3/DVX.
Niezależnie od jego wielu plusów (szczególnie interfejs użytkownika jest bardzo przemyślany, bo go robili prawdziwi tłumacze dla tłumaczy, a nie programiści dla projektmenażerii) czy różniastych minusów, to właśnie memoQ i jego szybki wzrost sprawił, że znalazł się wreszcie kij na tradosowy ryj.
Tj. Trados poczuł oddech konkurencji na plecach i zaczął się starać.
Tzn. zaczęli słuchać ludzi, a nie olewać ich jak zwykle, bo się zorientowali, że to już nie przelewki.
Np. sporo opcji w Studio 2011 np. rozbudowane filtrowanie wg statusu czy przez lata postulowane rozpoznawanie 2-literowych terminów to właśnie wpływ memoka.
Złośliwi mówią, że nawet Ctrl+Enter od niego wzięli
Reasumując, bardzo szybki rozwój, bardzo dobry stosunek ceny do jakości, np. kilka opcji dostępnych w Tradosie tylko za dopłatą (generator słownikow typu AutoSuggest tj. Muses, ekstrakcja terminologii, brak ograniczeń co do liczby języków w wersji podstawowej itp.), dobry serwis techniczny.
Ja oczywiście dalej siedzę na DVX2, ale jeśli mam wybór, zwykle wolę do preprocessingu czy QA użyć mQ niż Tradosa, jeśli coś w DVX2 jest trudne do zrobienia.
Zdrówkot
GG
| | | | | Wydajność dysków... | Mar 16, 2013 |
Andrzej Lejman wrote:
Rzeczywiście, sporo na pewno zależy od konfiguracji, wydajności itp. dysków.
Właśnie wczoraj dołożyłem sobie dysk SSD na bazy read-only, a z nieużywanej pamięci zrobiłem spory ramdysk na bazy referencyjne.
Jeśli czas pozwoli (trzy tygodnie temu mi się spalił stary komputer tzn. karta graficzna i nie wiem, co jeszcze, ciągle mam efekty uboczne...), to może trochę potestuję porównawczo...
Pierwsze, dość oczekiwane spostrzeżenie, jednoczesny zapis i odczyt z mechanicznego dysku sieciowego (przez gigabitowy Ethernet) z dwóch róznych komputerów daje z 10 (dziesięć) razy niższe transfery niż sam odczyt z tego dysku sieciowego z zapisem na jeden lokalny SSD (na poziomie 30-35 MB/s).
Przy docelowym mechanicznym byłoby to rzędu 15-20 MB/s, ale i tak widać, że na dyskach mechanicznych ostra wielozadaniowość praktycznie zabija wydajność.
Zdrówkot
GG
[Edited at 2013-03-17 11:28 GMT]
| | | | Tomasz Poplawski
Local time: 20:29
Member (2007)
English to Polish
+ ...
TOPIC STARTER | No chyba trochę odeszliśmy od tematu... | Mar 17, 2013 |
.. w Ezoterykę przez duże Ezo.
Choć właściwie to mi nie przeszkadza
| | |
|
|
|
| Skalowanie... | Mar 20, 2013 |
Tomasz Poplawski wrote: .. w Ezoterykę przez duże Ezo. Choć właściwie to mi nie przeszkadza
Nie chce mi się naprawdę wchodzić w szczegóły, ale takie problemy wydajnościowe to, przynajmnej częściowo, efekt tego, że ludzie się nie przeskalowali i myślą ciągle w kategoriach starego Dziadosa, małych baz i małych dokumentów po 50-100 kB, tak gdzieś z 10 lat do tyłu.
Tzn. jeśli te 10 lat temu 100 000 jednostek to była duża baza, ale technologia nadążała, lecz jeśli kumpel miał wtedy pół miliona, to już to czuł.
I ten problem dotyczy też, a może nawet zwłaszcza, twórców oprogramowania, oni w korporacyjnej prostotuszności sobie nawet nie wyobrażają, jak wielkie bazy miewają frilansi, więc rzadko testują wydajność na takich bazach.
Kiedyś miałem tu dyskusję, do której się włączył szef zespołu Multiterma, mówiąc, że przy dużych bazach rzęd 100 000 jednostek to cos tam, coś tam, na co mu odpowiedziałem, że moja największa baza Multiterma, którą dostarczył klient, miała prawie milion jednostek.
Ta baza po prostu, mówiąc po ludzku, nie działała, bo czas reakcji dochodził do 20 sekund i więcej.
Próbowałem toto skonwertować z formatu MT5 na MT7, bo w MT7 jednak indeksowanie jest lepsze, ale proces ubiłem po 5 (pięciu) dniach, bo deadline się zbliżał.
Swoją drogą, DVX to samo załatwił jakoś w jedną noc czy podobnie.
Mój standardowy zestaw baz TM w parze FR-PL ma teraz jakieś 2 miliony jednostek i to już w żaden sposób nie zadziała przyzwoicie na standardowym notebooku z dyskiem mechanicznym, choćbym zarżnął czarną kozę, ofiarował programistę Multiterma według mody z Tollund i splunął przez lewe ramię.
Coś trzeba zmienić, a co konkretnie, to już zależy od przypadku.
Wracając do tematu, memoQ na pewno będzie się zachowywał lepiej na dużych projektach, zwłaszcza jeśli zawierają setki małych plików.
Bo oni się przeskalowali z myślenia na poziomie osobnych dokumentów na myślenie globalne w kategoriach projektu, jak w DVX, i system nie musi trzymać w pamięci niepotrzebnego śmiecia takiego jak szkielet pliku SDLXLIFF.
Tzn. ten "śmieć" jest potrzebny przy eksporcie, ale przy samym tłumaczeniu jest absolutnie zbędny.
A może ważyć bardzo dużo.
PS
Robiłem wczoraj w Studio pretranslację pliku wygenerowanego z TTX (niecałe 3 MB w TTX, ponad 6 MB w SDLXLIFF), przez LAN.
Baza praktycznie pusta, opcja Copy source to target włączona.
Trwało to z pół godziny.
Dokładnie to samo w DVX trwało kilkanaście sekund, bo zamiast pisać w dokumencie po kolei wiersz po wierszu, wykonał prostą operację bazodanową.
memoQ miałby podobnie.
Zdrówkot
GG
| | | |
Grzegorz Gryc wrote:
W moim pojęciu memoQ to najpiękniejsza rzecz, jaka się pojawiła w oprogramowaniu CAT od jakichś 10-15 lat tj. od DV3/DVX.
Chyba masz rację, Grzegorz. Dzisiaj pobrałam wersję 45-dniową Memoqa i po 5 minutach stwierdziłam, że to proste jak budowa cepa. Od razu przekonałam się do tego kota (a Studio 2011 nadal mnie osłabia).
[Bearbeitet am 2013-03-21 18:17 GMT]
| | | | Tamod
Poland
Local time: 03:29
Polish to German
+ ...
| MemoQ i szybkość | Mar 28, 2013 |
Miałem ostatnio możliwość przetestować MQ. Zdziwiłem się szybkością z jaką pracuje (Trados i Across wymagają znacznie więcej miejsca i większej ilości RAMu). Na stronie producenta filmy instruktażowe, instalacja w kilku językach, ale później menu zmienia się na polski. Logicznie poukładane, różne możliwości filtrowania, szybko można się przestawić na nowy program.
MemoQ da się rzeczywiście lubić.
| | | | | Pages in topic: < [1 2 3 4] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Czy MemoQ da się lubić? | Protemos translation business management system | Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!
The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.
More info » |
| | Trados Business Manager Lite | Create customer quotes and invoices from within Trados Studio
Trados Business Manager Lite helps to simplify and speed up some of the daily tasks, such as invoicing and reporting, associated with running your freelance translation business.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
