Преимущество в том, что если сразу писать код с расчетом на возможность его компилирования в разных системах для разных архитектур, не придется потом прибегать к подобным костылям, о которых повествует разработчик из Abbyy.

http://habrahabr.ru/company/abbyy/blog/101560/

А ведь еще Керниган и Пайк в своей книжке "Практика программирования" об этом писали. В результате *nix программы, обычно без особых проблем портируются и под 64 бита и под разные процессоры и даже под Windows. Не потому что они юниксовые (линуксовые), а из-за принятой культуры программирования. Так 64-битные дистрибутивы Linux с в итоге миллионами строк кода уже существуют много лет и даже были до появления x86-64 (amd64).

А с виндовой культурой масса людей огребла кучу проблем уже с портированием на 64 бита. Нативных 64-битных программ в мире Windows до сих пор мало. Да, если при написании программы сразу держать в уме, что ее может быть понадобится портировать куда-то, это увеличит трудозатраты. Хотя и не факт, может весь код в итоге будет стройнее.

Можно возразить, что в описываемом случае просто предлагается быстрое решение проблемы и в качестве такового сложно чего-то еще требовать, но сложно отделаться от ощущения, что проблема носит системный характер. И случай с Recognition Server не единственный. Я встречал примеры, когда код был очень жестко заточен на Win32 и его разработчики не только не думали, что кроме Win что-то еще может быть, но даже никогда не думали, что Windows, начиная с начала 90-х годов (WinNT 3.1) бывает не только 32-битной.

Хотя далее другой человек из Abbyy (aram_pakhchanian) кое-что поясняет

Позвольте встрять. Не по поводу темы конкретной статьи. Она описывает частный случай быстрого решения проблемы совместимости с 64-битным кодом. Нормальная техника, может помочь в конкретной ситуации, когда почему-то (неважно почему) существующий код оказалось не просто перенести на 64-бита.

Я по поводу кросс-платформенности вообще. Для коммерческих продуктов критична не только работоспособность, но и конкурентоспособность. В частности, для библиотек очень часто важна скорость работы. Для победы над конкурентами по этому параметру приходится применять всяческие уловки:

— ассемблер (редко, осторожно, только если реально помогает).
— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
— оптимизация файловых операций (тоже по-разному работает на разных платформах)
— компиляторные оптимизации и оптимизация кода под конкретный компилятор(работают ОЧЕНЬ по-разному для разных платформ, а на кросс-платформенном GCC до сих пор работают нестабильно).
— процессорные оптимизации (оптимизация под конкретный процессор).
— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)

В результате в течение достаточно длительного периода времени фокус команды состоит не в кросс-платформенности (от которой, в результате сложившегося на реальном рынке баланса платформ коммерческого толка немного), а в том, чтобы на конкретной, лидирующей платформе обеспечить преимущество над конкурентом. От этих действий код может стать сильно не-кроссплатформенным. В этом нет ничего страшного: вместо того, чтобы заставлять 50 человек писать кросс-платформенный код, часто имеет смысл сфокусировать их на качестве работы кода на одной, основной платформе, а еще двух людей потом попросить перенести этот код на другие платформы. Это дешевле и эффективнее с точки зрения достижения результата.

И еще: алгоритм распознавания очень непростой. Наверное, как-нибудь стоит рассказать о нем поподробнее на Хабре. Это не математика. Это скорее искусственный интеллект.

M>Хотя далее другой человек из Abbyy (aram_pakhchanian) кое-что поясняет
Какие-то он странные вещи написал.

M>— ассемблер (редко, осторожно, только если реально помогает).
Ассемблер зависит не от операционной системы, а от процессора. Так что вполне можно писать кроссплатформенно на ассебмлере.

M>— оптимизация аллокаций памяти (специфическая штука для конкретных платформ)
С++ и аллокаторы вполне способны инкапсулировать аллокацию платформо-независимо.

M>— оптимизация файловых операций (тоже по-разному работает на разных платформах)
Это что такое?

M>— процессорные оптимизации (оптимизация под конкретный процессор).
Не зависит от ОС.

M>— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
Пусть откроет для себя POSIX

Здравствуйте, Vamp, Вы писали:

