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

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

I>>>>Что с того ? Не хватит этих сиплюсников что бы покрыть все имеющиеся проекты.
ГВ>>>К чему это ты?
I>>Да к тому же что и раньше — нет и не будет никакого ренесанса С++ и подобной ерунды. Доля нативной разработки чуток увеличится и все. Сначала была мода на джаву и дотнет и потому многие кинулись чуть не драйвера и низкоуровненвый рендеринг писать на C#. Вот такие проекты отсохнут сами собой и за счет этого увеличится доля нативной разработки.

ГВ>Хм. Взаимопротиворечивые предложения detected.

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

ГВ>Рассуждатели по моей ссылке делают такие выводы:

ГВ>

Applying these conservative scaling
ГВ>projections, half of that ideal gain vanishes; the path to 8nm in
ГВ>2018 results in a best-case average 3.7 speedup; approximately
ГВ>14% per year for highly parallel codes and optimal per-benchmark
ГВ>configurations. The returns will certainly be lower in practice.

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

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

ГВ>Производительность CPU от диска не зависит.

Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.

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

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

Для кого он не является узким местом?

I>>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс.
ГВ>>Производительность CPU от диска не зависит.

I>Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.

Хорошо, согласен — для винды, офисных прилаг и всякой вижлы процессор не является узким местом. А что про остальной софт?

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

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

ГВ>Для кого он не является узким местом?

Для приложений.

I>>>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс.
ГВ>>>Производительность CPU от диска не зависит.

I>>Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.

ГВ>Хорошо, согласен — для винды, офисных прилаг и всякой вижлы процессор не является узким местом. А что про остальной софт?

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

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

I> I>> Есть осязаемая граница — если язык обладает полнотой по Тьюрингу и требует интерпретации или какой либо среды для выполнения, то использование его в нативной программе на другом языке автоматически делает эту програму смешаной.

I> H>А Ворд нативный софт (доки могут иметь полноценные скрипты)?

I> Не знаю, использует ли ворд скрипты внутри приложения. Доки это не ворд и нативного в них ничего нет.

Доки никто нативными не называет. Но доки могу содержать скрипты на Тьюринг-полном языке, а Ворд умеет их выполнять. Так Ворд нативный или нет?

I> >А, скажем, сервер БД с поддержкой хранимых процедур? Ты видимо думаешь, что это софт смешанный. Но этот софт нативный т.к. нативность определяется не наличием или отсутствием скриптового движка, а реализацией непосредственной функциональности софта.

I> Я определяею нативность в зависимости от реализации непосредственной функциональности софта. Если это нативный с++ , то прилага нативная. Если это нативный с++ вперемешку с js, vb или lua — это смешаное. Если же только js, то очевидно это вообще не нативное приложение.

Ну так вот смотри, сервер БД выполняет выборку из базы по запросу. При этом, он может выполнять хранимые процедуры на скриптовом языке. Это его непосредственная функциональность? Разумеется. Сервер при этом нативный? Нативный. Файлы БД это не сам сервер БД? Верно, но, скажем, ASP.NET это тоже не сам IIS. Другой пример — автоматизация нативных приложений (т.е. софт нативный, но имеет возможность автоматизации средствами скриптов в виде плагинов или расширений).

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

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

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

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

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

I>>>>>Включи адский райд из SSD и внезапно окажется, что винда ускоряется примерно 10 раз, а если нормальная шина и много памяти, то офисные прилаги и всякая вижла выскакивает аки notepad какой. Вот тебе и ренесанс.
ГВ>>>>Производительность CPU от диска не зависит.
I>>>Правильно. А вот производительность приложений — зависит. Потому на адском райде винда ускоряется примерно в 10 раз потому что узкое место ни разу не CPU.
ГВ>>Хорошо, согласен — для винды, офисных прилаг и всякой вижлы процессор не является узким местом. А что про остальной софт?

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

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

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

H>Доки никто нативными не называет. Но доки могу содержать скрипты на Тьюринг-полном языке, а Ворд умеет их выполнять. Так Ворд нативный или нет?

Я уже дал ответ — зависит от реализации самого ворда, а не того, что ворд умеет или не умеет выполнять.

I>> Я определяею нативность в зависимости от реализации непосредственной функциональности софта. Если это нативный с++ , то прилага нативная. Если это нативный с++ вперемешку с js, vb или lua — это смешаное. Если же только js, то очевидно это вообще не нативное приложение.

