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

DG> H>Это все частности. Смысл их обсуждать?

DG> именно эти частности — и дают отличие native от managed.
DG> если в скрипте есть проверка на выход за границы — это уже managed, если есть gc — то тем более.

А скрипты никто нативными и не называет

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

CS>Проблема не в самом GC как процессе сборки мусора. А скорее в самой архитекуре managed объектов обусловленных нуждами этого GC. Там где в native code я могу например выделить память под контейнер одним куском
CS>

CS>struct items {
CS>  ...
CS>  int _n_items;
CS>  T   _items[0];
CS>}
CS>

CS>и получу оптимальную структуру с точки зрения data caching в процессоре и пр.

CS>В managed средах ты просто вынужден писать нечто типа
CS>

CS>class items {
CS>  ...
CS>  int _n_items;
CS>  T[] _items;
CS>}
CS>

CS>увеличивая (в два раза) indirection levels.

Открой для себя fixed arrays


CS>Короче — за все приходится платить — manageabilty не дешевое удовольствие.
Ты не путай managed и safe. Не все что managed является safe, а вот наоборот скорее всего является.


CS>В native code я например могу спроецировать DB на память — т.е. получение access к данным это тривиальный pointer на память. Быстро и дешево (по памяти).
Особенно когда БД находится на другом сервере
Вообще-то БД оптимизируют считывание с диска, это гораздо более дорогая операция, чем копирование памяти. А если получать указатель на замапленные файлы данных, то придется читывать все.

А мапить обычные файлы в managed можно.

CS>В случае с managed — пляски с бубном и GC cycles как результат. В native code свободы для оптимальных решений на порядки больше. Вот и результат.
И ты сходу привел решение, далекое от оптимальности

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

H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:

Без разницы. Обязанность связывания компонентов ничем не отличается от других обязанностей.

H>Приложение использующее такой скрипт не будет являться смешанным.

Будет. не совсем ясно, на каком основании ты выделил обязанность связывания компонентов в какой то особый класс .

I>> Вот раз "и его скрипты", то следовательно приложение смешаное.

H>Его — уровня. Скрипты, тем более в игрушках, обычно, очень высокоуровневые т.е. осуществляющие, по большей части, связку нативного кода, а не реализацию непосредственной функциональности. Потому такие приложения считаться даже смешанными, не то что управляемыми, не могут.

Во первых, про связку, см. выше.
Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.

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

I>>>>>Да ради бога. Процессор не является узким местом, а потому нет разницы, 14% в год или 99% или 1.5%.
ГВ>>>>Для кого он не является узким местом?
I>>>Для приложений.

ГВ>>Для каких? Ты сейчас говорил только о настольных, притом нативных.

I>десктоп, веб, серверные приложения всяких сортов.

ИМХО, это упрощенчество. Я не спорю, что принято не оглядываться на расходуемые процессорные мощности, но это не означает, что они не имеют значения вообще.

I>Процессор критичен для HPC и всякая всячина связаная с обработкой изображений, видео, звука и тд.

И оно как раз нередко выполняется именно на серверах — перекодирование аудио/видео, не говоря уж об HPC.

I>>>Смотря какой. Судя по тому, что в последние годы менеджед появился даже в HPC, не все так просто.

ГВ>>HPC — это high performance computing? Если так, то где там появился managed?

I>например
I>http://www.google.com/search?q=java+hpc&sourceid=ie7&rls=com.microsoft:en-us:IE-Address&ie=&oe=

Забавный комментарий к этой статье:

akuznetsov12 октября 2010, 11:49
А на сколько в java по сравнению с C производительность теряется?

ahriman12 октября 2010, 12:12
Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.
Этому вопросу отдельный пост будет посвящён с более оптимизированными программами (что очень важно, так как в этой программе на Java не использованы потоки, а они способны резко увеличить производительность), графиками и диаграммами.

Так что да, не всё так просто.

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

G>В вебе время отклика важно всегда, далеко не всегда это микросекунды, но объем обрабатываемых данных огромный и одна машина не всегда справляется с нагрузкой.

Микросекунды и "далеко не всегда это микросекунды" — это уже качественное различие между ПО. Я серьёзно: то, что вполне укладывается в "не микросекунды" абсолютно не допустимо там, где речь заходит о микросекундах.

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

ГВ>>Мне вот интересно: программа на Lisp по твоей классификации — она нативная, смешанная или управляемая?

I>Управляемая. Для нативной нужны указатели всякие, прямой доступ к ос и тд.

