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

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

AVK>Он там довольно давно присутствовал. По крайней мере ввиде Java. Специфика многих областей HPC в том, что количество прогонов программы может быть очень небольшим, и намного важнее с точки зрения скорости получения результата от постановки задачи — скорость разработки. Вот такой вот парадокс. Если что, это не я придумал, это Кирилл Фаенов рассказывал как то.

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

Только тут всё равно присутствует эта составляющая "нересурсности", ведь ключевое слово — "если есть возможность поднять производительность аппаратуры". Саттер не случайно ссылается на вот эту работу — там как раз говорят, что скорость роста производительности сейчас очень сильно упала и не совсем понятно, что со всем этим делать. Апеллировать к тому, что сегодняшних скоростей вполне достаточно, ИМХО, бессмысленно — один очень известный человек уже когда-то уверял, что "640 килобайт хватит любому". Время идёт, желания растут...

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

ГВ>>Следовательно тут только одно — что ты криво определил термин "нативные". Отсюда весь этот цирк.
AVK>Цирк тут из-за того, что некоторые товарищи азартно переключились с основного вопроса на спор о терминах, что к цирку с вероятностью 100% и ведет.

Я бы сказал не так. ИМХО, одни товарищи пытаются не слишком умело жонглировать словами, а другие развлекаются за их счёт. Добро бы те, первые, исправляли свои ошибки — ну ляпнул и ляпнул, с кем не бывает, так нет же, пытаются ещё и доказать что-то. С другой стороны — обе стороны упражняются в риторических умениях, так что, сплошное добро™ и благолепие, если разобраться.

А с третьей стороны — ну да, вот она, война информационного века — война смыслов (строгий онтопик для ФП, кстати). По сути, "первые" пытаются донести до окружающих простую до примитивного мысль: "C++ — в ж...", оформляя её в квазилогичное рассуждение, ну а "вторые" — раскатывают эту квазилогичность и таким образом, нейтрализуют неявную исходную посылку.

Ergo, не такие они и бессмысленные — эти самые споры о терминах. Ну и лулзы опять таки, куда ж без них?

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

ГВ>На парадокс не похоже. Если у нас есть возможность поставить вычислительный комплекс, допустим, в сотню раз более быстрый

Такой возможности обычно нет. Дело в другом — программа на С++ пусть будет считать на час меньше. А разработка с его использованием будет на месяц дольше. Такием образом, если нам нужен десяток-другой прогонов, то быстрее получить эти результаты с помощью Java.

ГВ>Только тут всё равно присутствует эта составляющая "нересурсности"

В том что я написал — нет, не присутствует.

ГВ>, ведь ключевое слово — "если есть возможность поднять производительность аппаратуры"

Удобно у самого же себя находить подтверждение своим же теориям?

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

AVK>>Цирк тут из-за того, что некоторые товарищи азартно переключились с основного вопроса на спор о терминах, что к цирку с вероятностью 100% и ведет.

ГВ>Я бы сказал не так.

Кто бы сомневался. Только вот факта это не изменит.

ГВ>Ergo, не такие они и бессмысленные — эти самые споры о терминах.

Именно такие.

ГВ> Ну и лулзы опять таки, куда ж без них?

Демагогия и троллинг. Неприглядная картинка.

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

ГВ>>Только тут всё равно присутствует эта составляющая "нересурсности"
AVK>В том что я написал — нет, не присутствует.

Присутствует, и ещё как! Если мы можем пренебречь потреблением CPU для расчётов — то вот она, "нересурсность" в чистом виде. Кстати, я не спорю, что есть задачи, для которых приоритетна производительность программиста и их, таких задач, достаточно много. Просто одно другого не отменяет.

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

AVK>>>Цирк тут из-за того, что некоторые товарищи азартно переключились с основного вопроса на спор о терминах, что к цирку с вероятностью 100% и ведет.
ГВ>>Я бы сказал не так.

AVK>Кто бы сомневался. Только вот факта это не изменит.

Контекст тоже не изменится.

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