M>>— ассемблер (редко, осторожно, только если реально помогает).
V>Ассемблер зависит не от операционной системы, а от процессора. Так что вполне можно писать кроссплатформенно на ассебмлере.
В разных Ос можно пользователю использовать разные регистры. По-разному складываются в стек переменные при вызовах функций и по-разному возвращаются.

M>>— оптимизация файловых операций (тоже по-разному работает на разных платформах)
V>Это что такое?
Использование виндового file mapping'а, например.

M>>— процессорные оптимизации (оптимизация под конкретный процессор).
V>Не зависит от ОС.
Зависит.

M>>— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
V>Пусть откроет для себя POSIX
На разных ОС разные планировщики потоков. Серверные ОС могут также различаться от десктопных работой с сетью. Ну и так далее.

N>В разных Ос можно пользователю использовать разные регистры. По-разному складываются в стек переменные при вызовах функций и по-разному возвращаются.
И это зависит от ОС? Это для меня новости. Ты уверен, что порядок укладки переменных зависит от ОС, а не от calling convention? И что регистры зависят от ОС?

N>Использование виндового file mapping'а, например.
А что, в UNIX mmap отменили?

M>>>— процессорные оптимизации (оптимизация под конкретный процессор).
V>>Не зависит от ОС.
N>Зависит.
Обоснуй.


N>На разных ОС разные планировщики потоков.
И что? Они и в одних и тех же ОС могут по-разному вести себя.

N>Серверные ОС могут также различаться от десктопных работой с сетью. Ну и так далее.
Например?

Здравствуйте, Michael7, Вы писали:

M>Преимущество в том, что если сразу писать код с расчетом на возможность его компилирования в разных системах для разных архитектур, не придется потом прибегать к подобным костылям, о которых повествует разработчик из Abbyy.
M>http://habrahabr.ru/company/abbyy/blog/101560/
Стандартный подход — вынести в отдельный процесс и использовать удалённые вызовы. Минусы в том, что код реально будет в другом процессе, так что просто указатель передать, к примеру, не получится. Или с callback'ами проблемы настанут.

Хороший пример подобного использования тут — это сам Линукс, 64-битное ядро может прекрасно работать с 32-битным userland'ом. Т.е. можно взять обычный 32-битный дистрибутив, воткнуть туда 64-битное ядро, и оно [почти] всё будет работать.

Ещё из аналогичных технологий есть D-BUS, который тоже позволяет делать межпроцессные вызовы. Ну и старушка CORBA.

Здравствуйте, Vamp, Вы писали:

V>И это зависит от ОС? Это для меня новости. Ты уверен, что порядок укладки переменных зависит от ОС, а не от calling convention? И что регистры зависят от ОС?
Открыл сейчас "How to optimize for the Pentium family of microprocessors" By Agner Fog, Ph.D.
И там есть разделы:
4.4 Register usage in 16 bit mode DOS or Windows
4.5 Register usage in 32 bit Windows
4.6 Register usage in Linux

К чему бы это?


N>>Использование виндового file mapping'а, например.
V>А что, в UNIX mmap отменили?
И они имеют абсолютно идентичный функционал?

M>>>>— процессорные оптимизации (оптимизация под конкретный процессор).
V>>>Не зависит от ОС.
N>>Зависит.
V>Обоснуй.
Например, пишешь ты на ассемблере под конкретный процессор. Выше я показал, что для разных ОС ассемблер надо специализировать.


N>>На разных ОС разные планировщики потоков.
V>И что? Они и в одних и тех же ОС могут по-разному вести себя.
Да, если можно выбирать планировщик потоков. В Windows XP, например, нельзя, в ней есть только один.

N>>Серверные ОС могут также различаться от десктопных работой с сетью. Ну и так далее.
V>Например?
Почитай про полуоткрытые сокеты.

V>>И это зависит от ОС? Это для меня новости. Ты уверен, что порядок укладки переменных зависит от ОС, а не от calling convention? И что регистры зависят от ОС?
N>Открыл сейчас "How to optimize for the Pentium family of microprocessors" By Agner Fog, Ph.D.

N>И там есть разделы:
N>4.4 Register usage in 16 bit mode DOS or Windows
N>4.5 Register usage in 32 bit Windows
N>4.6 Register usage in Linux

N>К чему бы это?
Ну во-первых, на вопрос о calling convention ты не ответил. Во-вторых, очевидно, что API Linux и Windows по-разному использует регистры. Но ассемблеру это по барабану. Если ты не зовешь API — а если зовешь, о кроссплатформенности можно забыть — то использование регистров в ТВОЕМ коде операционной системой не определяется.


