Как не переносить весь код на 64 бита
До чего бывает неприятно: есть 32-битная библиотека на C++, которую вы уже много лет лицензируете клиентам, а теперь все больше и больше клиентов хочет использовать ее из 64-битных программ. Вы развиваете библиотеку, исправляете ошибки, дорабатываете, холите и лелеете ее, она прекрасно работает, а клиентам это не так и важно – они просто хотят 64 бита. Им даже не важно, будет ли она вся 64-битной, они просто хотят ее использовать.
Что делать? Очевидно – переписать код так, чтобы он компилировался и на 32 бита, и на 64:
— читаем много статей – например, вот эту и те, что появятся в «похожих публикациях» при ее прочтении;
— быстренько правим код (за неделю должны управиться, правда?);
— ???
— PROFIT
А теперь добро пожаловать в реальный мир.
Кода, например, два миллиона строк, и код сложный (внезапно), так что переписывать егодолго дооолго. Когда вы закончите, у вас будет одна универсальная версия кода на C++, но вы будете компилировать его и на 32, и на 64 бита, т.е. исполняемого кода станет вдвое больше.
Вдвое больше кода →
→ вдвое больше тестирования;
→ вдвое больше отладки;
→ вдвое больше сопровождения.
Намечался WIN, а уже больше похоже на FAIL.
Вторая попытка. Переписываем все на C#. C# компилируется в волшебный байткод, который потом без проблем работает на машине любой разрядности. WIN?
— C++ и C# похожи, но все же различаются, поэтому переписывать много кода – ооочень долго;
— нужно будет заново профилировать весь код;
— нужно будет заново полностью тестировать весь код;
— очень сложно переписывать понемногу – пока не перепишете все, вам нечего лицензировать клиентам;
— все равно есть клиенты, которым неудобно использовать библиотеки на .NET.
Опять FAIL. Если перечисленные проблемы не убедили, что переписывать весь код может выйти слишком дорого, Капитан Очевидность™ раскрывает тему переписывания тут (оригинал) и отчасти тут.
Что делать, если у вас капитализация меньше, чем у Microsoft, а заставить 32-битный код работать из 64-битных программ хочется?
Попробуйте не переписывать. Попробуйте подружить ваш 32-битный код с 64-битным кодом. На Windows для этого есть технология COM – все необходимое для ее работы входит прямо в состав операционной системы.
«Что? Да COM был старьем, когда я в первый класс собирался идти!» – возразиттолстый тролль читатель в теме. На самом деле… Да, COM существует очень давно. Но колесо придумано гораздо раньше, чем COM, и все равно им пользуются. По одной причине: колесо решает возложенные на него задачи. С COM то же самое – это технология, которая работает.
Придется все же немного потрудиться:
— спроектировать интерфейс библиотеки,
— написать кучу вспомогательных механизмов (здесь здорово поможет ATL),
— протестировать вспомогательные механизмы…
… «вот, опять нечеловеческие усилия» – возразит читатель. Да, поначалу разработка COM-компонентов вызывает небольшие затруднения, придется это пережить. Зато на выходе:
— библиотеку можно использовать из широкого спектра языков – C, C++, C#, VB.NET, Delphi, многие скриптовые языки (и это неполный список);
— можно сделать компонент, код которого выполняется в отдельном процессе;
— сам код остается полностью 32-битным;
«В отдельном процессе? Клиентам ведь придется париться – нужно будет, чтобы их программа умела дружить с компонентом в другом процессе.» – возразит читатель и будет неправ. COM включает в себя магию (называется «маршаллинг»), которая позволяет программе вызывать код компонента так, как будто тот выполняется в ее собственном процессе. Клиент по-прежнему может писать что-нибудь в духе:
COM самостоятельно:
— запустит отдельный процесс,
— попросит его создать объект,
— сам организует связь между процессом программы клиента и процессом компонента,
— предоставит программе клиента объект, который с ее точки зрения ведет себя как настоящий COM объект.
Все вызовы, выполняемые программой клиента, будут перенаправляться в тот отдельный процесс совершенно прозрачно.
Как обычно, есть мелкий шрифт. Магия для организации связи требует накладных расходов, поэтому есть смысл проектировать интерфейс так, чтобы методов в нем было поменьше, а полезной работы они делали побольше – тогда доля магии в общем времени работы не будет беспокоить.
Есть еще неприятный момент. Работа компонента в отдельном процессе реально нужна только тем клиентам, у которых программы 64-битные. Клиентам, у которых программы 32-битные, от этого никакого толку, одни накладные расходы. COM позволяет сделать компонент, работающий в том же процессе, но снова две версии компонента – снова больше кода, больше тестирования, больше сопровождения.
Британские ученые™ недавно нашли решение и этой проблемы. Это COM+ – технология, которая среди прочего позволяет заставить компонент, предназначенный для работы в том же процессе, работать в отдельном. COM+ есть во всех версиях Windows, начиная с Windows 2000. Вы делаете компонент для работы в том же процессе и при необходимости кладете его в COM+ (Start→Settings→Control Panel→Administrative Tools→Component Services, там несколько щелчков мышью).
Программа клиента работает как обычно. Если программа 32-битная, компонент создается в том же процессе. Если программа 64-битная, включается магия, COM+ запускает так называемый суррогатный процесс, загружает компонент в него, организует маршаллинг, дальше компонент используется прозрачно из отдельного процесса.
По этому пути мы пошли, когда (внезапно) осознали, что COM-компонент для интеграции с Recognition Server невозможно использовать из 64-битных программ, а очень нужно. Кода там не очень много и мы бы могли его перенести, но оказалось намного проще использовать для решения этой проблемы COM+. Сравните – много не особо полезной кропотливой работы или несколько щелчков мышью.
Не всегда стоит переписывать весь код на 64 бита просто ради переписывания. Освободившееся время можно потратить на троллинг этого поста.
Дмитрий Мещеряков
Руководитель группы разработки Recognition Server
Что делать? Очевидно – переписать код так, чтобы он компилировался и на 32 бита, и на 64:
— читаем много статей – например, вот эту и те, что появятся в «похожих публикациях» при ее прочтении;
— быстренько правим код (за неделю должны управиться, правда?);
— ???
— PROFIT
А теперь добро пожаловать в реальный мир.
Кода, например, два миллиона строк, и код сложный (внезапно), так что переписывать его
Вдвое больше кода →
→ вдвое больше тестирования;
→ вдвое больше отладки;
→ вдвое больше сопровождения.
Намечался WIN, а уже больше похоже на FAIL.
Вторая попытка. Переписываем все на C#. C# компилируется в волшебный байткод, который потом без проблем работает на машине любой разрядности. WIN?
— C++ и C# похожи, но все же различаются, поэтому переписывать много кода – ооочень долго;
— нужно будет заново профилировать весь код;
— нужно будет заново полностью тестировать весь код;
— очень сложно переписывать понемногу – пока не перепишете все, вам нечего лицензировать клиентам;
— все равно есть клиенты, которым неудобно использовать библиотеки на .NET.
Опять FAIL. Если перечисленные проблемы не убедили, что переписывать весь код может выйти слишком дорого, Капитан Очевидность™ раскрывает тему переписывания тут (оригинал) и отчасти тут.
Что делать, если у вас капитализация меньше, чем у Microsoft, а заставить 32-битный код работать из 64-битных программ хочется?
Попробуйте не переписывать. Попробуйте подружить ваш 32-битный код с 64-битным кодом. На Windows для этого есть технология COM – все необходимое для ее работы входит прямо в состав операционной системы.
«Что? Да COM был старьем, когда я в первый класс собирался идти!» – возразит
Придется все же немного потрудиться:
— спроектировать интерфейс библиотеки,
— написать кучу вспомогательных механизмов (здесь здорово поможет ATL),
— протестировать вспомогательные механизмы…
… «вот, опять нечеловеческие усилия» – возразит читатель. Да, поначалу разработка COM-компонентов вызывает небольшие затруднения, придется это пережить. Зато на выходе:
— библиотеку можно использовать из широкого спектра языков – C, C++, C#, VB.NET, Delphi, многие скриптовые языки (и это неполный список);
— можно сделать компонент, код которого выполняется в отдельном процессе;
— сам код остается полностью 32-битным;
«В отдельном процессе? Клиентам ведь придется париться – нужно будет, чтобы их программа умела дружить с компонентом в другом процессе.» – возразит читатель и будет неправ. COM включает в себя магию (называется «маршаллинг»), которая позволяет программе вызывать код компонента так, как будто тот выполняется в ее собственном процессе. Клиент по-прежнему может писать что-нибудь в духе:
ThatLibrary.Worker worker = new ThatLibrary.WorkerClass();
worker.DoWork();COM самостоятельно:
— запустит отдельный процесс,
— попросит его создать объект,
— сам организует связь между процессом программы клиента и процессом компонента,
— предоставит программе клиента объект, который с ее точки зрения ведет себя как настоящий COM объект.
Все вызовы, выполняемые программой клиента, будут перенаправляться в тот отдельный процесс совершенно прозрачно.
Как обычно, есть мелкий шрифт. Магия для организации связи требует накладных расходов, поэтому есть смысл проектировать интерфейс так, чтобы методов в нем было поменьше, а полезной работы они делали побольше – тогда доля магии в общем времени работы не будет беспокоить.
Есть еще неприятный момент. Работа компонента в отдельном процессе реально нужна только тем клиентам, у которых программы 64-битные. Клиентам, у которых программы 32-битные, от этого никакого толку, одни накладные расходы. COM позволяет сделать компонент, работающий в том же процессе, но снова две версии компонента – снова больше кода, больше тестирования, больше сопровождения.
Британские ученые™ недавно нашли решение и этой проблемы. Это COM+ – технология, которая среди прочего позволяет заставить компонент, предназначенный для работы в том же процессе, работать в отдельном. COM+ есть во всех версиях Windows, начиная с Windows 2000. Вы делаете компонент для работы в том же процессе и при необходимости кладете его в COM+ (Start→Settings→Control Panel→Administrative Tools→Component Services, там несколько щелчков мышью).
Программа клиента работает как обычно. Если программа 32-битная, компонент создается в том же процессе. Если программа 64-битная, включается магия, COM+ запускает так называемый суррогатный процесс, загружает компонент в него, организует маршаллинг, дальше компонент используется прозрачно из отдельного процесса.
По этому пути мы пошли, когда (внезапно) осознали, что COM-компонент для интеграции с Recognition Server невозможно использовать из 64-битных программ, а очень нужно. Кода там не очень много и мы бы могли его перенести, но оказалось намного проще использовать для решения этой проблемы COM+. Сравните – много не особо полезной кропотливой работы или несколько щелчков мышью.
Не всегда стоит переписывать весь код на 64 бита просто ради переписывания. Освободившееся время можно потратить на троллинг этого поста.
Дмитрий Мещеряков
Руководитель группы разработки Recognition Server
комментарии (193)
"??? PROFIT", «внезапно» «WIN/FAIL», «Капитан Очевидность™», «британские ученые™» и прочая.
Бррр
Приятная статья, но вот над языком изложения бы поработать :)
2 Я бы всё это называл ядерным шаманством и кривотой, усложняющей поддержку в разы. Я думаю если библиотека нужна не одному единственному заказчику с 64 битной ОС а много кому, то лучше всё таким портировать на х64(С учётом того что каждый год количество 64 битных ОС у юзеров растёт быстро).
А вообще если бы не «спектр языков», то хватило бы .net для таких целей.
А ничего, что мир стабильно и уверенно движется в сторону если уж и не 64-х бит, то платформенной независимости? Слово ARM вам ничего не говорит? или вы и там будете через COM+ сервис давать?
Соответственно, можно сделать хорошую, правильную работу (вычищать говнокод — полезнее, чем плодить новый) 1 раз, а объем поддержки далеко не факт, что удвоится (кодовая база одна, то что бинарников получается два — ничего плохого не делает).
А «закладываться» на межпроцессное взаимодействие посредством COM/COM+ — тут могут быть свои грабли. Как минимум связанные с временем жизни серверного процесса.
Переход на новую версию ОС менее болезненен, чем переход под 64 бита.
Всё-таки можно программировать ради красивого кода, а можно деньги этим зарабатывать — подходы разные.
Это не значит, что такой метод стоит применять везде и всюду при первой возможности.
Это также не значит, что писать код изначально кроссплатформенным — некруто.
Далеко не факт, что использование дополнительной технологии потребует меньшее количество ресурсов, чем вычистка 32-бит-зависимого кода.
Гугль распознавалку допишет и вы встанете в длинную очередь ненужных проектов. Как недавно производители GPS-навигаторов.
Вот честно, никаких претензий лично к вашей компании. Я даже хочу, что бы у вас все было хорошо (говорят, файнридер — клевая вещ, но я не пробовал), но вот за методы, описанные в статье, надо бить лопатой по рукам.
Про Wave помниться тоже что то такое говорили — сейчас Гугл его допишет, запустит — и все в интернете перевернется.
Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще.
?
COM+ хороший и правильный в плане переносимости на другие платформы?
Вы действительно уверены, что костыли через COM — это «подходящая технология для того, чтобы с первого раза сделать хорошо и правильно»? Извините, но я был лучшего мнения о специалистах компании ABBYY… =\
Вы уже ошиблись дважды: первый раз — когда написали код, который для переноса на 64 бита требует описанных костылей (или доооолгого переписывания), второй раз — когда в качестве «решения» выбрали платформо-зависимый COM (в свете заявляения «на Линукс мы сами неплохо его портируем» это смотрится особенно феерично). Так что маркетоидные рассказики о том, как вы «сразу делаете хорошо и правильно» оставьте для тех, кто в это поверит.
Будет АРМ? Пусть будет. На чем писать десктопные приложения для него, да так, чтобы это было совместимо с большим компьютером, пока не сильно очевидно.
Жаву не предлагать, мы все знаем, как широко у нас распространен гуй на ней и дестопные жава-приложения :)
Можно писать на C/C++ имея нормальные, исторические сложившиеся механизмы интеграции — динамическая линковка.
Почему-то вот в линуксе нету практически никаких проблем с портированием софта. Один раз написали код ядра и большая часть userland-софта просто начинает работать на новой платформе.
У ABBYY есть библиотека и гуй. В чем проблема сделать портабельную библиотеку и по одному интерфейсу на каждую нужную платформу? Вместо этого начинаются пляски с бубном.
То, что вы гвоорите, что «нет проблем с портированием софта» — это все не то, о чем писал автор. Портирование софта = компиляция-сборка-тестирование под новую целевую платформу. И поддержка.
Вышла убунту? Получили +1 версию.
Вышел андроид? Получили еще +1 версию.
Идея, насколько я понял, была именно в минимизации кода и максимальному сведению его к одной ветви. «Потому что мы меньше чем микрософт» — такая позиция расово очень близка.
Это все уже давно есть до меня, гуглите.
В качестве одного из стандартов можете взять POSIX.
Клиентская программа как-то общается с библиотекой, а библиотека как-то общается с операционной системой. POSIX — стандарт общения с операционной системой, общение программы с библиотекой тут ни при чем.
POSIX — это набор стандартов для написания переносимого софта. Т.е. одни и те же исходники можно будет собрать под разными операционками. О методах интеграции со сторонним софтом там тоже есть.
Посмотрите, например, любую из стопиццот тысяч опен-сурс библиотек, одинаково хорошо работающих в любых линукс-дистрибутивах, практически во всех unix и даже в windows.
Для простых библиотек (а библиотека, реализующая некий алгоритм распознавания символов, т.е., собсно, чистая математика, обязана быть простой. Простой — в смысле количества связей со внешними разнородными сущностями) для кросс-платформенности достаточно таких уникальных инструментов как компилятор и линкер. Никаких ни фреймворков, ни протоколов не нужно. Базовые вызовы и всё.
> пересобирать их придется нам
То есть вы не хотите нормально проектировать приложения потому, что вам их (боже, боже!) придётся собирать? Я правильно понял вашу мысль?
Нужно будет собирать, тестировать (как следует тестировать) и поставлять дистрибутив под каждую. Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Вот сейчас начали помаленьку появляться ноутбуки на ARM. А вы что? А вам их никогда не видать. По крайней мере вот с таким подходом.
> Вы думаете, это так запросто? Что мы с этого получим кроме ощущения «правильности программирования»?
Запросто было бы, если бы перед написанием двух миллионов строк кода кто-нибудь успел подумать головой. А теперь ССЗБ на костылях. Подумайте сейчас — ещё не поздно, пока ещё два миллиона строк не нафигачили.
А после применения костылей, описанных в топике, вы тестировать на целевой платформе не собираетесь, что ли? о_О
Если собираетесь — то какая разница, какую сборку тестировать: нативную или костыльно-КОМовскую?
Объем в 2 миллиона строк преодолен уже давно.
Во втором случае люди уже десятилетиями пишут программы, которые одинаково работают на x86, ARM, MIPS, Power etc до бесконечности. Как так получилось? И ведь сложности возникают, только в случае зависимости от каких-то экзотчных вещей на конкретной ОС.
Вы думаете — весь мир это виндоуз и 32/64 бита? Боюсь старик Джобс прямо сейчас крайне удачно пересаживает человечество на ARM.
Что вы будете делать со свом COM-ом проблема для портирования продукта на iPad?
Я по поводу кросс-платформенности вообще. Для коммерческих продуктов критична не только работоспособность, но и конкурентоспособность. В частности, для библиотек очень часто важна скорость работы. Для победы над конкурентами по этому параметру приходится применять всяческие уловки:
— ассемблер (редко, осторожно, только если реально помогает).
— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
— оптимизация файловых операций (тоже по-разному работает на разных платформах)
— компиляторные оптимизации и оптимизация кода под конкретный компилятор(работают ОЧЕНЬ по-разному для разных платформ, а на кросс-платформенном GCC до сих пор работают нестабильно).
— процессорные оптимизации (оптимизация под конкретный процессор).
— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом. От этих действий код может стать сильно не-кроссплатформенным. В этом нет ничего страшного: вместо того, чтобы заставлять 50 человек писать кросс-платформенный код, часто имеет смысл сфокусировать их на качестве работы кода на одной, основной платформе, а еще двух людей потом попросить перенести этот код на другие платформы. Это дешевле и эффективнее с точки зрения достижения результата.
И еще: алгоритм распознавания очень непростой. Наверное, как-нибудь стоит рассказать о нем поподробнее на Хабре. Это не математика. Это скорее искусственный интеллект.
Не подскажете, какая платформа лидирует на рынке серверов, раз уж в посте упоминаются серверные приложения?
А вообще было бы интересно прочитать соответствующую публикацию.
Все решают сугубо финансы.
Средств, чтобы сделать более-менее полноценный кроссплатформенный софт — кот наплакал. Java и QT, ВСЁ. Зная производительность программирования на Qt (да, снова упирается в деньги), это вовсе перестает быть серебряной пулей.
Мало вопросительных знаков.
> Зачем мне при разработке ориентироваться на сферический линукс-рынок бухгалтерского софта и тратить на это усилия, когда это 0.0001% от рынка, и его роста не предвидится?
Попробую ещё раз, но иначе: вы в состоянии сопоставить доли процентов 64-разрядных систем годы назад и их текущее положение на рынке?
> в 2010 году под win чудесно работают дос программы, и МС все сделала, чтобы на вин64 без проблем шел вин32 код. Более того, клиент даже не будет знать, что это 32.
Ага, особенно когда это пакет декодеров, или утилиты, встраивающиеся в Проводник.
Это слишком частный узкий случай. Многомиллионную же армию разработчиков прикладного софта эти 32/64 переходы никак не волнуют.
— делает ли библиотека то, что нужно
— работает ли она на их платформе
— легко ли ее интегрировать в программу клиента на выбранном клиентом одном из многих языков.
Оно и видно — проще написать про два миллиона строк кода, сказать «ой!» и приделать костыль, вместо того, чтобы сразу нормально спроектировать приложение.
«Зачем мне при разработке ориентироваться на сферический рынок 64-битных систем?» — думал архитектов из ABBYY 5 лет назад… В общем, уровень понятен.
Да, кстати, чисто из любопытства: какой ранг у человека, отвечающего на вопросы в этом треде под ником ABBYYTeam? В частности, вот в этой ветке? Узнать ранг автора статьи было бы тоже весьма интересно.
Дмитрий Мещеряков
Руководитель группы разработки Recognition Server
Наверное он и отвечает на комментарии к его же статье. Тогда, в общем, понятно, откуда у ABBYY такие сложности с выпуском того же Lingvo для Linux, который просят у них уже лет пять.
офигеть %-)
Братцы линухоиды и просто любители писать «правильный кросс-платформенный софт», простите, но похоже, что вы этим просто никогда не занимались.
Посмотрев однажды за разработкой одного такого продукта, для тестирования которого необходимо было иметь порядка 270 тестовых конфигураций с разными версиями мускула, постгриса, апача и дистрибутивов никсов, с командой QA, которая в восемь раз превышала команду разработчиков, я стал жутко преданным сторонником Microsoft.
Вы просто не представляете, какое счастье, что есть кампания, которая выпускает софт для 95% машин и разрабатывая свою продукцию под ее платформу, можно с чистой совестью забить на полпроцента неудачников!
Ребята, я хочу заниматься разработкой, а не изнурительной синхронизацией между разными платформами, которые сами не очень заботятся о совместимости (к слову, в отличии от той же MS).
что с оставшимися 4.5% пользователей?
А если кроме шуток, то реальность такова, что в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Иными словами, кампании разработчику выгоднее убедить клиента поставить еще одну машину с windows, чем портировать высокотехнологичный софт на другую платформу — wellcome to real world.
На всякий случай расшифрую — подстраиваться под клиента имеет смысл ровно до тех пор, пока прибыль приносимая клиентом превышает расходы по подстройке под него.
На всякий случай переведу для широкой публики, словами попроще: пока лох башляет — на его пожелания можно c&@$b. Я ничего не упустил при переводе?
Говоря Вашим языком, пока клиент НЕ башляет, его пожелания не интересуют.
И ещё вопрос: когда необходимость всё же назреет, вы будете исправлять ситуацию точно так же, прибивая новую версию программы к некоторой (пускай это будет x64 во время массового перехода на x128 — это будет очень в духе ABBYY) архитектуре гвоздями, или всё же на этот раз, кхм, рассмотрите альтернативы?
habrahabr.ru/company/abbyy/blog/101560/#comment_3152960
> мы будем решать ее тем способом, который сочтем самым эффективным.
«говнокод» — упомянуто дважды
«костыл» — одиннадцать упоминаний (я вычел пять упоминаний в моих сообщениях)
> Вы сейчас говорите о возможной проблеме неизвестно насколько далекого будущего.
Возможной проблеме? Вы серьёзно? Нет, правда?
Весь тред начался со статьи ровно о том, как ABBYY удовлетворила это пожелание своих клиентов.
Насколько я понял — все довольны, обиженным не ушел никто :)
> Весь тред начался
Тред начался с возможности (слово «возможность»! Вы видите его?) проектировать софт так, чтобы при необходимости (при необходимости! ещё раз: «при необходимости») его можно было гораздо проще переносить на другие ОС и архитектуры? Без использования ужасных костылей, как в этом случае.
> Насколько я понял — все довольны, обиженным не ушел никто :)
Да, да, они бы ещё 16-разрядную версию в виртуальной машине предложили запустить. Ведь:
> в любой кампании готовой заплатить за софт который ей реально нужен, не проблема поставить еще одну машину с windows под этот софт, и имеются в наличии админы способные эту машину поддерживать в работоспособном состоянии.
Так? Вы бы одобрили такой метод решения и статью об этом на Хабре?
Разницу между написанием кода, для которого доступна возможностью лёгкого переноса на платформу, поддержку которой потребовал рынок, и написанием кода, перенос которого потребует полного переписывания понимаем? Или вы не различаете возможность переноса и поддержку уже перенесённого?
И вопросы поддержки и разработки новых фич никто не отменял.
Процитируйте, пожалуйста, список поддерживаемых архитектур, у, например, Debian.
Для особых поклонникров POSIX могу напомнить относительно недавнюю историю про Oracle и SAP — обе эти компании официально поддерживали ReadHut и SuSE, но в какой-то момент оказалось так, что ни на одной из этих операционок нельзя создать такую конфигурацию, чтобы последние SAP и Oracle работали одновременно.
Можно конечно сказать, что и SAP и Oracle тоже код писать не умеют и я даже сильно возражать не буду… :) Но речь не о об этом…
А о том, что пора уже расставаться с подростковыми иллюзиями о том, что можно легко написать эффективный кроссплатформенный код.
Удачи. =)
Для начала можете попробовать просто выделить список и скопировать его сюда. Я верю, у вас получится!
> Для особых поклонникров POSIX могу напомнить относительно недавнюю историю про Oracle и SAP — обе эти компании официально поддерживали ReadHut и SuSE, но в какой-то момент оказалось так, что ни на одной из этих операционок нельзя создать такую конфигурацию, чтобы последние SAP и Oracle работали одновременно.
Вы хотите передать привет лидеру команды QA SAP?
> А о том, что пора уже расставаться с подростковыми иллюзиями о том, что можно легко написать эффективный кроссплатформенный код. Удачи. =)
Пора научиться читать сообщения оппонентов. Вам про Фому, а вы про Ерёму.
Вам сюда: habrahabr.ru/company/abbyy/blog/101560/#comment_3153497
Кроме того эти три сообщения ожидают вашего ответа:
habrahabr.ru/company/abbyy/blog/101560/#comment_3153449
habrahabr.ru/company/abbyy/blog/101560/#comment_3153201
habrahabr.ru/company/abbyy/blog/101560/#comment_3153456
Ну так расскажите же нам, каким образом Linux с одной стороны поддерживает хренову тучу архитектур (это к вопросу об универсальности), а с другой стороны — стоит на более, чем 90% суперкомпьютеров из Top500 (это к вопросу об эффективности)?
Под суперкомпютеры пишется узкоспециализированный софт, который Вы устанете куда либо портировать, да и сами дистрибутивы там отнюдь не Ubuntu, — так что да, прекрасный аргумент, жаль что не в тему… =)
На этом ваши познания в этом вопросе, я полагаю, и ограничиваются? Просто по всем вашим сообщениям видно, что так и есть.
Угу, вот только как связаны «поддержка кучи архитектур» и «невозможность стороннего софта нормально взаимодействовать на одной и той же машине с другим софтом» — видимо, так и останется загадкой.
>Под суперкомпютеры пишется узкоспециализированный софт...
Писать узкоспециализированный софт можно под любую платформу. Ну так почему же для более 90% суперкомпьютеров в качестве платформы для этого самого «узкоспециализированного софта» был выбран именно Linux?
Да, мы сейчас как раз наблюдаем за компанией, которая несколько лет назад «разработала софт для 95% машин» (32-битных) и «с чистой совестью забила на полпроцента неудачников» (обладателей 64-битных систем). Что из этого вышло — читаем в статье.
Мы сейчас наблюдаем за компанией, которая на протяжении 15 лет выпускает лучшую распознавалку в мире (это не преувеличение, по качеству распознавания файн рвет всех конкурентов по всем тестам с момента своего выхода на рынок и до наших дней) и которой, на сколько мне известно, принадлежит больше половины всего рынка распознавания.
Мальчики, приходите со своей критикой, когда напишите то же самое, но портабельно подо все что можно, договорились? :)
Список ответов тут: lurkmore.ru/Сперва_Добейся#Варианты_беспроигрышной_контратаки
Прочитаете там, сюда копировать мне лень.
> Мы сейчас наблюдаем за компанией, которая на протяжении 15 лет выпускает лучшую распознавалку в мире (это не преувеличение, по качеству распознавания файн рвет всех конкурентов по всем тестам с момента своего выхода на рынок и до наших дней) и которой, на сколько мне известно, принадлежит больше половины всего рынка распознавания.
Прошу вас не стесняться, и без утайки рассказать «мальчикам», как связан дар разрабатывать действительно хорошие алгоритмы распознавания с умением откровенно плохо (хотел написать другое слово; впрочем, и так понятно, какое) проектировать приложение в целом? По факту ведь имеет и то, и другое.
Она успешна не только потому, что алгоритмы эффективные, но и потому, что оказалась в состоянии поддерживать эффективность этих алгоритмов на протяжении более пятнадцати лет, обеспечивать все это вермя стабильные релизы и удовлетворять самые прихотливые запросы клиентов.
И уж поверьте — делать это без действительно хорошей архитектуры и правильно спроектированного кода было бы невозможно.
Причем правильно спроектированного не с учетом абстрактной совместимости «а вдруг когда чего потребуется», а с учетом текущей рыночной ситуации, целевой аудитории и стратегии развития продукта продуманной заранее на много лет вперед.
Эти приложения спроектированы так, чтобы (в порядке приоритетов):
а — наиболее эффективно решать задачу в текущих условиях
b — наиболее быстро и эффективно удовлетворять запросы клиентов (что и было продемонстрировано)
Иными словами, по факту, приложения abbyy, учитывая обсуждаемый recognition спроектированы на отлично — возражения есть?
Так что еще раз повторюсь: мальчики, вы прежде чем критиковать, попробуйте сами создать что-нибудь подобное, но очень-очень архитектурно правильное.
> наиболее быстро и эффективно удовлетворять запросы клиентов (что и было продемонстрировано)
Первая версия Recognition Server была выпущена в августе 2007 года. Вы приблизительно представляете, как выглядел график роста продаж 64-разрядных серверов в то время, и как падали продажи 32-разрядных? Ах, сие была неуловимая перспектива — в те времена одному лишь Богу было известно, что же будет дальше.
> Так что еще раз повторюсь: мальчики, вы прежде чем критиковать, попробуйте сами создать что-нибудь подобное, но очень-очень архитектурно правильное.
Мальчики, мальчики… вас мальчики в детстве обидели что ли?
Мимоходом может быть расскажете, как эти канальи из неуправляемого сообщества Debian (если бы я привёл пример корпоративного ПО — это сравнение было бы слишком равноценным; использование в качестве примера Debian даёт ABBYY фору в сравнении) умудряются переносить на неподдерживаемые ранее архитектуры не один проект, а операционную систему и десятки гигабайт программного обеспечения? Как им это удаётся?
Подозреваю, что в 07 году и было принято описанное здесь решение для работы rs на x64.
Я уже описал как они это делают — совместимость и клиенты их не парят ни в одном месте.
Я всерьёз полагаю, что кроме проектирования костылей за три года можно было решить проблемы, которые бы избавили от необходимости мастерить костыли в будущем. Интересно, сколько они ещё собираются сидеть на этих двух миллионах строк? Год? Пять? Десять?
> Я уже описал
Где?
Recognition Server — не единственно возможный способ использования технологических библиотек, это продукт для определенной рыночной ниши. Есть сценарии (в других рыночных нишах), когда его инфраструктура вообще не нужна для решаемой клиентом задачи, а этом случае эффективнее использовать другую архитектуру, при которой в процессе клиента работает намного больше кода.
Так что да, вы правы, что в Recognition Server формально 64-битный код нужен не везде, но это не отменяет сценариев, когда формально весь код должен быть 64-битным.
Это интересно. Где можно узнать больше?
Еще — как это работает в сценарии, когда все много строк кода изначально работали в процессе клиента? Все равно же нужно будет где-то провести межпроцессную границу и организовать взаимодействие, верно?
В сценарии, когда все два миллиона строк кода должны работать в контексте клиентского приложения — межпроцессная граница проводится там же, где она имеется у вас уже сейчас. Т. е. Recognition server — сам по себе (в своих процессах), его клиенты — сами по себе (в клиентских процессах). Если я, конечно, правильно понял суть вопроса.
Объективно это выглядит как то же самое, но по-другому, нужно будет внимательно оценить слабые и сильные стороны.
«Экспертно»-субъективно — это «очередные грабли и феерические костыли, чтобы только не проектировать приложение нормально с самого начала».
На счёт первого абзаца — то да, с точки зрения банальной эрудиции — это тоже самое. Но есть существенное отличие, заключающееся в том, что решение базируется на mainstream (на текущий момент) технологиях, а не на «старом добром COM'е», который поддерживают постольку-поскольку это необходимо, но уже не развивают. Как результат — потенциал у такого решения больше.
Да, идея интересная, нужно будет ее внимательно оценить. Спасибо.
В пассиве же — неоходимость тянуть за собой .Net Framework, для серверных приложений это может быть и не критично, а для клиентских все еще довольно актуально, к сожалению.
На счёт «тянуть фреймворк» — это да. Придётся. Но это не архикритичное требование.
Тянуть же за собой FW требование конечно не архикритичное, но и чем так плох COM тоже не очень понятно. =)
habrahabr.ru/company/abbyy/blog/101560/#comment_3153265
Буду признателен, если вы ответите на этот вопрос:
> Интересно, сколько они ещё собираются сидеть на этих двух миллионах строк? Год? Пять? Десять?
Дяденька, у Вас аргументация на уровне школьника (я смотрю, Вам эту сслыку уже привели выше). Весьма неожиданно слышать подобную «логику» из уст преподавателя ВУЗа. Как-то сразу немного грустно становится.
Слушайте-ка сюда: я уверен, что Вы сами не раз упоминали в нехорошем контексте плохие дороги/наглых маршрутчиков/глюки винды/идиотов в Думе/операторов из колл-центров ОпСоСов и так далее. При этом я так же уверен, что Вы не проложили ни километра асфальтовой дороги, ни дня не проработали водителем маршрутки, не написали операционной системы, стоящей на ~90% десктопов в мире, ни дня не заседали в Думе и ни дня не проработали оператором в колл-центре ОпСоСа. Верно? Поэтому (следуя Вашей собственной логике) — молчите в тряпочку и про дороги, и про маршрутчиков, и про винду, и про всё остальное.
Я же, напротив, давно и плотно занимаюсь как дизайном софта, так и воплощением этого дизайна в жизнь, поэтому я прекрасно вижу, когда отовсюду торчат «белые нитки».
У Вас есть что возразить по существу моего предыдущего комментария (про 95% 32-битных систем и далее по тексту)? Не хотите ли Вы заявить, что невозможно написать эффективную кроссплатформенную программу? Тогда мне становится ещё более грустно за Ваших студентов (если Вы, конечно, преподаёте что-то, связанное с IT).
>Я же, напротив, давно и плотно занимаюсь как дизайном софта, так и
>воплощением этого дизайна в жизнь, поэтому я прекрасно вижу, когда
>отовсюду торчат «белые нитки».
Простите, но не верю. Уровень критики и аргументации не соответствует этому заявлению, ровно по этому я и позволяю себе некоторые вольности, в стиле этой дискуссии. Какой вопрос, такой и ответ ))
Ровно по существу я и ответил, если Вы внимательно читали.
Это коммерческий софт, а не фриварные штаны на лямках. Данное решение позволило эффективно и в минимальные сроки решить запросы клиентов — если для данного приложения на самом деле достаточно 32 бит, то переводить его на 64 из любви к искуству нет никакого смыла, благодаря тому что есть COM+, который обеспечивает отличную совместимость. :)
Уровень Вашей аргументации не соответствует Вашим словам о том, что Вы преподаёте в ВУЗе — так что теперь?
>Данное решение позволило эффективно и в минимальные сроки решить запросы клиентов — если для данного приложения на самом деле достаточно 32 бит, то переводить его на 64 из любви к искуству нет никакого смыла, благодаря тому что есть COM+, который обеспечивает отличную совместимость.
Что в переводе означает «Мы по-быстрому слабали офигенное решение для текущих насущных потребностей, которое оказалось непереносимо даже в рамках одного семейства ОС, а для работы под 64 бита нам приходится прикручивать разного рода костыли».
Что слегка отличается от пафосного заявления «Мы как раз используем подходящую технологию для того, чтобы с первого раза сделать хорошо и правильно, а не переносить постоянно на что-нибудь еще» (с которого, собственно, и началось моё участие в данном топике).
Я ни в коему случае не хочу сказать, что программа плохая или не выполняет возложенных на неё задач. Выполняет, причём на отлично. Мои «претензии» (если Вы до сих пор не заметили) совершенно иного плана.
Но не переживайте, я прекрасно провел вечер пятницы наблюдая троллей в их природной среде обитания, однако дальнейшие развлечения подобного рода мне наскучили, поэтому я прекращаю свое участие в этой клоунаде. =)
> Мои «претензии» (если Вы до сих пор не заметили) совершенно иного плана.
Последняя попытка: Поймите одну простую мысль — писать эффективный код заточеный под одну платформу и писать эффективный переносимый код — две большие разницы, более того, второе, во многих случаях, попросту невозможно.
И утверждать, что компания А криворукие уроды, проектировать они не умеют и архитектура их продуктов ужасна, лишь на том основании, что они решили заложиться на особенности платформы (и по факту, заметим, оказались совершенно правы), вместо того чтобы бороться за переносимость… Как бы это по мягче сказать — несколько самонадеянно.
Спасибо, я тоже провёл немало весёлых минут, наблюдая за слабыми попытками выкрутиться, и так и не получив внятного возражения по поводу того, что Linux одновременно является а) универсальным; и б) эффективным решением. И что «особенности платформы» не являются помехой для написания переносимого кода (а уж сколько в Linux кода, заточенного под «особенности» того или иного процессора — поинтересуйтесь сами, благо источники открыты).
Да уж, участие в этой «клоунаде» Вам стоило прекратить намного раньше…
О! Серьёзное заявление! Давайте, раскрывайте свою мысль — очень интересно, что же именно вы имели ввиду.
Большое спасибо за конкретный пример того, как это бывает в реальном мире.
habrahabr.ru/company/abbyy/blog/101560/#comment_3149949
Между прочим то, что вы не потрудились ответить про множество конфигураций там, но именно так ответили здесь, говорит о многом. Надеюсь, что вся эта чушь про многоплатформенность, POSIX и истории успеха на *nix не сильно отвлекают вас от написания третьего миллиона строк кода. Кстати, вам доводилось читать слухи о том, что к Windows 8 MS готовит рынок к переходу на 128-разрядные ЦП? Что? Отвлекаю? Извините, пишите дальше непереносимый код для x86.
Я ожидал такую реакцию на упоминание 128-разрядных ЦП. Вы оправдали мои ожидания. Ваш ответ так же подтвердил это предположение: habrahabr.ru/company/abbyy/blog/101560/#comment_3152403
Ещё раз извините за то, что отвлекаю от работы. Она ведь у вас такая тяжёлая — день изо дня бегать по кругу на костылях, предварительно устилая свой путь граблями. Хотя… вы ведь счастливы, занимаясь своим делом, да? Ну и ладно — ведь это главное, а все эти проблемы ваших программистов и клиентов, это всё мирское, и не достойно вашего внимания. Не отвлекайтесь!
Реальная проблема — как сделать библиотеку так, чтобы ее можно было использовать из 64-битных программ. В случае Recognition Server библиотекой является только компонент интеграции — все остальное в любом случае работает в отдельных процессах, с которыми клиент программно не общается.
Да, внезапно: habrahabr.ru/company/abbyy/blog/101560/#comment_3149949
Но есть способ облегчить себе жизнь, однако вы смотрите на него с точки зрения типичного Win-программиста, которому MS из года в год скармливает какую-нибудь ненужную или костыльную новинку.
Им это не грозит, поэтому: habrahabr.ru/company/abbyy/blog/101560/#comment_3152960
Я несколько далек от темы, но мне кажется, что это — жесть.
расходы на маршалинг — они просто дичайшие.
1) метод для инициализации, метод для задания фильтра, метод для установки «курсора» на первую запись, метод для получения следующей записи
2) один метод на всё: задали фильтр — получили список записей (пускай и внутри модели всё будет происходить аналогично способу 1, например вызовом тех же методов, но приватных)
Разве выбор второго метода — это дичайшая жесть? :) Особенно, если не исключено, что модель будет выполняться в отдельном процессе? Да, возможно, что потом, «когда-нибудь завтра» (с), понадобится работать с отдельными записями, но когда понадобится, тогда и добавим нужные методы в интерфейс (а скорее сделаем их из приватных публичными)
Там свои тонкие извращения типа аякса, разбора на клиенте, чтобы траффика поменьше, пореже и по-асинхроннее.
меньше методов — гораздо более быстрая локализация места ошибки. плюс меньше методов — меньше вызовов прослойки и больше вызовов целевой библиотеки
хотя, у вас наверное таких проблем не должно быть:)
статья хорошая, спасибо
Managed C++ — и вызываем ваш 32-битный код из 64-битного приложения. Мороки меньше, проверять прощё.
Что не совсем то, что я думал в начале.
Очень удобная штука много для чего (например, для универсального интерфейса расширений функционала; не делать же его на экспортных функциях — тогда до свидания Шарп).
Который лежит в базе половины системы винды.
На котором написано немеряно АПИ.
За что его забыли? За некроссплатформенность?
С другой стороны, это — все равно костыли. Реализация кома проста как банан, а фреймворк при этом даже проще — как шкурка от банана. Но иногда старые-добрые костыли приходится доставать =)
я слышал, что отбор в вашу компанию будь здоров ;)
как так получилось, что код нельзя перекомпилировать под 64 бита? расскажите, какие ошибки в коде привели к такого рода непортабельности.
есть ли в компании внутренние семинары для разработчиков, которые бы помогли команде писать более «правильный код»? подкорректировали ли вы программу собеседования на предмет понимания программистом особенностей написать кода, который бы одинаково успешно мог работать под 32 и 64 битами путем обычной перекомпиляции?
кстати, ответы было достойны отдельной статьи!
Некоторые проблемы такого вида можно выявить только после очень тщательного тестирования. Плюс есть очень много старого (зато работающего и проверенного) кода, при написании которого 64 бита были как сферический конь в вакууме. Соответственно, если у вас есть неограниченное число разработчиков и тестировщиков с неограниченно высокой квалификацией, то это вовсе не проблема. В реальном мире ресурсы очень ограничены.
Вопросы на собеседованиях очень простые. Отличить человека, который может писать хороший код на С++, можно без выяснения тонкостей написания кода без привязки к разрядности. В конце концов, описание наиболее типичных проблем можно найти Гуглом за 10 минут.
Семинары есть, на них происходит обмен опытом по разным специфическим проблемам. Например, опытом разработки распределенных программ.
а) нанять нормальных программистов вместо клоуна-автора топика?
б) выкинуть С++ и написать на чем-нибудь более вменяемом?
А я еще был об ABBYY хорошего мнения. Оказывается, совершенно зря.
Но статья интересная и очень познавательная, спасибо!
Спасибо за статью. Про финт с COM+ не знал. Несколько раз за полгода столкнулся с проблемой необходимости использования стороннего 32-битного софта в 64-битном окружении. Решалось это оборачиванием компонентов веб-сервисами и запуском этих сервисов под 32бита.
:)
p.s.
Информация: мы не только Viva64 предлагаем, но и готовы проекты переносить на 64-битные системы в режиме аутсорса.