H>Ну так вот смотри, сервер БД выполняет выборку из базы по запросу. При этом, он может выполнять хранимые процедуры на скриптовом языке. Это его непосредственная функциональность? Разумеется.
Сервер при этом нативный? Нативный. Файлы БД это не сам сервер БД? Верно, но, скажем, ASP.NET это тоже не сам IIS. Другой пример — автоматизация нативных приложений (т.е. софт нативный, но имеет возможность автоматизации средствами скриптов в виде плагинов или расширений).

Если сервер БД свой непосредтсвенный функционал реализует в т.ч. на скриптах, то это смешаное приложение. Например если в консольном олдскульном WINAPI приложении на языке с напишу примерно следуеющее

void OnButtonClicked()
{
  ExecuteJavaScriptOperationOnContext(ctx, "ctx.fire(ctx.started).run().waitForExecution().fire(ctx.finished);");
}

ТО очевидно приложение сразу становится смешаным, т.к. использует джаваскрипт для реализации своего функционала.

И так же очевидно, что интерпретатор джаваскрипта писаный на чистом нативном С является нативным приложение хотя и умеет выполнять джаваскрипт. Зато если написать на этом скрипте приложение да пускать его через этот интерпретатор, приложение будет управляемым.

Так понятно ?


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

H>Непосредственная функциональность Ворда заключается в том числе и в корректной интерпретации документов имеющих скрипты.

Интерпретатор может быть и нативным, представь себе весь ужас.

>С игрушками точно также. Что такое игрушка? Грубо говоря, это движок способный корректно интерпретировать данные уровня и его скрипты.

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

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

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

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

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

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

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

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

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

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

I>Гуру это не тот кто знает всё, это тот кто знат намного больше средней массы и встречается в силу этого сильно редко. Ты просто не понял иронии. Бывает.
Это ты щас сам придумал? Сходи что ли в толковый словарь загляни.

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

ГВ>>>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев.
BBI>>Это синдром VladD2

I>Угу, и у Сиплюсников он проявляется слишком остро.

Что, опять у тебя острый приступ попаболи?

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

BBI>>Сайт при этом работает. Значит не такой уж и важный этот функционал.
I>Согласно букварю по логике твой сайт не требует этот функционал.
Спасибо Кэп!

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

I>>Гуру это не тот кто знает всё, это тот кто знат намного больше средней массы и встречается в силу этого сильно редко. Ты просто не понял иронии. Бывает.
BBI>Это ты щас сам придумал? Сходи что ли в толковый словарь загляни.

"Индийский термин, более или менее соответствующий слову учитель."

Учитель это, к слову, не тот, кто знает всё. Это тот кто знает намного больше средней массы да еще способен учить.

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

BBI>>>Сайт при этом работает. Значит не такой уж и важный этот функционал.
I>>Согласно букварю по логике твой сайт не требует этот функционал.
BBI>Спасибо Кэп!

Не за что. Вопрос, как ты вывел "не такой уж и важный этот функционал." остаётся открытым согласно тому же букварю. Надеюсь в твоем сайте больше одной странички ?

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

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

ГВ>>>>А то, право слово, такое впечатление, что раз вы что-то для себя выбрали, то все вокруг должны, во что бы то ни стало, признавать однозначное превосходство вашей платформы над другими для всех возможных и невозможных случаев.
BBI>>>Это синдром VladD2

I>>Угу, и у Сиплюсников он проявляется слишком остро.

BBI>Что, опять у тебя острый приступ попаболи?

Не у меня, а у тебя. Это ж ты выискиваешь синдромы.

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

I> H>Ну так вот смотри, сервер БД выполняет выборку из базы по запросу. При этом, он может выполнять хранимые процедуры на скриптовом языке. Это его непосредственная функциональность? Разумеется. Сервер при этом нативный? Нативный. Файлы БД это не сам сервер БД? Верно, но, скажем, ASP.NET это тоже не сам IIS. Другой пример — автоматизация нативных приложений (т.е. софт нативный, но имеет возможность автоматизации средствами скриптов в виде плагинов или расширений).

I> Если сервер БД свой непосредтсвенный функционал реализует в т.ч. на скриптах, то это смешаное приложение. Например если в консольном олдскульном WINAPI приложении на языке с напишу примерно следуеющее

