COMConnector для 64 разрядных приложений

[Old]

Коллеги.
Похоже COMConnector 3.0 не совместим с 64 разряднымы приложениями.
Я прав

[George Nordic]

Да. Ждите 2009.

Сервер, кстати, работает - я запускал 4,0 на х64. Однако скорость была крайне низкой. Эмуляция 32х разрадного режима сожрала все преимущество платформы.
С Уважением,

Георгий

[gl00mie]

Цитата:

Сообщение от George Nordic

Да. Ждите 2009.

Что значит "ждите"? Оно уже давно есть, и даже SP1 успел выйти. То, что пока нет локализации приложения для России, не мешает испытать в действии COM-коннектор (от которого, к слову, MS обещает уже отказаться в пользу .NET-варианта).

Цитата:

Сообщение от George Nordic

Сервер, кстати, работает - я запускал 4,0 на х64.

Подождите, а при чем тут сервер? Я так понимаю, изначально речь шла о том, чтобы дергать COM-коннектор из приложения под x64, а не о том, чтобы просто запускать 32-разрядное ядро того же AOS'а под 64-битной ОСью, к примеру. 32-разрядные (x86) приложения под x64-виндами на соотв. платформе работают и так, иначе кому бы нужна были эти x64-винды.

Цитата:

Сообщение от George Nordic

Однако скорость была крайне низкой. Эмуляция 32х разрадного режима сожрала все преимущество платформы.

О какой эмуляции идет речь? Вроде в виндах под x64 нет никакой эмуляции при выполнении x86-приложений, есть лишь thunk'и для вызова из них 64-разрядного кода ядра, ну и что-нить аналогичное для вызова из ядра 32-разрядных callback-функций приложения, а эмуляции, как на IA64, там afaik нет.

[George Nordic]

Цитата:

Сообщение от gl00mie

Что значит "ждите"? Оно уже давно есть, и даже SP1 успел выйти. То, что пока нет локализации приложения для России, не мешает испытать в действии COM-коннектор (от которого, к слову, MS обещает уже отказаться в пользу .NET-варианта).

Продажа DAX 40 на территории Российской Федерации запрещена. Может быть использованна только виртуальная машина, да и то - для обучения. Вот что означает "ждите".

Остальное просто рассказал, относилось к серверу, не к СОМу.

Спасибо, не знал, что нет эмуляции 32х разрядного режима, думал, есть

С Уважением,
Георгий

[somebody]

2 George Nordic

Цитата:

Сообщение от George Nordic

Эмуляция 32х разрядного режима сожрала все преимущество платформы.

Это очень интересно. Поскольку обычно "эмуляция" (назовём её так) не оказывает такого трагического действия, замедление должно укладываться в единицы процентов. Но только если имеется много памяти. Поэтому вопрос: а сколько памяти (RAM) было на этом сервере? И что-либо ещё не занимало ли память?

Цитата:

Сообщение от gl00mie

есть лишь thunk'и для вызова из них 64-разрядного кода ядра

Thunk'и - преобразование 32-битных структур в 64-битные для вызова 64-битного кода ядра. Для вызова в итоге надо в 2 раза больше памяти (по сравнению с 32-битными вызовами), и если RAM в принципе мало, могут теоретически возникнуть тормоза. Но это всё маловероятно, вот и интересен объём (доступной) памяти на упомянутом АОС...

[George Nordic]

Прошу прощения. Платформа была Itanium II. http://www.seneca2.ru/archive_370_19932

С Уважением,
Георгий

[gl00mie]

Цитата:

Сообщение от somebody

Thunk'и - преобразование 32-битных структур в 64-битные для вызова 64-битного кода ядра. Для вызова в итоге надо в 2 раза больше памяти (по сравнению с 32-битными вызовами), и если RAM в принципе мало, могут теоретически возникнуть тормоза. Но это всё маловероятно

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

[Old]

Реализовали доступ через ADO. Пришлось пожертвовать бизнес логикой...

[gl00mie]

Ну зачем сразу жертвовать бизнес-логикой? Есть же XML Web-службы, в которые можно "завернуть" вызовы Business Connector'а, - они не чувствительны к "разрядности" клиентских приложений.

[somebody]

Цитата:

Сообщение от gl00mie

обычно через стек передается относительно немного данных (в худшем случае до сотни байт)

Размер стека кратен странице, т. е. в любом случае не меньше 4 Кб (для 32 бит), при вызовах API из потока рекомендуется от 64 Кб. Т. е. о нескольких сотнях байт речь идти не может. Умолчание вообще 1 Мб.
Т. е., похоже, проблемы thunk'ов 32->64 могут возникнуть при недостаточных размерах стека 32-битного потока?.. Точнее, при размерах, не рассчитанных на выполнение в 64-битной среде (при вызовах API-функций, богатых параметрами)? Резерв-то указывается в исполняемом файле...

[gl00mie]

Чего-то какая-то путаница возникла, по-моему...

Цитата:

Сообщение от somebody

Размер стека кратен странице, т. е. в любом случае не меньше 4 Кб (для 32 бит), при вызовах API из потока рекомендуется от 64 Кб. Т. е. о нескольких сотнях байт речь идти не может. Умолчание вообще 1 Мб.

При чем тут размер стека и "несколько десятков-сотен байт на один вызов"?

Цитата:

Сообщение от somebody

Т. е., похоже, проблемы thunk'ов 32->64 могут возникнуть при недостаточных размерах стека 32-битного потока?..

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

[somebody]

Цитата:

Сообщение от gl00mie

При чем тут размер стека и "несколько десятков-сотен байт на один вызов"?

Я о том, что добавляемые "сотни байт" ни к чему учитывать, если они поместились в выделенный к настоящему моменту стек. Только если ранее выделенную память стека пришлось нарастить из-за этих сотен байт... В общем, здесь не путаница, просто разное понимание нами смысла "накладных расходов".

Цитата:

Сообщение от gl00mie

при вызове через thunk используется один и тот же стек вызывающего потока, т.е. отдельный какой-нить стек мегабайтного размера (или сколько там прописано в PE-заголовке) не создается.

То есть размер 32-битного стека не важен... Тогда понятно...