MX -- ALEX kalin Теперь про GT.M
Абсолютно бесплатная СУБД под Linux. Наличие исходников СУБД позволяет вносить свои изменения в ядро базы, что с успехом и используют разработчики. 100% М подобная база. Использование бесплатных надстроек других производителей позволяет использовать на ней объектный подход в построении структур данных. Для поиска по таким данным имеются свои оригинальные не SQL методы доступа к данным, которые более приближены к M структурам, а не реляционным SQL таблицам.
Насчет отладчика и редактора программ , так имеющейся к GT.M редактор Serenje с точки зрения отладчика рутин по своим возможностям намного лучше аналогичного в Cache.
Насчет WEB приложений под GT.M, имеется тьма примеров, как это сделать. Причем по своим возможностям они ни в чем не уступают CSP.

Если нужны подробности, всегда готов ответить

Александр

два больших минуса GTM
- медленнее чем CACHE - по нашим замерам - в разы
- нет варианта под WINDOWS

Абсолютно согласен. Более того, я очень сомневаюсь в каких-либо сдвигах в сторону ускорения
в последующих релизах. Что касается Serenjie, как отладчика, то кому как. Мне так и Break
хватает за глаза.

kalin>два больших минуса GTM
>- медленнее чем CACHE - по нашим замерам - в разы
Все идет из настроек
Тоже, что сказать, что windows работает быстрее Linux

Настройки здесь не при чем. Free-M под Linux тоже работает быстрее GT.M

kalin
В GT.M программы компилируются в исполняемый машинный код в отличие от Cache, где они лежат в P коде и работают под уравлением интерпретатора Cache. Так , что это утверждение некорректно

С какой версии GT.M программы стали компилироваться в ассемблер? И когда GT.M перестал
быть интерпретируемой системой, что в корне противоречит стандарту?

kalin>С какой версии GT.M программы стали компилироваться в ассемблер? И когда GT.M перестал
>быть интерпретируемой системой, что в корне противоречит стандарту?

Linux на файлы в GT.M с расширением .o пишет, что это объектный код
Он может писать все, что угодно. Но это P-код, не особо отличающийся от изначального MSM.
Который, конечно же, обрабатывается интерпретатором GT.M.
У меня, кстати, есть подозрение, что Linux ориентируется на расширение "o". Впрочем, это
конечно неважно. Важно другое - не стоит рекламировать систему, не зная как она работает.

kalin>Настройки здесь не при чем. Free-M под Linux тоже работает быстрее GT.M
Еще как причем. Нстройки требует как сам Linux, так и правильно сгенерированная база под него
Это о какой базе идет речь? О GT-M? Это уже "база данных", а не СУБД? С каких это пор?
Я вас уверяю, что Free-M без настроек, каковых в нем-таки и нет почти, абсолютно
интерпретируемый, то есть не имеющий p-кода вообще, будет работать быстрее, чем
совершенно правильно настроенный GT.M

LittleCat MX -- ALEX
два больших минуса GTM
- медленнее чем CACHE - по нашим замерам - в разы
- нет варианта под WINDOWS
Насчет медленнее, утверждение очень спорное, мне известны другие результаты экспериментов :-)

Можно взглянуть? :)

LittleCat
Александр правильно сказал, что все упирается в настройки (как впрочем и во многих других системах :-)) У GT.M есть в этом плане серьезное преимущество, можно управлять размером блоков базы, размерами записей и для каждой базы индивидуально настраивать кэш, что позволяет оттюнить систему под конкретные особенности прикладной системы. Про возможные тормоза я уже писал где-то выше, это неудачная по скорости реализация $query(). Но это тоже исправимо, поскольку имеется исходный код :-)

Причем тут $query? Я говорю об общей тормознутости системы. Даже без обращений к глобалям.

LittleCat
Насчет машинных команд, эта фича была заложена в GT.M при рождении. Т.е. действительно программы компилятся в машинный код.

Поподробнее пожалуйста, если не трудно. Насколько я понимаю в компьютерах, машинный код
исполняет операционная система, в нашем случае Linux. Я ничего не путаю? Размеры файликов
с расширением .o не позволяют предполагать, что к ним на этапе компиляции присобачили
половину исполняемых модулей GT.M. А коли так, каким же образом осуществляется не только
согласование одновременной работы этих программ, обращение к глобалям, но и интерактивная
с ними работа? Я имею в виду хотя бы Break.

Кстати, проверяется это элементарно. Попробуйте запустить хоть один из этих файликов.
Если он заработает, то я признаю свою неправоту. ;)

LittleCat
А насчет противоречий стандарту, в каком месте написано, какова должна быть внутренняя реализация ??? Просто большинство М-систем реализовано с использованием Р-кода, но в разных реализациях устройство этого кода разное, и Р-код из MSM не будет исполняться в Cache, и наоборот, так что тут Вы сильно заблуждаетесь.

Только не надо, пожалуйста, пытаться ловить меня на противоречиях. :) P-код P-кодом,
а M-стандарт - это интерпретируемая система. Единственное известное на сегодня
исключение - компилятор M2C O'Kane, который M можно назвать с ба-а-альшой натяжкой.
Я опять обращаю внимание, что выражение "машинный код" в простонародье подразумевает
ассемблер, сиречь набор команд процессора, а не P-код.