AVK>Такой возможности обычно нет. Дело в другом — программа на С++ пусть будет считать на час меньше. А разработка с его использованием будет на месяц дольше. Такием образом, если нам нужен десяток-другой прогонов, то быстрее получить эти результаты с помощью Java.

Для таких расчетов гораздо лучшим вариантом чем ява может оказаться что-то из класса MATLAB или R или питон со SciPy.
Притом если их возможностей недостаточно то пишется модуль расширения именно на C/C++.

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

FR>Для таких расчетов гораздо лучшим вариантом чем ява может оказаться что-то из класса MATLAB

Возможно. А может и нет.

FR>или питон со SciPy.

Вот питон уже вряд ли. Там разница на числомолочении будет пару порядков.

FR>Притом если их возможностей недостаточно то пишется модуль расширения именно на C/C++.

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

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

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

"Не говори глупостей", "это хрень" и т.д. Думаешь, эти "заклинания" работают?
ИМХО, прошли те времена, когда на RSDN оппоненты понимали что пишут не поставлялись в каждом втором абзаце строчке...

Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит. Например, попарный перебор элементов коллекции. Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам.

Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов.

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


V>>К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет.
G>Дык есть codecontracts, кроме того есть unit-тесты, которые проверяют утверждения, которые в свою очередь невозможно вычислить статически.

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

Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом.

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

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

G>>>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна).
V>>Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования.
G>Ну давай вернемся. Ты серьезно предлагаешь затратить 70% времени тестирования на тестирование результатов не нужных пользователю?

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

Почему именно так? Помнишь, про относительную надежность? У вас в продукте тысячи таких примитивных мест, и если надежность каждого из них жалкие ~99.9%, достигнутые через код ревью и проверку только позитивных моментов, то программа ваша в большинстве случаев будет падать. Всё просто. Поэтому тут и пишут некоторые, что у них огромный отдел "ручных" тестировщиков. Их задача как раз "тупо" запускать программу в различных условиях, что бы вылазили боком те самые непокрытые негативные сценарии в различных комбинациях. А что еще можно проверять в ручном режиме? Помедитируй на эту тему... И как приговор: ручное тестирование — это аналог тыканья пальцем в небо. Можно попасть, а можно нет — как повезет.


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

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


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

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


G>Более того "поток данных" состоит из отдельных кадров, так что вопрос в том как работать с состоянием.

Изначально неправильный вопрос. Вопрос может быть лишь в том, какие требования. А ответ всегда — удовлетворить требования максимально дешевым способом, вот и всё кино.

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

G>Ты покажи сайт написаный на native, который работает соизмеримо с сайтом на ASP.NET?

Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта.

CS>>Мы рассматривали конкретный пример EverNote для которого есть две версии написанные профессионалами которых я знаю лично.
G>Это не значит что они умеют и знают WPF

А что там уметь и знать для EverNote? Ты его интерфейс видел? Это можно брать любой официальный пример и в 2 шага получить требуемое.

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

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

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

V>"Не говори глупостей", "это хрень" и т.д. Думаешь, эти "заклинания" работают?
V>ИМХО, прошли те времена, когда на RSDN оппоненты понимали что пишут не поставлялись в каждом втором абзаце строчке...
Это правда жизни. Ты пытаешься говорить то что противоречит практике. Мне даже лениво тебе объяснять все детали.

V>Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит.
Агащаз.

V>Например, попарный перебор элементов коллекции.
.Zip

V>Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам.
Снова бред. Ты просто не в теме.


V>Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов.
Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.


V>Пишу эти банальности не для тебя, разумеется, бо с тобой уже по 3-му кругу пошли на одно и то же... как том анекдоте, про очень пылкого в постели дедушку со склерозом. Это я для "независимых" читателей пишу, которые добрались до сюда и надеются вынести толику информации.
Ты бы лучше выглянул из своей норы, увидел бы что в .NET есть много способов априори избежать тех ошибок, которые постоянно случаются в unmanaged. Но если для тебя stl является пределом, то вряд ли стоит тебе что-то тут писать.


