О 64-битном Photoshop

Примерно неделю назад было довольно много шума из-за того, что Adobe заявили, что следующая версия Adobe Creative Suite 4 выйдет в 64-битной версии для Windows, а для Мака 64-битность наступит только в следующей версии, в CS5 (и когда она выйдет, естественно, никто не может сказать). Многим пользователям этого хватило в качестве повода забеспокоиться, что Adobe собирается “забросить” разработку под Mac, раз уж “самые современные разработки человечества” будут игнорировать эту платформу. Однако, это на самом деле не так, и к тому же “слухи о полезности” 64-битности несколько преувеличены.
Давайте вначале разберемся почему Adobe вдруг решила “пропустить ход” и подождать до версии выпуска версии CS5. Все дело — в “углероде”, а другими словами — в Carbon. Нет, вовсе не в Need for Speed Carbon, в который играли разработчики Adobe, и поэтому пропустили все сроки выпуска приложения. Carbon — это набор системных вызовов, который используют приложения, запускаемые на Mac OS X. Но не все приложения — а в основном те, которые пришли к нам из “классической” Mac OS.

Когда начался переход с Mac OS 9 на Mac OS X, разработчики приложений заявили Apple, что они не готовы выпускать свои программы для Mac OS X путем полного переписывания их на Cocoa — это еще одна среда для запуска приложений, которая в Mac OS X пришла из NeXT. А поскольку времена для Apple тогда были плохие, то компания не могла “разбрасываться” разработчиками, и пошла им на уступки. Набор системных вызовов из Mac OS 9 (и предыдущих версий “старой” Mac OS), который носил название ToolBox, был портирован на Mac OS X и получил название Carbon — углерод, благодаря которому существует жизнь. Так и благодаря Сarbon на Mac OS X смогли начать работать приложения, написанные для предыдущей версии Mac OS — с небольшими доработками (чтобы хоть как-то работать) или с основательной доработкой (чтобы нормально работать). Альтернативой было только переписывание приложений на Cocoa с практически нуля, что в условиях непредвиденного будущего Apple мало кто мог себе позволить в 2000 году.
Для кросс-платформенных приложений, таких как Photoshop, Google Earth или Maya, Carbon вообще оставался практически единственной возможной альтернативой, при которой можно было продолжать разрабатывать приложения для нескольких платформ сразу. Правда, выпуск по-настоящему красивого “маковского” приложения на Carbon требует бОльших усилий, чем на Cocoa.
Теперь о 64-битности. Для большинства пользователей 64-бита — некая магическая величина, в случае которой настанет как минимум двоекратное увеличение производительности, а также мир во всем мире. Однако это не совсем так. В первую очередь поддержка 64-битности в операционной системе означает возможность этой системы доступаться к более чем 4ГБ оперативной памяти и, соответственно, обрабатывать большие массивы данных.
Mac OS X, начиная с версии 10.4, стала потихоньку “перебираться” в 64-битность, сначала предоставляя возможность работать с 64-битными массивами на уровне приложений в командной строке. А на конференции разработчиков WWDC в 2006 году Apple заявила, что в Mac OS X 10.5 64-битность выйдет на новый уровень, и будет поддерживаться в API для приложений — в Carbon и Cocoa, что, собственно, открыло дорогу для разработки приложений с графическим интерфейсом, использующими 64-битность. “Ура!”, кричали программисты, и в воздух чепчики бросали. Однако, праздник длился недолго.

