S>>Не это? https://msdn.microsoft.com/en-us/library/dn877695(v=vs.110).aspx
EP>При чём тут это "Transforms a two-dimensional vector by a specified 4x4 matrix."
Да смысл в том, что для типичных алгоритмов куча библиотек. Если нужна скорость то через интероп можно подключиться к нативным библиотекам.
Еще раз повторю, что сравнивать нужно реальные массовые приложения. Например Asp.Net как по скорости работы так и по скорости разработки.
Это будет правильно. Иногда дешевле купить железо, чем платить за разработку. Заметь сколько сайтов на PHP
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>Я уже приводил, ссылку что самые востребованные программисты это 1С овцы. EP>>Водители ещё более востребованы, и что из этого? S> А разве водители это программисты?
А причём востребованность?
S>>> Я к тому, что для каждого языка свои задачи. EP>>А я разве говорил обратное? S>>>А порядок скоростей давно известен. EP>>Видимо не всем — иначе не было бы этого топика S> Это было известно лет 10 назад после выхода Net 2.0 с дженериками.
Тему не я поднял.
S>>>И многие задачи решаются за счет оптимального подбора алгоритмов. EP>>Я не предлагаю сравнивать решения с разными алгоритмами. S> Так давай сравнивать реальную предметную область, а не сортировки
Сравнивать чтобы выяснить что?
Тема про производительность, обсуждение внезапно тоже.
Ты же зачем-то начинаешь переходить на сравнение востребованности языков, какие-то конкретные области типа ASP.NET, причём до конца не говоришь что конкретно хочешь этим выяснить.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Ах эта сверхманевренность. Так тупо съехать с пузырька на шейкер — верх мастерства.
Для описанного случая пофиг. Я напоминаю коллеге принципы работы пузырьковой сортировки.
К тому же, шейкерная сортировка официально является разновидностью пузырьковой.
Здравствуйте, alexzz, Вы писали:
A>>>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать. EP>>В каком смысле? A>Смотри, допустим, есть метод на C#, который принимает ICollection<T>, как-то сложно её анализирует и даёт на выходе IDictionary<TKey, TValue>. И при этом тормозит. Допустим, кто-нибудь пишет аналог этого метода на C++ и указывает, что он работает в сто раз быстрее. Что это знание даёт практически? A>Я ведь не смогу из C# передать в C++ ICollection<T> и получить IDictionary<TKey, TValue>. A>- либо код на C++ должен будет понимать детали реализации типов в .Net, и получится уже не высокоуровневый код; A>- либо передавать и возвращать придётся не абстрактные коллекции абстрактных типов, а какие-нибудь банальные массивы с числами или указатели на блоки памяти с числами, и снова получится не высокоуровневый код.
Это всего лишь механический слой interop'а, который прекрасно автоматизируется. Например каким-нибудь SWIG'ом, или Microsoft'авскими диалектами C++ которые работают в .NET.
При этом даже если вручную на низком уровне перебросить массив каких-то данных, это отнюдь не означает что вся реализация алгоритма на C++ должна быть на низком уровне — она без проблем может использовать весь арсенал высокоуровневых возможностей.
A>Логичный вариант ― не смотреть на другие языки, а сначала убрать лишние абстракции и чё-нибудь оптимизировать в коде на исходном языке. Стало достаточно быстро ― замечательно. Не стало ― смотрим в сторону С++, пробуем написать на нём аналог и сравниваем скорость. При этом сравниваем, естественно, с оптимизированной низкоуровневой версией. Ведь обогнать теперь нужно именно её.
Ещё раз, оптимизированные низкоуровневые версии на C# будут мало отличаться по скорости от C++ — какие-нибудь десятки процентов.
А вот цена создания такой низкоуровневой версии может быть неподъёмной, и намного превышать цену interop'а.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
S>>>>Я уже приводил, ссылку что самые востребованные программисты это 1С овцы. EP>>>Водители ещё более востребованы, и что из этого? S>> А разве водители это программисты?
EP>А причём востребованность?
При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация, а не на тех, что быстрее, но менее удобный.
S>>>> Я к тому, что для каждого языка свои задачи. EP>>>А я разве говорил обратное? S>>>>А порядок скоростей давно известен. EP>>>Видимо не всем — иначе не было бы этого топика S>> Это было известно лет 10 назад после выхода Net 2.0 с дженериками.
EP>Тему не я поднял.
S>>>>И многие задачи решаются за счет оптимального подбора алгоритмов. EP>>>Я не предлагаю сравнивать решения с разными алгоритмами. S>> Так давай сравнивать реальную предметную область, а не сортировки
EP>Сравнивать чтобы выяснить что? EP>Тема про производительность, обсуждение внезапно тоже. EP>Ты же зачем-то начинаешь переходить на сравнение востребованности языков, какие-то конкретные области типа ASP.NET, причём до конца не говоришь что конкретно хочешь этим выяснить.
. Просил сделать на С++ но народ не стал делать. Тогда уже порядок был известен и за счет чего.
Смысл даже был в том, что было предубеждение по поводу байт кода итд. Проигрыш в 2 раза был вполне удовлетворителен. Мало, того была куча библиотек где можно было на своих алгоритмах увеличивать скорость раза в 4 http://rsdn.ru/article/alg/tlsd.xml#EZD
внизу сравнения.
Так большинство будет использовать стандартную библиотеку, чем более быструю, но неизвестно от кого.
Еще раз экономическая целесообразность (стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности. Вот, что нужно считать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
EP>>Линейный поиск обычно идёт с конца, а не сначала. V>Обычно он идёт двоичный.
Обычно он линейный. Сортировка вставками чаще всего применяется для случаев где элементы находятся недалеко от своего места — например на нижних уровнях std::sort — в этих случаях делать обычный двоичный поиск невыгодно.
Вот визуализация реализации std::sort — там сортировка вставками на последнем этапе. http://www.youtube.com/watch?v=67ta5WTjjUo
EP>>Даже с этими модификациями получается больше сравнений — дойдёт до 6, сделает swap, дойдёт до конца, а потом ещё сделает проход от 5 до 1. V>И с этими и без этих модификацией НЕ будет лишнего прохода.
Каким образом?
V>Напиши реализацию этого алгоритма и убедись.
В тех реализациях что я представляю — лишний проход есть. Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код.
Здравствуйте, Serginio1, Вы писали:
EP>>А причём востребованность? S> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация,
Пишут что? В каких случаях? Удобнее для чего?
S>а не на тех, что быстрее, но менее удобный.
Для быстрого кода C++ удобный
S>>>>>И многие задачи решаются за счет оптимального подбора алгоритмов. EP>>>>Я не предлагаю сравнивать решения с разными алгоритмами. S>>> Так давай сравнивать реальную предметную область, а не сортировки EP>>Сравнивать чтобы выяснить что? EP>>Тема про производительность, обсуждение внезапно тоже. EP>>Ты же зачем-то начинаешь переходить на сравнение востребованности языков, какие-то конкретные области типа ASP.NET, причём до конца не говоришь что конкретно хочешь этим выяснить. S> Еще раз повторю, что порядок скоростей был известен лет 10 назад.
Каких конкретно скоростей? И зачем ты мне это повторяешь? Ещё раз, тему не я поднял — если тебя не устаревает что это тему опять подняли — то задавай вопросы на счёт этого не мне.
S>Я делал тесты на C#,Delphi http://rsdn.ru/forum/philosophy/555869.flat
Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++.
Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости.
S>Еще раз экономическая целесообразность (стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности. Вот, что нужно считать.
Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше.
Во-вторых, даже если брать твой сценарий — чтобы прикинуть вычислительную мощность на одном устройстве нужно внезапно проводить те же тесты, против которых ты выступаешь
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>А причём востребованность? S>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация,
EP>Пишут что? В каких случаях? Удобнее для чего?
Удобнее для написания сайтов, учетных систем массовых задач.
S>>а не на тех, что быстрее, но менее удобный.
EP>Для быстрого кода C++ удобный
Еще раз повторю формулу экономической целесообразности
(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
S>>>> Так давай сравнивать реальную предметную область, а не сортировки EP>>>Сравнивать чтобы выяснить что?
Выяснить экономическую целесообразность выбора инструмента. EP>>>Тема про производительность, обсуждение внезапно тоже. EP>>>Ты же зачем-то начинаешь переходить на сравнение востребованности языков, какие-то конкретные области типа ASP.NET, причём до конца не говоришь что конкретно хочешь этим выяснить. S>> Еще раз повторю, что порядок скоростей был известен лет 10 назад.
EP>Каких конкретно скоростей? И зачем ты мне это повторяешь? Ещё раз, тему не я поднял — если тебя не устаревает что это тему опять подняли — то задавай вопросы на счёт этого не мне.
S>>Я делал тесты на C#,Delphi http://rsdn.ru/forum/philosophy/555869.flat
. Просил сделать на С++ но народ не стал делать.
EP>Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++. EP>Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости.
Ну в Net есть дженерики. Да они медленнее примерно в 2 раза за счет отсутствия инлайна. Но все зависит от структур и версии Jit а который совершенствуется.
S>>Еще раз экономическая целесообразность (стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности. Вот, что нужно считать.
EP>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше. EP>Во-вторых, даже если брать твой сценарий — чтобы прикинуть вычислительную мощность на одном устройстве нужно внезапно проводить те же тесты, против которых ты выступаешь
Я не против тестов, я против синтетических тестов. В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд. Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.
Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.
Нужно учитывать, что очень хороших программистов очень мало. Поэтому нужно брать средних программистов типа меня.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
PM>>В заголовок новости не поместилась информация о том, что они: PM>>
PM>> оптимизировали работу с памятью (а память по факту уже давно является многоуровневой системой кэшей) PM>> запустили user-space TCP/IP стек для определенного вида сетевых карт PM>> и пока не полностью реализовали все функции PM>>PM>>У меня есть сомнения, что первые 2 пункта легко реализуемы в управляемых средах (не знаю, добавили ли уже в Java value types) I>То есть, язык ни при чём. Чтд.
Если подразумевается язык в смысле синтаксиса, то конечно ни при чём. Если же говорить про платформу (clr vs jvm vs native), то как раз очень даже причём. ))) Собственно в этом почти всё дело и есть.
Ну и ещё не забываем про то, что у главных компиляторов C++ в данным момент мощнейшие в мире оптимизаторы. Что впрочем обычно влияет на быстродействие не более чем в пару раз (если не считать таких нюансов как автовекторизация), а не в 10, как в новости. Так что главное естественно не в этом, а в рантайме платформы, но про этот нюанс тоже стоит помнить.
Здравствуйте, Serginio1, Вы писали:
EP>>>>А причём востребованность? S>>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация, EP>>Пишут что? В каких случаях? Удобнее для чего? S> Удобнее для написания сайтов, учетных систем массовых задач.
И? Это единственные существующие задачи?
S>>>а не на тех, что быстрее, но менее удобный. EP>>Для быстрого кода C++ удобный S> Еще раз повторю формулу экономической целесообразности S>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
ОК, повторил, что ты этим хочешь сказать? (причем это одна из возможных формул, а не единственная)
Да, целесообразность тоже нужно учитывать, с этим не спорю — кроме этого ты что-то ещё подразумевал?
S>>>Я делал тесты на C#,Delphi http://rsdn.ru/forum/philosophy/555869.flat
. Просил сделать на С++ но народ не стал делать. EP>>Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++. EP>>Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости. S> Ну в Net есть дженерики. Да они медленнее примерно в 2 раза за счет отсутствия инлайна.
Это цифра с потолка.
Во-первых отсутствие инлайна это прежде всего не стоимость непосредственно вызова, а отсутствие возможности оптимизировать большой кусок кода целиком.
Во-вторых даже если брать только цену вызова ~T нужно понимать что цена каждого вызова суммируется, то есть N*T. А чтобы посчитать "во сколько раз" — нужно знать цену конечной полезной операции P. Получается формула (N*T + P)/P, и чем мельче сама операция P — тем в большее число раз разрыв. На C++ можно без проблем оборачивать в абстракции даже мелкие операции без потерь: конкретный пример
В-третьих помимо тормозов дженериков/лямбд есть тормоза лишних косвенностей по памяти. Потому что default это pointer semantics, а не value semantics как в C++. Да есть структуры, но они далеко не всегда применимы: например
для оценки эффекта: заменили struct на class в одном месте и получили ~80x просадку. Так это всего лишь один уровень и пример простой.
EP>>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше. EP>>Во-вторых, даже если брать твой сценарий — чтобы прикинуть вычислительную мощность на одном устройстве нужно внезапно проводить те же тесты, против которых ты выступаешь S> Я не против тестов, я против синтетических тестов.
А я не против синтетических тестов — я только за, они позволяют проверить какой-нибудь конкретный аспект отметая всё лишнее. Тем не менее я против неверных выводов из результатов этих тестов.
S>В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд.
Старая шарманка "всё в базу упираются"
У меня в продукте вообще нет никакой никакого SQL и никаких HTTP, не надо проецировать какие-то свои личные задачи на всех, и делать далеко идущие выводы
S>Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.
ASM.JS достаточно быстрый. Я даже выше приводил ссылку. C++ скомпилированный в ASM.JS обогнал C# в своей родной среде практически в два раза
JavaScript, в веб-браузере, Карл!
S> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.
Здравствуйте, Serginio1, Вы писали:
EP>>Пишут что? В каких случаях? Удобнее для чего? S> Удобнее для написания сайтов, учетных систем массовых задач.
Сайты удобнее делать на скриптовых языках. А что такое "учетные системе массовых задач"?.
S> Еще раз повторю формулу экономической целесообразности S>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
Да, всё верно. Именно из-за этого факта и существуют такие вещи как Java/C#. И как раз сейчас в связи со стагнацией в росте производительности процессоров, ростом мобильного рынка (где вообще печаль с производительностью) и начинающейся модой на "интернет вещей" (а туда вообще даже сами платформы jvm/clr не лезут по нормальному, не говоря уже о какой-то производительности) в этом вопрос возможны существенные корректировки.
S> Я не против тестов, я против синтетических тестов. В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд. Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды. S> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата. S> Нужно учитывать, что очень хороших программистов очень мало. Поэтому нужно брать средних программистов типа меня.
Из этого текста создаётся такое впечатление, что все эти sql серверы, http серверы, браузеры и т.п., в которых происходит основное время исполнения задачи (по твоим же словам) и которые кстати в подавляющем большинстве написаны на C/C++, пишутся не программистами, а какими-то инопланетянами. )))
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Линейный поиск обычно идёт с конца, а не сначала. V>>Обычно он идёт двоичный. EP>Обычно он линейный.
Линейный он лишь для случая одновременного поиска и сдвига элементов массива.
В этом случае он представляет из себя разновидность пузырьковой сортировки. Если же сначала найти необходимую позицию, а затем сдвинуть все необходимые элементы за раз, то так может оказаться эффективней.
EP>Сортировка вставками чаще всего применяется для случаев где элементы находятся недалеко от своего места — например на нижних уровнях std::sort — в этих случаях делать обычный двоичный поиск невыгодно.
Сортировка вставками — это один из наиэффективнейших алгоритмов сам по себе для случая, когда в массиве немного неотсортированных элементов. А "далеко" или "недалеко" — это всё спекуляции. В std::sort идет линейный поиск по той причине, которую уже многократно обсуждали на этом сайте — до, примерно, 16-ти элементов на современных процессорах выгодней искать элемент линейно, а не двоичным поиском. В общем же случае это утверждение совершенно не верно.
Ну вот хорошо видно, что от текущего элемента работает как пузырьковая при линейном поиске ))
EP>В тех реализациях что я представляю — лишний проход есть.
Мммм...
Похоже, что в тех реализациях, что ты представляешь — пузырьковая сортировка отработает N! (факториал) раз независимо от исходных данных. ))
EP>Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код.
Стандартная и есть без лишнего прохода. Из вики:
Введение индикатора (флажка F) действительно произошедших во внутреннем цикле обменов уменьшает число лишних проходов в случаях с частично отсортированными массивами на входе. Перед каждым проходом по внутреннему циклу флажок сбрасывается в 0, а после действительно произошедшего обмена устанавливается в 1. Если после выхода из внутреннего цикла флажок равен 0, то обменов не было, то есть массив отсортирован и можно досрочно выйти из программы сортировки.
Здравствуйте, vdimas, Вы писали:
EP>>>>Линейный поиск обычно идёт с конца, а не сначала. V>>>Обычно он идёт двоичный. EP>>Обычно он линейный. V>Линейный он лишь для случая одновременного поиска и сдвига элементов массива. V>В этом случае он представляет из себя разновидность пузырьковой сортировки.
Это не разновидность пузырьковой сортировки.
V>Если же сначала найти необходимую позицию, а затем сдвинуть все необходимые элементы за раз, то так может оказаться эффективней.
Может, не спорю что есть вариант с двоичным поиском, и что у него есть область применения. Я говорю что обычно он линейный.
EP>>Сортировка вставками чаще всего применяется для случаев где элементы находятся недалеко от своего места- например на нижних уровнях std::sort — в этих случаях делать обычный двоичный поиск невыгодно. V>Сортировка вставками — это один из наиэффективнейших алгоритмов сам по себе для случая, когда в массиве немного неотсортированных элементов. А "далеко" или "недалеко" — это всё спекуляции.
Это не спекуляции, а реальное свойство влияющее на применимость.
V>В std::sort идет линейный поиск по той причине, которую уже многократно обсуждали на этом сайте — до, примерно, 16-ти элементов на современных процессорах выгодней искать элемент линейно, а не двоичным поиском.
В том числе и по этой причине.
V>В общем же случае это утверждение совершенно не верно.
Я не говорил про общий случай, я конкретно обозначил необходимое свойство.
EP>>Или например вот визуализация insertion sort: EP>>http://www.youtube.com/watch?v=8oJS1BMKE64 V>Ну вот хорошо видно, что от текущего элемента работает как пузырьковая при линейном поиске ))
Это не пузырьковая сортировка
Там вообще говоря swap использовать не выгодно — там нет необходимости менять каждый соседний элемент между собой. Оптимальнее переместить текущий элемент в temp, все остальные переместить вправо, а потом переместить temp в левый край. Это операция ЕМНИП rotate_by_one.
EP>>В тех реализациях что я представляю — лишний проход есть. V>Мммм... V>Похоже, что в тех реализациях, что ты представляешь — пузырьковая сортировка отработает N! (факториал) раз независимо от исходных данных. ))
Очень смешно. Пузырьковая сортировка квадратична в худщем случае.
EP>>Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код. V>Стандартная и есть без лишнего прохода.
Код в студию, иначе наш спор не разрешится.
V>Из вики: V>
V>Введение индикатора (флажка F) действительно произошедших во внутреннем цикле обменов уменьшает число лишних проходов в случаях с частично отсортированными массивами на входе. Перед каждым проходом по внутреннему циклу флажок сбрасывается в 0, а после действительно произошедшего обмена устанавливается в 1. Если после выхода из внутреннего цикла флажок равен 0, то обменов не было, то есть массив отсортирован и можно досрочно выйти из программы сортировки.
* "Перед каждым проходом по внутреннему циклу флажок сбрасывается в 0"
flag = 0
В этом цикле у нас будет один swap/обмен 6<->5 :
* "а после действительно произошедшего обмена устанавливается в 1"
Устанавливаем flag = 1
* "Если после выхода из внутреннего цикла флажок равен 0, то обменов не было, то есть массив отсортирован и можно досрочно выйти из программы сортировки."
flag == 1, значит досрочно выйти мы не можем.
Делаем ещё один проход, опять вначале устанавливаем flag в 0 — на этот раз без обменов, и после этого второго прохода можем выйти досрочно.
Здравствуйте, vdimas, Вы писали:
EP>>Вот визуализация реализации std::sort — там сортировка вставками на последнем этапе. V>Оттуда же ролик: V>https://www.youtube.com/watch?v=kPRA0W1kECg V>Сортировка прямым выбором заборола быструю почти в два раза, ы-ы-ы. V>Кста, сортировка прямым выбором одна из наипростейших для реализации... V>Т.е., от исходных данных сильно всё зависит.
Конечно зависит, размер данных решает — в данном ролике он разный в каждом эпизоде
P.S. Сортировка выбором (не стабильный вариант) даёт наименьшее возможное количество перемещений элементов, вполне полезное свойство.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
EP>>>Пишут что? В каких случаях? Удобнее для чего? S>> Удобнее для написания сайтов, учетных систем массовых задач.
_>Сайты удобнее делать на скриптовых языках. А что такое "учетные системе массовых задач"?.
Учетные системы ERP это ERP Microsoft Dynamics,SAP, Oracle E-Business Suite ну и конечно 1С.
http://www.sencha.com/products/extjs/ http://webix.com/demo/charts/customizing/ http://yuilibrary.com/yui/docs/examples/ http://docs.angularjs.org/guide/overview http://jqueryui.com/
S>> Еще раз повторю формулу экономической целесообразности S>>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
_>Да, всё верно. Именно из-за этого факта и существуют такие вещи как Java/C#. И как раз сейчас в связи со стагнацией в росте производительности процессоров, ростом мобильного рынка (где вообще печаль с производительностью) и начинающейся модой на "интернет вещей" (а туда вообще даже сами платформы jvm/clr не лезут по нормальному, не говоря уже о какой-то производительности) в этом вопрос возможны существенные корректировки.
Ну сейчас идут по пути распараллеливания кода. Кстати многие сортировки можно распараллелить.
S>> Я не против тестов, я против синтетических тестов. В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд. Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды. S>> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата. S>> Нужно учитывать, что очень хороших программистов очень мало. Поэтому нужно брать средних программистов типа меня.
_>Из этого текста создаётся такое впечатление, что все эти sql серверы, http серверы, браузеры и т.п., в которых происходит основное время исполнения
задачи (по твоим же словам) и которые кстати в подавляющем большинстве написаны на C/C++, пишутся не программистами, а какими-то инопланетянами. )))
Народ в большинстве случаев варится в своем тесном мирке. Разработка SQL серверов и Вэб серверов весьма нетривиальная задача, которая для среднестатистического программиста далека как Марс от Земли.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Serginio1, Вы писали:
EP>>>>>А причём востребованность? S>>>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация, EP>>>Пишут что? В каких случаях? Удобнее для чего? S>> Удобнее для написания сайтов, учетных систем массовых задач.
EP>И? Это единственные существующие задачи?
Такими задачами занимаются большинство программистов.
S>>>>а не на тех, что быстрее, но менее удобный. EP>>>Для быстрого кода C++ удобный S>> Еще раз повторю формулу экономической целесообразности S>>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
EP>ОК, повторил, что ты этим хочешь сказать? (причем это одна из возможных формул, а не единственная) EP>Да, целесообразность тоже нужно учитывать, с этим не спорю — кроме этого ты что-то ещё подразумевал?
К тому, что нужны специалисты со снанием конкретного языка. Какова доля программистов С++ в программистском мире?
А задач таких полно. И нужна скорость решения, а не скорость выполнения. У меня куча отчетов где скорость новых быстрее раз в 10.
Но например этот отчет бухгалтер делает раз в месяц. И он может подождать даже пол часа, занимаясь другой работой.
Иногда нужно быстро решить задачу, а сколько она будет выполняться не имеет значения.
S>>>>Я делал тесты на C#,Delphi http://rsdn.ru/forum/philosophy/555869.flat
. Просил сделать на С++ но народ не стал делать. EP>>>Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++. EP>>>Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости. S>> Ну в Net есть дженерики. Да они медленнее примерно в 2 раза за счет отсутствия инлайна.
EP>Это цифра с потолка.
EP>Во-первых отсутствие инлайна это прежде всего не стоимость непосредственно вызова, а отсутствие возможности оптимизировать большой кусок кода целиком.
поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много. Кстати по поводу использования структур. http://rsdn.ru/forum/dotnet/415352.1
Смысл в том, что если прошла сборка мусора, то джит собирает 0 поколения, а старые поколения если ссылки на них не менялись не трогает. А вот для если они менялись, то он их помечает и в итоге происходят тормоза. Поэтому Хэш таблицы например сделаны на массиве структур. Но при этом и сборщики мусора совершенствуются
Это EP>>>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше.
Или если таких приложений будет 1-2 он уйдет к тем у кого 1000-100000. Везде нужна экономическая целесообразность. Поэтому и существуют С++,С# и 1С.
S>>В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд.
EP>Старая шарманка "всё в базу упираются" EP>У меня в продукте вообще нет никакой никакого SQL и никаких HTTP, не надо проецировать какие-то свои личные задачи на всех, и делать далеко идущие выводы
И какова занятость процессора в твоих приложениях? S>>Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.
EP>ASM.JS достаточно быстрый. Я даже выше приводил ссылку. C++ скомпилированный в ASM.JS обогнал C# в своей родной среде практически в два раза EP>JavaScript, в веб-браузере, Карл!
В итоге все зависит от компилятора. Например TS тоже транслируется в JS и ничто не мешает транслировать в более оптимальный. Здесь проблема не языков а компиляторов которые совершенствуются.
S>> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.
EP>Дальше-то ты какой вывод делаешь?
Вывод в том, что существование тех или иных языков или платформ вызвано не только скоростью выполнения, и от количества специалистов. А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
EP>>>>>>А причём востребованность? S>>>>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация, EP>>>>Пишут что? В каких случаях? Удобнее для чего? S>>> Удобнее для написания сайтов, учетных систем массовых задач. EP>>И? Это единственные существующие задачи? S> Такими задачами занимаются большинство программистов.
ОК, дальше-то какой вывод?
S>>> Еще раз повторю формулу экономической целесообразности S>>>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности EP>>ОК, повторил, что ты этим хочешь сказать? (причем это одна из возможных формул, а не единственная) EP>>Да, целесообразность тоже нужно учитывать, с этим не спорю — кроме этого ты что-то ещё подразумевал? S> К тому, что нужны специалисты со снанием конкретного языка.
Когда как. Бывает заказчику всё равно какой там язык, главное результат.
S>Какова доля программистов С++ в программистском мире?
Не знаю, но уж точно не маленькая. И не только из-за его скорости или других удобств, например у него самый широкий из mainstream охват по платформам, и например есть ещё и legacy.
S>А задач таких полно. И нужна скорость решения, а не скорость выполнения.
С этим никто не спорил, и в общем-то это очевидные вещи.
S>У меня куча отчетов где скорость новых быстрее раз в 10. S>Но например этот отчет бухгалтер делает раз в месяц. И он может подождать даже пол часа, занимаясь другой работой.
Бывают и такие варианты.
А бывают и другие, например бухгалтер генерирует отчёт, потом проверяет его, исправляет ошибки, и опять запускает — и так может быть несколько раз.
Или например инженер делает расчёт, ждать результата он может долго скажем день, но при этом бОльшая доступная вычислительная мощность переходит в качество — он может сделать более густую расчётную сетку, произвести большее количество нелинейных расчётов и т.д. и т.п.
S>Иногда нужно быстро решить задачу, а сколько она будет выполняться не имеет значения.
Расшифруй.
S> поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много.
Смысл в том, что если прошла сборка мусора, то джит собирает 0 поколения, а старые поколения если ссылки на них не менялись не трогает. А вот для если они менялись, то он их помечает и в итоге происходят тормоза. Поэтому Хэш таблицы например сделаны на массиве структур. Но при этом и сборщики мусора совершенствуются
А я вообще забыл упомянуть тормоза от GC, это отдельная тема. Тормоза для pointer semantics style есть даже без учёта бОльшей нагрузки на GC.
И если активно использовать pointer semantics в C++ — то и там появятся точно такие же тормоза как и в Java/C#/etc: пример
— заменили плотно упакованные элементы, на структуру ссылочного вида — в результате разница по скорости 208.6x, и это без учёта работы менеджера памяти.
Но в C++ default это value semantics, и там его намного легче использовать чем в языках заточенных под pointer semantics.
S>Это EP>>>>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше. S> Или если таких приложений будет 1-2 он уйдет к тем у кого 1000-100000.
Не понял этого тезиса.
S>Везде нужна экономическая целесообразность. Поэтому и существуют С++,С# и 1С.
Нужна, я этого не отрицал.
S>>>В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд. EP>>Старая шарманка "всё в базу упираются" EP>>У меня в продукте вообще нет никакой никакого SQL и никаких HTTP, не надо проецировать какие-то свои личные задачи на всех, и делать далеко идущие выводы S> И какова занятость процессора в твоих приложениях?
Это надо у клиентов спросить, так как это библиотека
А вообще не понятно к чему вопрос про занятость, даже если он в среднем занят на доли процента, это не делает не нужным быстрое железо, и быстрый софт.
Например женщина в среднем вынашивает ребёнка в течении скажем 2% от продолжительности своей жизни, размазать этот процент по всем годам никак не получится, и она не сможет родить ребёнка через день после зачатия
S>>>Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды. EP>>ASM.JS достаточно быстрый. Я даже выше приводил ссылку. C++ скомпилированный в ASM.JS обогнал C# в своей родной среде практически в два раза EP>>JavaScript, в веб-браузере, Карл! S> В итоге все зависит от компилятора. Например TS тоже транслируется в JS и ничто не мешает транслировать в более оптимальный. Здесь проблема не языков а компиляторов которые совершенствуются.
Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.
S>>> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата. EP>>Дальше-то ты какой вывод делаешь? S> Вывод в том, что существование тех или иных языков или платформ вызвано не только скоростью выполнения
В целом да, а в частности нет. Например сделали язык заточенный под скорость, потому что нужна скорость — вопрос, чем вызвано его существование?
S>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит
Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?