V>>>К тому же, отсутствие инструментов по статической верификации вынуждает плодить интерфейсы и пользовать в неуемных масштабах динамическое приведение типов. В каждом из случев можно получить ошибку в рантайм. Опять же, во время тестирования — если только повезет.
G>>Дык есть codecontracts, кроме того есть unit-тесты, которые проверяют утверждения, которые в свою очередь невозможно вычислить статически.

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

Я тоже видел падения, но ты же пытаешься доказать что их не меньше чем для unmanaged, причем приводишь в качестве агрументов ошибки вроде IndexOutOfRange. Вот только в managed можно писать программы на таком уровне абстракции, где подобные ошибки не случаются.

V>Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом.
Не, в C# такой код просто не будет написан. Но ты этого не поймешь, потому что даже на C# пишешь как на C++. Вот и получается что для тебя managed это только exception вместо непонятного поведения.

V>Опять ошибаешься, и уже делился информацией не раз. Например, открыть нашу JIRA, и там багов, связанных с порчей памяти, будет всяко меньше одного процента. Далеко не у каждого проекта хотя бы раз, при общем кол-ве фиксов на каждый проект за несколько лет жизни в сотни. Т.е. ошибки в логике происходят примерно в тысячу раз чаще, чем ошибки собственно кодирования. Да, разумеется, юнит тестирование используется. Как раз чаще всего для проверки граничных условий и соблюдения инвариантов. Надо просто понимать, что стоит проверять в первую очередь. Все подряд, естественно, мы не проверяем.
Именно, вот managed позволяет сконцентрироваться на логике, а в unmanaged ты вынужден и за памятью следить. При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.

G>>>>Мы ведь не о всех багах говорим, а о тех которые вызваны ошибками в процессе кодирования (не дизайна).
V>>>Да, о них. Можно возвращаться в обсуждении к доле негативных тестов в общем объеме тестирования.
G>>Ну давай вернемся. Ты серьезно предлагаешь затратить 70% времени тестирования на тестирование результатов не нужных пользователю?

V>Именно.
Это тоже бред. Ни один толковый менеджер не позволить такое сделать.

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


V>Почему именно так? Помнишь, про относительную надежность? У вас в продукте тысячи таких примитивных мест, и если надежность каждого из них жалкие ~99.9%, достигнутые через код ревью и проверку только позитивных моментов, то программа ваша в большинстве случаев будет падать. Всё просто. Поэтому тут и пишут некоторые, что у них огромный отдел "ручных" тестировщиков. Их задача как раз "тупо" запускать программу в различных условиях, что бы вылазили боком те самые непокрытые негативные сценарии в различных комбинациях. А что еще можно проверять в ручном режиме? Помедитируй на эту тему... И как приговор: ручное тестирование — это аналог тыканья пальцем в небо. Можно попасть, а можно нет — как повезет.
Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит.
Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе.

V>>>Системы, обслуживающие в основном только запросы, очень масштабируемы уже на уровне целевых endpoint. В отличие от них, в системе принятия решений поступающие данные не являются независимыми, а влияют на состояние.
G>>Скажу по секрету что запросы тоже могут влиять на состояние. Например форум подсчитывает количество просмотров, на каждый запрос изменяется соcтоние.
V>Но требования к оперативности получения этой изменяемой величины стремятся с 0-лю. Каждый запрос вполне может слать выделенному сервису тикет, который будет вставлен в неспешную очередь, которая будет разгребаться в отсутствии пиков загрузки с подходящим приоритетом и т.д. Что я тебе тут рассказываю, в общем, базовые вещи уровня 3-го курса профильной специальности...
Тем не менее в этом форуме просмотры подсчитываются сразу и нагрузка на этот сайт совсем недетская.

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

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

G>>Ты покажи сайт написаный на native, который работает соизмеримо с сайтом на ASP.NET?

V>Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта.
Ну никакого интереса в статических ресурсах нет. Эра статического инернета закончилась еще 20 лет назад.