LittleCat
Sergei Obrastsov
Важно другое - не стоит рекламировать систему, не зная как она работает.

Справедливо и обратное утверждение, не стоит ругать систему, не зная, как она работает :-)
Я опять повторюсь - не стоит пытаться меня поймать. Я возился с GT.M полтора года и прекрасно
представляю как оно устроено. И когда система с p-кодом серьезно тормозит по сравнению
с голым интерпретатором в лице, скажем, Free-M - это что-нибудь да значит.

kalinКак во Free-M реализован механизм транзакций ? Как во Free-M реализован размер ключей и глобалей ?

А разве я что-то говорил о транзакциях и глобалях? Free-M не предназначен для использования
в качестве сервера для тысяч пользователей и террабайтов данных. Но речь об этом и не шла.
Я говорил о банальной скорости работы в однопользовательском режиме. Медленнее - это
медленнее. Ни примите за рекламу, но Cache быстрее Free-M. :)

Hampster-MumpsterНастоящий ли это obj-код? Предоставим слово авторам GT.M:
http://www.fidelityinfoservices.com/user_documentation/AdminOpsUNIX/UNIX_A_O/run_gtm.htmlDepending on the platform, the format of M object modules may not be the standard object file format, so you may not be able to use the UNIX ld utility to link all M .o files together. GT.M, however, automatically links and executes these files.

Интересно, где здесь ответ на вопрос "Может ли этот код запускаться без участия GT.M?"?
Ответа такого нет, потому как этот код, можете называть его "объектным", "по-настоящему
объектным", "п-кодом" или как-то еще, НЕ выполняется без участия run-time system GT.M
То, что их при этом можно линковать вместе - просто замечательно, что совершенно
не меняет картины в целом. GT.M - интепретируемая система со всеми вытекающими отсюда
последствиями.

документация
The Run-Time System

A GT.M programmer can execute an M routine from the shell or interactively,
using the M commands from Direct Mode.
The run-time system executes compile-as-written code as long as it does not
encounter the compile-time errors. If it detects an error, the run-time system
suspends execution of a routine immediately and transfers control to Direct Mode
or to a user-written error routine.

kalin>А разве я что-то говорил о транзакциях и глобалях? Free-M не предназначен для использования
>в качестве сервера для тысяч пользователей и террабайтов данных. Но речь об этом и не шла.
О чем речь тогда вообще идет ?

О том, что GT.M медленнее Cache. И медленнее другой реализации M, которая вообще без
компилятора. Безотносительно транзакций. Просто по исполняемости кода. Я не делаю
никаких выводов и никого никуда не зову. Просто привожу свое мнение.

kalin
Мы говорим про нормальную СУБД на много одновременных пользователей. Такая СУБД должна поддерживать стандартные технологии, присущие современным СУБД. К таковым относится механизм транзакций. Естественно, такие механизмы будут влиять на скорость работы СУБД. Поэтому надо рассматривать работы СУБД в комплексе, а неотдельные какие-то фрагменты выхватывать и говорить, что это круто. Любит у нас InterSystems сравнивать ORACLE и Cache, насколько Cache круче ORACLE, хотя в Cache не реализовано и половина механизмов работы с СУБД, которые есть в ORACLE. Глупо все это и несолидно.

Я вам про скорость работы кода говорю, а вы мне про транзакции. Нисколько не сомневаюсь,
что ACID в GT.M реализован блестяще, а в Cache пока еще криво. Только вот до транзакций
мы еще пока не дошли, а уже тормозит и серьезно.

kalinВот написал небольшой тест, столь любимый Intersystems
f i=1:1:1000000 s ^A(i)=i
В Cache 5.20 под Windows (seleron 2.8) выполняется 4 сек
В GT.M 5.1 (linux Fedora, seleron 2.8) выполняется 4 сек
Теперь делаем наоборот
f i=1:1:1000000 s a=^A(i)
В Cache под Windows (seleron 2.8) выполняется 2 сек
В GT.M (linux Fedora, seleron 2.8) выполняется 1 сек
Так, что GT.M по чтению справился реально быстрей
А на запись в базу явно влияет механизмы реализации работы с базой, которые в GT.M отличаются от Cache.

На запись в базу явно влияет размер кэша. :)

Cache 5.0.11, кэш - 300Mb, AMD 1.87

test #1 - (с предварительным удалением ^A, конечно)
0.7-0.8 сек.
test #2
0.5-0.6 сек.

Hampster-MumpsterНасчет тестирования когда-то была полемика в соседнем форуме, многое из сказанного здесь

/topic/9021&pg=11#339482

до сих пор актуально. Вот и в нашем случае: что мы сравниваем? движки БД (global managers) - к тому же в однопользовательском режиме - или сервера БД в целом? Если второе, подойдут только реальные задачи или "навороченные" тесты, максимально к ним приближенные.
Странные вы какие-то. Я который раз говорю про скорость выполнения кода, а вы мне про
движки БД. Впрочем, если код выполняется медленнее, то и движок будет работать не быстрее.
А вот про транзакции верю, потому как подход такой, основательный, чувствуется школа DEC.