GIMP gardzi naszymi procesorami
Taki smutny wniosek nasunął mi się ostatnimi czasy podczas intensywnego wykorzystywania pluginów GIMP’a. O ile wcześniej na procesorze z dwoma rdzeniami machnąłem na to ręką, o tyle na procesorze którzy posiada tych rdzeni cztery (i po dwa wątki na każdy), wprawiło mnie to w zakłopotanie. Siedząc z brodą opartą na dłoni przeliczałem sobie w pamięci jak to by szybko było, gdyby GIMP jednak użył tych wszystkich rdzeni. Ale nic z tego, monitor zasobów oraz top uparcie wskazywało stu-procentowe wykorzystanie tylko jednego z nich. Poszperałem, pogrzebałem, w końcu program jest aktywnie rozwijany, na pewno w tej materii coś się zmienia (bo w ilości wykorzystywanych rdzeni ustawianych w preferencjach programu już nie wierzyłem).
Z nowości w nadchodzącej stabilnej wersji 2.7.X na pierwszym miejscu stawia się sprowadzenie interfejsu GIMP’a do jednego okna. A GEGL’em (który teoretycznie powinien usprawnić wykorzystanie zasobów) podąża sobie swoją ścieżką rozwoju i nie zapowiada się na rewolucję zbyt wcześnie (a przynajmniej tę rewolucję przesłania sukces jedno-okienkowego interfejsu). Niestety, kolejny element układanki GNU stawia na wygląd, zamiast na powalenie swoją sprawnością obliczeniową. Nie jest to pierwszy przypadek, a wręcz plaga ostatnio powstających programów – ‘skoro nie działa jak powinno, niech przynajmniej ładnie wygląda’ (znacie?) Mnoży się ‘śłitaśne’ ikonki, przyciski, animacje i inne śmieci na potrzeby turystów systemowych, a człowiek próbujący pracować dostaje obietnice na najbliższą dziesięciolatkę.
Na szczęście, nie jest to reguła. Ale niech ktoś wskaże zamiennik GIMP’a. Ja nie wątpię w rozwój tego programu. Ale przy takim rozłożeniu priorytetów, nim GIMP usprawni obsługę gospodarowania zasobami, procesory z kilkoma rdzeniami wyjdą z użycia. A zwolennicy Photoshopa, jak utyskiwali na interfejs, tak teraz będą narzekać na wydajność.
10 komentarzy
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
A czy ustawienie w opcjach w zakładce środowisko Wykorzystanie zasobów ilość wykorzystywanych procesorów na 4 nie pomaga?
Obecnie GCC wspiera możliwość automatycznego rozłożenia obliczeń na wiele rdzeni. Jednak należy spojrzeć na to z tej strony, że nie tylko tym kompilatorem może zostać skompilowany GIMP. Byłoby jednak świetnie, gdyby twórcy GIMP-a sprawdzili dostępność odpowiednich, predefiniowanych makr, a w razie ich braku zadeklarowali makra, co nic nie zmieniają.
Mnie zaś uderza trafne i zbieżne z moim spostrzeżenie, że coraz więcej “pary idzie w gwizdek”, to jest robienie cudownych ikonek, wirujących dupereli i innych upiększeń, zaś cała sfera dobrego programowania, optymalizacji i dopieszczania ważnych funkcji programów leż odłogiem.
Może to dla tego, że byle motyw może machnąć każdy? Nowa i kona, nowa skórka to przecież tylko kilka słów wklepanych w google -> “tworzenie przycisków w stylu web 2”, upiększanie motywów Ubuntu bla, bla.
Szkoda – bo dla doświadczonego użytkownika ważne jest nie tylko to “jak wygląda”, ale przede wszystkim – “jak działa”.
@golem14
Ja coraz częściej odnoszę wrażenie, że developerzy oprogramowania/rozwiązań dla Linuksa nie wierzą w to, że ktoś próbuje za pomocą tego systemu najnormalniej pracować (oczywiście pomijam rozwiązania serwerowe). Stąd po macoszemu są traktowane takie rzeczy jak optymalizacja użytkowania zasobów, optymalizacja UI programów i ogólnej komunikacji systemu z użytkownikiem.
Sytuację na pewno poprawiłby komercyjne rozwiązania dla konkretnych dziedzin. Ale ich potencjalni twórcy też utkną na etapie dystrybucji paczki, ew. zmian w kernelu/bibliotekach pobocznych, itp.
dziwicie się? dzisiejsze pokolenia wychowane na językach typu .net i python, ide typu visual studio czy borland w których tworzy się szybko aplikacje bez zagłębiania się w szczegóły po prostu skupia się na tym co znają…. na gui a nie bebechach….
Zrównoleglanie algorytmów do obróbki grafiki nie jest znów tak trywialne. I za całą pewnością na nie wiele zdadzą się tu opcje kompilatora. Nawet bardziej wyszukane modele programowe też nie zawsze ułatwiają sprawę. Słowem, programowanie równoległe, ani łatwym, ani automagicznym sposobem nie wychodzi za bardzo. Choć prawdą jest, że większość tych algorytmów daje się zrównoleglić w przyzwoity sposób.
BTW Się przekonałem ostatnio, że ten cudowny Gimp nie obsługuje żadnego przyzwoitego formatu zapisu bezstratnego z danymi EXIF. #*#$ Mam trochę zdjęć z komórki z danymi GPS w środku, jednakże ze względu na kiepską jakość muszę je edytować w dwóch różnych programach. Oczywiście narzuca się tu tiff jako format pośredni. Niestety tiff nie zachowuje EXIF więc kiedy sobie wyedytuje plik do końca i stworze jpga to nie mam tam już żadnych cennych danych. Bolesne, jeśli nadpisze się wynikowy plik na źródłowym (lub go wykasuje). Kolejny kamyczek do ogródka.
Dobry interfejs to nie sa ladne ikonki i animowane progresbary, to funkcjonalnosc. Stworzenie przyzwoitego UI dla gimpa jest naprawde szczytnym celem. Na razie, abstrahujac od innych jego ulomnosci, “dzieki” swojemu bezmyslnie zaprojektowanemu UI to program dla przypadkowych uzytkownikow.
A alternatywy nie ma. Profesjonalnie uzywa sie photoshopa i paintera, przy obnizeniu wymagan ew. paint shopa i elements, bo to dziala jak powinno. I tyle. Jak ktos musi uzywac tego typu softu non-stop, a nie po 2h na miesiac, to nie bedzie sie zastanawial, tak jak zawodowy pilkarz sie nie zastanawia, czy grac na bosaka czy jednak sie szarpnac na przyzwoite buty.