CS>>>Мы рассматривали конкретный пример EverNote для которого есть две версии написанные профессионалами которых я знаю лично.
G>>Это не значит что они умеют и знают WPF
V>А что там уметь и знать для EverNote? Ты его интерфейс видел? Это можно брать любой официальный пример и в 2 шага получить требуемое.
Угу, и сразу начинать ругаться на то что "тормозит", "криво работает" итп.
WPF прост только с виду, для того чтобы он эффективно работал надо еще постораться.

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

V>>Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов.
G>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.

Ты их по скорости сравнивал? Как ты думаешь, каковы различия в скоростях выполнения вот этих конструкций (чтобы уж от онтопика не отходить):

C++:

std::accumulate(v.begin(), v.end(), c);

C++ STL+лямбда:

std::accumulate(v.begin(), v.end(), c, [=](long long acc, long long v) -> long long { return acc + v; });

C# foreach:

foreach (var k in v){ c += k; }

C# Linq:

v.Aggregate(c, (acc, k) => acc += k, acc => acc);

Во всех случаях v значит "вендетта" массив 64-битных целых.

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

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

V>>>Но это всё не принципиально для спора. Принципиально, что твой пример не контраргумент ни разу, т.е. просто бесполезно засоряет форум. Просто речь ни о чем. Ну или о том же, что присутствует в С++ примерно лет за 15 до дотнета причем во всех видах, как в интерактивной, так и в функциональной. Я говорю об STL. Ты не мог не слышать об этой библиотеке и не мог не знать, что интерфейсы подачи целевых множеств в алгоритмы этой библиотеки доступны исключительно в виде итераторов.
G>>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.

ГВ>Ты их по скорости сравнивал?
Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.

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

G>>>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.

ГВ>>Ты их по скорости сравнивал?
G>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.

А я сравнил. Соотношение времени выполнения примерно такое:

C++: 1
C++ STL+лямбда: 1
C# foreach: 1
C# Linq: 13-20

Мощно и выразительно.

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

ГВ>Чертовски любопытное выступление Герба Саттера "Why C++".

Да элемеентарно. Когда у тебя зоопарк из 15 платформ, C++ это единственно возможный вариант.

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

FR>>Для таких расчетов гораздо лучшим вариантом чем ява может оказаться что-то из класса MATLAB

AVK>Возможно. А может и нет.

С большей вероятностью да.

FR>>или питон со SciPy.

AVK>Вот питон уже вряд ли. Там разница на числомолочении будет пару порядков.

А числомолочением питон заниматься и не будет, это сделают хорошо оптимизированные (более быстрые чем на яве)
C/C++ библиотеки. Тот же SciPy как пример.

FR>>Притом если их возможностей недостаточно то пишется модуль расширения именно на C/C++.

AVK>А смысел тогда в питоне? Это ж не коробка, там большая часть кода — собственно вычисления, обязочный код минимален.

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

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

V>>Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта.
G>Ну никакого интереса в статических ресурсах нет. Эра статического инернета закончилась еще 20 лет назад.

Ты случайно не клиентскую DHTML-фичу имеешь ввиду?
Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере.
Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился.

Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна.

И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом. Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++)

Ну и даже брать задачи работы с БД, где ASP.Net якобы является "удачной прослойкой"... Дотнетный парсер потока MS SQL сливает нейтивному в 4-5 раз (а то и более, если идет много числовых полей и мало строковых). Т.е. на сегодня ситуация такова, что нейтивный MS SQL способен выдавать данные быстрее, чем дотнетные приложения способны парсить его ответ... Хохма натуральная. Уже на гигабитных картейках в локалке это видно во всей красе.

Поэтому действительно "быстрые" веб-сервера пишутся как нейтивная часть некоторого сервера, например модули Apache или нейтивные модули IIS. Так же полно популярных нейтивных либ, вроде этой, обыгрывающих серверную часть HTTP-протокола. Ты просто очень далек от современной ситуации в web, судя по твоим постам...


G>Угу, и сразу начинать ругаться на то что "тормозит", "криво работает" итп.
G>WPF прост только с виду, для того чтобы он эффективно работал надо еще постораться.

Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать...

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

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

Быстрая сортировка. Нарисуй-ка inplace без foreach.

V>>Например, попарный перебор элементов коллекции.
G>.Zip