I>

I> void OnButtonClicked()
I> {
I>   ExecuteJavaScriptOperationOnContext(ctx, "ctx.fire(ctx.started).run().waitForExecution().fire(ctx.finished);");
I> }
I>

I> ТО очевидно приложение сразу становится смешаным, т.к. использует джаваскрипт для реализации своего функционала.

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

new Window(320, 240);
Window.Add(new Button(10, 10, 'OK'));
Window.Show;

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

I> H>Непосредственная функциональность Ворда заключается в том числе и в корректной интерпретации документов имеющих скрипты.

I> Интерпретатор может быть и нативным, представь себе весь ужас.

А кто спорит?

I> >С игрушками точно также. Что такое игрушка? Грубо говоря, это движок способный корректно интерпретировать данные уровня и его скрипты.

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

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

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

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

CS>>Каждый DOM элемент в WPF это Common Language Runtime object instance.
CS>>Каждый event handler это тоже object instance. Properties там же — GC должен пройттись по ним всем для того чтобы собрать мусор. И т.д.
CS>>Десятки GCable things и набегают.
MM>Дык, не получается. Я приводил тест. Создано было более 5000 контролов, в каждом из которых визуальное дерево образуют еще 5-10 вложенных. GC потратил на себя ничтожное время. Да, загрузка медленная, но не из-за GC.

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

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

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

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

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

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

Короче — за все приходится платить — manageabilty не дешевое удовольствие.


CS>>Cравнивать WPF OO и OO HTML DOM можно и нужно. Ибо в принципе одну и ту же функцию выполняет. Практически любую WPF картинку можно воспроизвести в современном browser.
CS>>Вот с какой скоростью эти все хозяйства работают и может быть объективным критерием (одним из) оценки технологий.
CS>>Собственно об этом и говорим. Evernote в данном случае характерный пример ибо известны две имплементации: WPF и native — можно сравнивать на примерно одном и том же функционале.
MM>Пример с Evernote скоро станет, как Fire And Motion. Конечно, WPF сольет native. Тут без вариантов. Отсутствие интеропа, наличие огромного числа наработок для native кода. Evernote делали для .Net 3.5. Сейчас в WPF шрифты не плывут, известны разные ходы для увеличения пефоманса. И я бы хотел поглядеть на код, тогда смогу сказать, что Evernote-вцы выжали из WPF всё, что смогли. Недавно я установил их клиент: не сказать, что там мега-богатый UI. Не вижу причин, почему на нем WPF должно быть медленнее (исключая запуск .Net).

На самом деле UI сам по себе это вершина айсберга. Вот скажем представление предметной области — доступ к базе данных.
В native code я например могу спроецировать DB на память — т.е. получение access к данным это тривиальный pointer на память. Быстро и дешево (по памяти).
В случае с managed — пляски с бубном и GC cycles как результат. В native code свободы для оптимальных решений на порядки больше. Вот и результат.

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

G>Ну это в unmanaged так, а в .NET как раз правильное использование immutable позволяет увеличить быстродействие слегка увеличив расход памяти, а также сделать код многопоточным.

К сожалению, когда код действительно многопоточный и выполняется на многих ядрах, то shared state опять зло, рулят только локальные, по отношению к потоку, данные. Причем, эти данные надо расположить в памяти так, чтобы их страницы не пересекались. На плюсах в таких структурах я использую padding м/у разделяемыми данными, который заведомо больше размера страницы памяти.

Возвращаясь к shared state. Прямое его использование, без padding, на моем 6-ти-ядернике как раз показывает почти 3-х-кратную разницу в минус (!!!), если случайно на той же странице лежат мутируемые данные. А если на каждый shared state заводить с обоих сторон большой padding, то слишком жирно по памяти, чаще всего проще получить и сохранить локальные копии данных.


V>>А почему ты так уверен, что баг был не в коде реализации как раз агентов и очередей?
G>Может и там был, ведь пример не я придумал, а ГВ, а он как раз рассказал и показал все, кроме того места где собственно была ошибка.

V>>Какие ты еще знаешь способы реализации архитектур СМО, интересно?
G>Что такое СМО?

А это такая штука, лишь для которой очереди в классике и нужны.

G>См пост синклера на эту тему. Это просто случайное совпадение. Выставлять его за правило — глупо.