N>И они имеют абсолютно идентичный функционал?
А что, есть существенные отличия?


N>Например, пишешь ты на ассемблере под конкретный процессор. Выше я показал, что для разных ОС ассемблер надо специализировать.
Нет, ты не показал.


N>Почитай про полуоткрытые сокеты.
И что конкретно мне прочитать про полуоткрытые сокеты? Я просто как-то считал, что я про них все знаю. Но если ты телепатически чувствуешь, что в моих знаниях пробел — укажи.

M>>— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
V>Пусть откроет для себя POSIX

А что, POSIX внезапно стал работать на Винде?

M>А что, POSIX внезапно стал работать на Винде?
Есть boost, он как posix.

M>>А что, POSIX внезапно стал работать на Винде?
V>Есть boost, он как posix.

как или posix?

M>как или posix?
Он не может быть posix, он boost. Это — кроссплатформенная реализация POSIX на С++.

M>>как или posix?
V>Он не может быть posix, он boost. Это — кроссплатформенная реализация POSIX на С++.

Думаю, когда ABBYY разрабатывался, boost'а еще и в помине не было или было в очень недостаточном количестве

M>Думаю, когда ABBYY разрабатывался, boost'а еще и в помине не было или было в очень недостаточном количестве
Примитивы POSIX ложатся на примитивы Win один-в-один, за исключением условных переменных, которых долгое время не было — но и их несложно сделать на эвентах. Я думаю, что простейшую кроссплатформенную обертку над вызовами win с предоставлением posix-интерфейса я сделаю примерно дня за три. И любой другой программист тоже. Так что было бы желание.

M>>Думаю, когда ABBYY разрабатывался, boost'а еще и в помине не было или было в очень недостаточном количестве
V>Примитивы POSIX ложатся на примитивы Win один-в-один, за исключением условных переменных, которых долгое время не было — но и их несложно сделать на эвентах. Я думаю, что простейшую кроссплатформенную обертку над вызовами win с предоставлением posix-интерфейса я сделаю примерно дня за три. И любой другой программист тоже. Так что было бы желание.

B что потом делать с этой оберткой, если используются не только примитивы?

Здравствуйте, Cyberax, Вы писали:

C> M>Преимущество в том, что если сразу писать код с расчетом на возможность его компилирования в разных системах для разных архитектур, не придется потом прибегать к подобным костылям, о которых повествует разработчик из Abbyy.
C> M>http://habrahabr.ru/company/abbyy/blog/101560/

C> Стандартный подход — вынести в отдельный процесс и использовать удалённые вызовы. Минусы в том, что код реально будет в другом процессе, так что просто указатель передать, к примеру, не получится. Или с callback'ами проблемы настанут.

+1. Тоже сразу про RPC подумал.

Здравствуйте, Mamut, Вы писали:


M>>>— поддержка многопроцессорной архитектуры, многопоточности и проч. (тоже по-разному работает на разных платформах и процессорах)
V>>Пусть откроет для себя POSIX

M>А что, POSIX внезапно стал работать на Винде?

ВНЕЗАПНО POSIX в WinNT был, вплоть до WinXP. Видишь, ты был не в курсе, видимо этот POSIX действительно очень нужен

M>B что потом делать с этой оберткой, если используются не только примитивы?
В posix threads есть только примитивы, больше там и нет ничего.

IID>ВНЕЗАПНО POSIX в WinNT был, вплоть до WinXP. Видишь, ты был не в курсе, видимо этот POSIX действительно очень нужен
POSIX — просто кроссплатформенный стандарт. Собственно, в винде он есть, например, в виде буста.

Здравствуйте, Cyberax, Вы писали:

C>Т.е. можно взять обычный 32-битный дистрибутив, воткнуть туда 64-битное ядро, и оно [почти] всё будет работать.

Очень в этом сомневаюсь. Предлагаю провести эксперимент. Имеем: скачанные и развёрнутые в виртуалках дистрибутивы OpenSUSE x86 и x64. Я не линуксоид, поэтому "взять и воткнуть ядро" не осилю. Распиши плз. по шагам, как перетыкается ядро, и я с удовольствием проверю процитированный тезис.