Опять read-only.

V>>Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам.
G>Снова бред. Ты просто не в теме.

Пока что я вижу, что это ты не в теме даже в базовых вещах.

G>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.

На сегодня Linq сливает даже традиционным функциональным языкам по эффективности времени выполнения... а те, в свою очередь, во все времена были руганы за тормознутость и требования к памяти. Да и полно таких технологий, в сравнении с которыми Linq и по выразительности — ничто... Одна засада, тормозит это так же нехило, как и LINQ, а то и похлеще.

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

Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов.

G>Но если для тебя stl является пределом, то вряд ли стоит тебе что-то тут писать.

А в Киеве дядька.

G>Я тоже видел падения, но ты же пытаешься доказать что их не меньше чем для unmanaged, причем приводишь в качестве агрументов ошибки вроде IndexOutOfRange. Вот только в managed можно писать программы на таком уровне абстракции, где подобные ошибки не случаются.

На таком уровне абстракции можно на любом языке писать, даже на С++... Всяко эффективней будет все-равно. Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно. Слабоватый ты оппонент с такой позицией... Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили).


V>>Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом.
G>Не, в C# такой код просто не будет написан.

Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить?

G>Но ты этого не поймешь, потому что даже на C# пишешь как на C++. Вот и получается что для тебя managed это только exception вместо непонятного поведения.

А почему я должен понимать твои неуемные фантазии? Я этой ньювасюковщины наелся еще в 2002-м, а потом в 2005-м. Но сужу по реальным проектам, которых насмотрелся достаточно. А ты тут пытаешься говорить "сахар, сахар", и удивляешься, как у нас до сих пор во рту не сладко.
Такого уровня программист, которого ты подразумеваешь на C#, сможет на плюсах сделать то же самое и быстрее и эффективнее. Проверено многократно на задачах, где для дотнета нету львиной доли конечного решения в готовых библиотеках, т.е. много надо делать с 0-ля. Но если брать спецов, скажем так, не очень высокого уровня, то у них плюсовые проги даже не заработают, согласен, но шарповые заработают хоть как-то... Тут C# всяко эффективнее, да... Со всеми этими регулярными глюками, о которых я говорил выше. Прямо отсюда можешь начинать заходить на 5-й круг, но результат будет тот же, гарантирую.

G>Именно, вот managed позволяет сконцентрироваться на логике, а в unmanaged ты вынужден и за памятью следить.

Ну так не везде же нужна голая логика без эффективности, правда? Иначе бы никто не искал программистов С++ сегодня. Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? Тебе ведь невдомек выделить время и прикинуть такой момент, что политика работы с памятью (а есть и такое вне дотнета) — это всегда часть процедур при работе над эффективностью кода. Более обще — сама основа эффективности ПО — это суть эффективное использование ресурсов. Не только памяти, смотри шире.

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

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


V>>Именно.
G>Это тоже бред. Ни один толковый менеджер не позволить такое сделать.

А посадить 100 тестеров на 10 программистов толковые менеджер позволит?
Ты просто не в курсе, как организуется тестирование ГУИ-приложений. В общем, негативных тестовых сценариев (в основном автоматических) подавляющее большинство. Именно у грамотных менеджеров QA. Наблюдал самолично в крупных штатовских компаниях. Оттуда эту полезную практику и вынес.


G>Нет, то что не происходт — не проверяется. Нет смысла писать тесты для наборов входных данных, которые не появляются в работе. Лучше такие места заткнуть ассертами (или code contracts), любое срабатывание которых очевидно говорит о баге, который надо править.

Вот ты и попался. Я неделю ждал, когда же ты, наконец, проговоришься и назовешь вещи своими именами, без твоих обычных обтекаемых "тут всё ИНАЧЕ!!!".
Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших.


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

Детсад.

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

Детсад.

G>Тем не менее в этом форуме просмотры подсчитываются сразу и нагрузка на этот сайт совсем недетская.

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

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

ГВ>>Ты их по скорости сравнивал?
G>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.

Не можешь, т.к. требования, наример, десяток тыщ запросов в секунду. Твои действия?