Где ты видел выставление за правило? Это был лишь контраргумент насчет того "а у вас программы падают!". Дык, плюсист всегда рад, когда нерабочая программа падает, а не продолжает делать вид, будто честно работает, как это принято в джаве и дотнете.

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

Смех-смехом, а сессионные объекты, как уже говорил рядом, это уровень 0 сложности, бо всё самое интересное делает низлежащая инфраструктура.

К тому же, наблюдал случай у коллег, что программа работала с ошибкой при какой-то там смене ситуации и клиент потерял энное кол-во тыщ нерусских денег за несколько минут... Лучше бы она просто упала нафик тогда. Но, к сожалению, ошибкой был не "проход по памяти и прочее из ада С++", а сугубо логическая ошибка.


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

Не льсти себе. Баги просто "бывают", даже при идеальной спецификации и идеальном процессе. Даже у самых что ни на есть мегакрутейших сферических программистов. А у нас с тобой и подавно. Поэтому-то интерес предоставляют не сами баги или причины их появления (кроме систематических причин), а гораздо интереснее пути попадания багов в продакшн. Прочувствуй разницу.

И да, поиск причины обнаруженного бага, по многолетнему опыту, никак не сложней задачи его обнаружения. Несмотря на все юнит-тестовые фреймворки или многоуровневые мегасистемы или подходы к микро- и макро-тестированию.

G>Ты слово "распределенно" правильно понимаешь? Один запрос все равно обрабатывает как можно меньшее количество машин. В идеале одна. Но производительность машин ограничена, а количество запросов может быть гораздо больше. А если вдруг надо шарить между ними какое-то состояние становится совсем интересно.

Да не расшаришь ты никакое состояние с требованием отклика в единицы микросекунд. Между процессорами и то сложно, разве что м/у ядрами получается. И да, узел, обрабатывающий информацию и принимающий решения, работает не так, как узел, выдающий информацию по запросу — поток информации тут противоположный.

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

кто при этом следит за освобождением памяти?
используются ли массивы в таком скрипте? проверяется ли при этом выход за границы массива?

H>

H>new Window(320, 240);
H>Window.Add(new Button(10, 10, 'OK'));
H>Window.Show;
H>

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

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

DG> кто при этом следит за освобождением памяти?
DG> используются ли массивы в таком скрипте? проверяется ли при этом выход за границы массива?

DG> H>

DG> H>new Window(320, 240);
DG> H>Window.Add(new Button(10, 10, 'OK'));
DG> H>Window.Show;
DG> H>

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

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

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

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


G>>См пост синклера на эту тему. Это просто случайное совпадение. Выставлять его за правило — глупо.

V>Где ты видел выставление за правило? Это был лишь контраргумент насчет того "а у вас программы падают!". Дык, плюсист всегда рад, когда нерабочая программа падает, а не продолжает делать вид, будто честно работает, как это принято в джаве и дотнете.

V>К тому же, наблюдал случай у коллег, что программа работала с ошибкой при какой-то там смене ситуации и клиент потерял энное кол-во тыщ нерусских денег за несколько минут... Лучше бы она просто упала нафик тогда. Но, к сожалению, ошибкой был не "проход по памяти и прочее из ада С++", а сугубо логическая ошибка.
Еще раз: это случайно что она падает, а managed продолжает работать. В большинстве случаев неправильная concurrency не приводит к падению ни managed, ни unmanaged программ.
Именно поэтому часто встраивают защиту от обращения из разных потоков, как в UI.

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

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

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

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

G>>Ты слово "распределенно" правильно понимаешь? Один запрос все равно обрабатывает как можно меньшее количество машин. В идеале одна. Но производительность машин ограничена, а количество запросов может быть гораздо больше. А если вдруг надо шарить между ними какое-то состояние становится совсем интересно.

V>Да не расшаришь ты никакое состояние с требованием отклика в единицы микросекунд. Между процессорами и то сложно, разве что м/у ядрами получается. И да, узел, обрабатывающий информацию и принимающий решения, работает не так, как узел, выдающий информацию по запросу — поток информации тут противоположный.
Вот я тебе об этом и говорю. В вебе время отклика важно всегда, далеко не всегда это микросекунды, но объем обрабатываемых данных огромный и одна машина не всегда справляется с нагрузкой.
Так что о недостатке воображения ты зря.

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