Уже через год, на следующей конференции WWDC 2007, Стив Джобс, рассказывая о задержке выхода Mac OS X 10.5 и о ее новых возможностях, в своей презентации показал, что одной из новых возможностей будет являться поддержка 64-битности в Cocoa, а вот Carbon куда-то из презентации Джобса подевался. И тут подозрение разработчиков на Carbon их не обмануло — когда они стали выяснять, случайно ли пропал Carbon из презентации Джобса, оказалось, что неслучайно. Apple действительно в последний момент “выбросила” поддержку 64-бит из Carbon для финальной версии 10.5.
Сказать, что это был неприятный сюрприз для программистов Adobe — это не сказать ничего. Они ведь об этом узнали точно так же, как и все остальные — из презентации Джобса. А до нее они, выпустив CS3, занимались его портированием для 64-бит, используя предварительные версии 10.5, в которых поддержка 64-бит в Carbon еще была. Честно говоря, я удивляюсь, как Adobe до сих пор не хлопнула дверью перед Apple, после всех пертурбаций последнего времени.
Вначале это был переход с “классической” Mac OS на Mac OS X, при котором Adobe пришлось попотеть, чтобы выпустить вначале Photoshop, а затем и CS для новой системы — Adobe была практически последней компанией, выпустившей свои программы для Mac OS X. Затем Apple “обрадовала” всех разработчиков переходом на Intel-процессоры, при котором Adobe пришлось не только переделывать поддержку архитектуры, но и менять инструменты разработки на Xcode. И вот теперь — новый сюрприз: чтобы Photoshop заработал в 64-битном режиме на Mac OS X, нужно выбросить бОльшую часть Сarbon-кода, и переписать его на Cocoa.
Нет, конечно, на самом деле понятно, почему Adobe до сих пор терпит эти приколы Apple — практически 40% продаж Adobe идут от версий их продуктов для Mac OS X, и так взять и избавиться от этих продаж ни один акционер компании не позволит. Да и Adobe надо было давно понять, что у Carbon нет большого будущего, и Apple вряд ли долго будет его развивать и поддерживать, и начать постепенную миграцию в сторону Cocoa.
Но с другой стороны, винить только Adobe не стоит — Apple тоже хороша. По большому счету, “слив” 64-битного Carbon из релиза 10.5 произошел из-за задержек в разработке 10.5 и переносе даты выпуска с июня на октябрь. Видимо, даже на октябрь толком не успевали, и поэтому начали “резать features”, и поэтому пострадали самые “неперспективные” возможности системы, в том числе и поддержка 64-бит в Carbon. Поэтому теперь наверняка в Adobe “чешут репу” о том, как же им с минимальными потерями и минимизацией головной боли портировать весь набор Creative Suite на Cocoa — а это огромнейший кусок работы. И поэтому результатов раньше версии CS5 ждать не стоит — а это, я думаю, будет примерно 2012 год, а то и позже.
Однако, расстраиваться раньше времени не стоит, так как полезность 64-бит для обычного пользователя обычно сильно преувеличена. Сами представители Adobe говорят о том, что Photoshop в 64-битном режиме для большинства пользователей даст прирост производительности в районе 8-12%, а по-настоящему его возможности раскроются при работе с гигантскими файлами. К примеру, на 4-ядерной машине с 32ГБ оперативной памяти в 64 битном режиме Photoshop открывает файл в 3.75 гигапикселей в 10 раз быстрее, чем в 32-битном режиме.  Однако стоит помнить, что даже самые продвинутые камеры на сегодня снимают изображения размером в 20-25 мегапикселей, что в тысячи раз меньше, чем файл, который открывали на Photoshop.
Так что как раз к выходу CS5 у вас, возможно, появятся файлы, при работе с которыми выигрыш от 64-битности будет заметен. А вот в случае с видео все не так однозначно — видеофайлы уже сегодня занимают терабайты, и очень интересно будет посмотреть, что будет делать Apple, у которой Final Cut (популярное приложение для работы с видео) написано на Carbon.


Discover more from alexmak.net

Subscribe to get the latest posts sent to your email.