;;;;
;;;; Common Lisp IDENTITY function.
;;;;
(defasm identity (obj)
{
push ebp ;; link new frame
mov ebp, esp
cmp ecx, 1 ;; check number of arguments
je short :next
callp _wrong-number-of-args-error
:next
mov eax, [ebp + ARGS_OFFSET] ;; return argument in eax
mov ecx, 1 ;; returning a single value
pop ebp ;; unlink stack frame
ret
})

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


G>Есть тестирование чтобы предотвратить случайные ошибки, есть управляемые среды, которые просто не допускают некоторые классы ошибок.

Эээ... Ты сейчас понял хоть, что сказал? Управляемая среда не может "не допустить ошибку" выхода за пределы, например, она честно выплюнет баг... И если повезет — во время тестирования. Но в плане "недопущения" — это фантазии.

К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет.


G>Процент багов, связанных с неправильным кодированием, попадающими в production очень низок.

Процент от объема логики или от чего?


V>>И да, поиск причины обнаруженного бага, по многолетнему опыту, никак не сложней задачи его обнаружения. Несмотря на все юнит-тестовые фреймворки или многоуровневые мегасистемы или подходы к микро- и макро-тестированию.
G>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна).

Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования.


G>А разницы между потоком и запросом почти нету на самом деле. Можно одно свести к другому и наоборот.

Нельзя. Каждый запрос — локален, независим от остальных. Системы, обслуживающие в основном только запросы, очень масштабируемы уже на уровне целевых endpoint. В отличие от них, в системе принятия решений поступающие данные не являются независимыми, а влияют на состояние.

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


H>>Это все частности. Смысл их обсуждать?

DG>именно эти частности — и дают отличие native от managed.
DG>если в скрипте есть проверка на выход за границы — это уже managed, если есть gc — то тем более.
DG>дальше этот managed быть тотальным (все операции проверяются), или не тотальным (проверяется только часть операций, и есть операции которые позволяют выйти за пределы массива и выделить память в обход gc)

То есть D managed язык?

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

I>>десктоп, веб, серверные приложения всяких сортов.

ГВ>ИМХО, это упрощенчество. Я не спорю, что принято не оглядываться на расходуемые процессорные мощности, но это не означает, что они не имеют значения вообще.

"принято не оглядываться " — это миф. Принято учитывать реальные приоритеты. И вот здесь экономия процессора не всегда имеет приоритет. Экономия IO как правило имеет куда более высокий приоритет.

ГВ>ahriman12 октября 2010, 12:12
ГВ>Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.

Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки. На регулярных выражениях и то получается казус — движки с джытом и GC рвут с++ в хлам.

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


I>>Управляемая. Для нативной нужны указатели всякие, прямой доступ к ос и тд.

FR>

FR>;;;;;
FR>;;;;; Common Lisp IDENTITY function.
FR>;;;;;
FR>;(defasm identity (obj)
FR>;{
FR>;push ebp ;; link new frame
FR>;mov ebp, esp
FR>;cmp ecx, 1 ;; check number of arguments
FR>;je short :next
FR>;callp _wrong-number-of-args-error
FR>;:next
FR>;mov eax, [ebp + ARGS_OFFSET] ;; return argument in eax
FR>;mov ecx, 1 ;; returning a single value
FR>;pop ebp ;; unlink stack frame
FR>;ret
FR>;})
FR>;

FR>

А какой это из лиспов такое умеет ? Неужели все ?

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

I>А какой это из лиспов такое умеет ? Неужели все ?

SBCL, Corman Lisp.

Corman вообще практически все возможности нативных языков имеет:
http://www.cormanlisp.com/features.html

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

I>>>десктоп, веб, серверные приложения всяких сортов.
ГВ>>ИМХО, это упрощенчество. Я не спорю, что принято не оглядываться на расходуемые процессорные мощности, но это не означает, что они не имеют значения вообще.

I>"принято не оглядываться " — это миф. Принято учитывать реальные приоритеты. И вот здесь экономия процессора не всегда имеет приоритет. Экономия IO как правило имеет куда более высокий приоритет.

Зачастую — да. Только это никак не противоречит тому, что я написал.

ГВ>>ahriman12 октября 2010, 12:12
ГВ>>Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.

I>Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки. На регулярных выражениях и то получается казус — движки с джытом и GC рвут с++ в хлам.

Для HPC актуальна performance. Ваш К.О.

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

ГВ>>Мне вот интересно: программа на Lisp по твоей классификации — она нативная, смешанная или управляемая?

I>Управляемая. Для нативной нужны указатели всякие, прямой доступ к ос и тд.

Кстати и питон нативный язык:

from ctypes import *

libc = CDLL("libc.so.6")

BufSize = 100
Buf = libc.malloc(BufSize)

libc.sprintf(Buf, "BufSize = %d", c_int(BufSize))
libc.printf("%s\n", Buf)

libc.free(Buf)

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

I> H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:

I> Без разницы. Обязанность связывания компонентов ничем не отличается от других обязанностей.

Я не про обязанность, я про выполняемую работу.

I> H>Приложение использующее такой скрипт не будет являться смешанным.

I> Будет. не совсем ясно, на каком основании ты выделил обязанность связывания компонентов в какой то особый класс .

Заостряя внимание на связывании кода, я даю тебе понять, что непосредственная функциональность приложения обеспечивается не скриптом, а нативным кодом.

I> H>Его — уровня. Скрипты, тем более в игрушках, обычно, очень высокоуровневые т.е. осуществляющие, по большей части, связку нативного кода, а не реализацию непосредственной функциональности. Потому такие приложения считаться даже смешанными, не то что управляемыми, не могут.

I> Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.

Я же не зря сказал о том, что игрушечные скрипты очень высокоуровневые (подумай над этим). Разумеется, использование скриптов очень удобно т.к. позволяет отстроить игровую логику и законы сильно быстрее, чем непосредственно "вкомпилированные" алгоритмы, но это все равно не более чем клеевой слой. Ты можешь сам глянуть на Lua-скрипты от FarCry и посмотреть, много ли работы они делают.

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

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

I>>А какой это из лиспов такое умеет ? Неужели все ?

FR>SBCL, Corman Lisp.

Я про такой ничего не знал. Как бы под Lisp обычно подразумевают Common Lisp

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

ГВ>>>ahriman12 октября 2010, 12:12
ГВ>>>Примерно в 1-1.5 раз в случае с целыми числами и 1.5-2 — плавающими.

I>>Это фигня какая то. Для HPC актуальны высокоуровневые оптимизации, а не тупо числодробилки. На регулярных выражениях и то получается казус — движки с джытом и GC рвут с++ в хлам.

ГВ>Для HPC актуальна performance. Ваш К.О.

То есть, твоя цитата с хабры смысла не имеет

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

FR>Кстати и питон нативный язык:

Мне лень развивать эту ветку в такой форме, потому я готов согласиться на что угодно, наприме что все языки — нативные, все языки — менеджед, все языки — интерпретируемые и тд и тд.

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

I>Я про такой ничего не знал. Как бы под Lisp обычно подразумевают Common Lisp
SBCL — это common lisp и есть.

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

I>> H>Так для реализации или для связки? Скрипты, обычно, для связки используются, а не для реализации. Ниже пример связки:

I>> Без разницы. Обязанность связывания компонентов ничем не отличается от других обязанностей.

H>Я не про обязанность, я про выполняемую работу.

Это одно и то же. Если код выполняет работу связывания компонентов, то это значит, что у этого кода обязанность — связывание компонентов.

I>> Будет. не совсем ясно, на каком основании ты выделил обязанность связывания компонентов в какой то особый класс .

H>Заостряя внимание на связывании кода, я даю тебе понять, что непосредственная функциональность приложения обеспечивается не скриптом, а нативным кодом.

Эдак мы дойдем до того, что всю работу делают ОС, процессор и тд, а стало быть все софтины нативные.

I>> Во вторых, больших игра вся игровая динамика, AI и много чего еще пишется именно на скрипте. Т.е. поведение каждого юнита, группы юнитов, оружие и тд и тд. Нативный движок предоставляет рендеринг, физику и кое какие мелочи.

H>Я же не зря сказал о том, что игрушечные скрипты очень высокоуровневые (подумай над этим).

Ты лушче сам думай. Предполагается, если ты увидел изъян в рассуждениях, то можешь продемонстрировать это некоторым тестом. Если такого нет — сэкономь лучше траффик

>Разумеется, использование скриптов очень удобно т.к. позволяет отстроить игровую логику и законы сильно быстрее, чем непосредственно "вкомпилированные" алгоритмы, но это все равно не более чем клеевой слой. Ты можешь сам глянуть на Lua-скрипты от FarCry и посмотреть, много ли работы они делают.

Неважно, много или мало. Главное что взаимодействие это очень важная часть и её нельзя выбросить.

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

I>>Я про такой ничего не знал. Как бы под Lisp обычно подразумевают Common Lisp
DE>SBCL — это common lisp и есть.

Хорошо, все программы — нативные, все программы — менеджед, все программы — интерпретируемые