9 thoughts on “О 64-битном Photoshop

  1. Для кросс-платформенных приложений, таких как Photoshop, Google Earth или Maya, Carbon вообще оставался практически единственной возможной альтернативой, при которой можно было продолжать разрабатывать приложения для нескольких платформ сразу
    Что-то не совсем ясно. Вы считаете, что Carbon более удобен для разработки кросс-платформенных приложений, чем Cocoa?
    . Затем Apple “обрадовала” всех разработчиков переходом на Intel-процессоры, при котором Adobe пришлось не только переделывать поддержку архитектуры, но и менять инструменты разработки на Xcode
    Переход на новую архитектуру не стоит ничего почти. Только переписать ассемблерный код, которого в CS, уверен, почти что и нет.
    Про XCode вообще непонятно. Все утилиты для сборки (gcc, linker, etc…) интерфейс не поменяли. Переход на xcode и архитектура почти вообще никак не связаны.

    • Про Карбон это не я так считаю – в одном из доков Apple на developer.apple.com под названием “Porting to Mac OS X from Windows Win32 API”, есть такая формулировка:

      Wherever possible, it is recommended that you develop applications using the Cocoa environment. However, Carbon is a good choice when your application is already implemented in C or C++ code that has been written in a procedural (as opposed to object-oriented) style.

      Что касается перехода на архитектуру. С переходом на Intel оказалось, что писать программы в Universal Binary можно только используя Xcode. Продукты Adobe до этого момента писались на CodeWarrior, и поэтому когда оказалось, что надо делать UB, то им пришлось переносить свои проекты сначала с CW на Xcode, а затем только начать портировать приложения.

      • Wherever possible, it is recommended that you develop applications using the Cocoa environment.
        Ага, был не прав. Действительно, родной язык Cocoa — ObjectiveC, а Carbon’а — с++. Так что действительно при наличии c++ кода проще писать используя carbon, нежели мучаться с c++ cocoa’шными binding’ами.
        Что касается перехода на архитектуру. С переходом на Intel оказалось, что писать программы в Universal Binary можно только используя Xcode
        Вы путаете понятия. XCode — это среда разработки, по сути редактор кода. Для сборки используется gcc. Никто не мешает писать код в любом другом редакторе (vi, eclipse cdt, что угодно) и собирать его тем же gcc, который отлично поддерживает сборку UB. Вот, например, Mozilla собирается в UB без всякого xcode.
        Единственная проблема, которая тут может возникнуть, это отсутствие UI’шного дизайнера для Cocoa (в xcode он точно есть).

        • я не путаю, просто формулировка не совсем верная – да, действительно можно делать UB и без Xcode, но зато совершенно точно UB нельзя делать в CW, на котором до этого собирались продукты Adobe.
          Ну и я знаю, что после объявления перехода на интел немало программистов Apple было откомандировано в офис Adobe для помощи перехода с CodeWarrior на Xcode. Да и я как-то себе с трудом представляю проекты объема CS, которые ведутся в текстовом редакторе vi. Может быть, Mozilla и использует какие-то другие средства, но у adobe огромную часть времени перехода на UB занял именно переход на Xcode. да и потом собрать фотошоп и иже с ним, в котором огромное количество legacy code, на UB тоже непросто – это не какавные проги, большинство которых простым recompile можно было собрать

        • Xcode – это не редактор кода, это целый набор утилит для сборки, и, скажем так, порядок и правила сборки задаются в файле проекта Xcode. А Adobe, как и многие разработчики, которые работают под маком еще с классики, использовали CodeWarrior (в то время не было достойных альтернатив) – там, кроме всего прочего, компилятор другой, не gcc. Самая трудоемкая часть в переводе проекта на UB – это как раз перевод на Xcode.

  2. 1. Переход на Cocoa совсем не обязательно влечет за собой “переписывание с нуля”. Серьезных изменений требует только имплементация юзер интерфейса. При этом используются мощные RAD инструменты, количество кода уменьшается, он становится более гибким и оптимальным.
    2. У Adobe уже есть Lightroom, написанный на Cocoa. Я уверен, что 70% его кода – самого ценного, того что отвечает за обработку изображения – взято из Photoshop-а AS IS. Ну не написали же они его заново на Cocoa.
    3. То что Carbon лишь переходной фреймворк не имеющий будущего было известно 8 лет назад.
    4. Microsoft поступает с разработчиками не лучше чем Apple: они объявили что только .NET является теперь “родным” для Windows и что новые возможности системы будут доступны только в нем. А .NET не имеет ничего общего с MFC, Win32 API и стандартным C++. И почему все пинают Apple? При том что Carbon никогда и не был “родным”.
    5. В Adobe работают разные команды. Обратите внимание на разное качество продуктов, и даже на разные иконы фолдеров: http://www.onedigitallife.com/2008/03/27/adobe-drops-giant-turd-on-director-community/ Впрочем разное отношение к проектам наблюдается в любой большой компании.
    6. Учитывая все выше сказанное я могу предположить что все публичные оправдания с наездами на Apple – лишь попытки прикрыть неумелое руководство, или полное отсутствие финансирования развития маковской версии.
    7. В 64-битном коде действительно нет большой необходимости. Проблема “длинных” файлов была на маке решена еще во времена классики (QuickTime содержит набор “64-битных” функций где-то с 3й версии). Правда, справедливости ради, надо сказать, что обычный юзер легко может получить гигапиксельное изображение при попытке создать панораму состоящую из нескольких десятков кадров.

    • По поводу пункта 4 вы, мягко говоря, не правы. Все API появляются сначала в ОС, а потом уже во всех остальных местах. Никто никого не “кидает” — слишком дорого такие выкрутасы обойдутся. Вот, ознакомьтесь, новые API Vista: http://tinyurl.com/6pf684
      Кроме того, скажем, для MFC (это который нативный Win32/64 C++) недавно вышел Feature Pack, который добавляет, например, фичи вроде ribbon в “обычные”, нативные приложения. В .NET 3.x “из коробки” такого нет.

  3. Мне кажется все это отмазки и нежелание адобе вкладывать ресурсы в мак. Бум надеятся кто нибудь их с этого рынка подвинет пока очухаются.
    В сравнимом по сложности продукте – Mathematica, есть и универсальность и 64 битность.
    А уж на чем математика писалась, это вообще история – Вольфрам хвастался что там еще есть код который он писал (наверно очень мало 🙂 ).

  4. А еще надо помнить о том, что МакОСь это юникс и с кэшированием у нее все куда лучше чем у винды.
    Я когда купил 8 гигов, поставил ФШ и увидел что он только 4 видит.. в начале расстроился. А потом посмотрел как это все работает. Пока до реального скрэч диска дело дойдет…
    У меня знакомый редактирует файлы для билбордов, они по 1.5-2 гига весят и он ни каких проблем с производительностью не испытывает. В то время как под виндой 200-300 мегов это уже тормаза страшные, даже если там памяти как грязи.

Leave a Reply