Java vs C# vs C++
От: xRAZORx  
Дата: 07.09.15 17:46
Оценка:
Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.
Re: Java vs C# vs C++
От: uncommon Ниоткуда  
Дата: 08.09.15 03:19
Оценка: 9 (1) +9 -1
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Это всё бред. Не заморачивайся. Вообще, на хабре мало чего хорошего бывает.
Отредактировано 08.09.2015 3:20 uncommon . Предыдущая версия .
Re: Java vs C# vs C++
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 08.09.15 05:11
Оценка: +4
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++

Эта статья написана человеком, который явно плохо знает плюсы. Даже с первого взгляда видно, что его плюсовый код пестрит warning'ами (я его не компилировал — честно!). Ну и забавные пассажи про оверхед умных указателей — беее. Если он знает С# также как и плюсы, то смотреть на тест нет смысла.

P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?
Re: Java vs C# vs C++
От: dya-victor Россия  
Дата: 08.09.15 05:32
Оценка: +4
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


В реальном мире инструмент выбирают в зависимости от задачи. Так что такие статьи можно воспринимать как развлекательные
Re[2]: Java vs C# vs C++
От: Blazkowicz Россия  
Дата: 08.09.15 06:37
Оценка: +2 :))) :))
Здравствуйте, Nuzhny, Вы писали:

N>Ну и забавные пассажи про оверхед умных указателей — беее.

Но толика правды в этом же есть? Умные указатели признаны довольно тормозным решением.
Re: Java vs C# vs C++
От: Blazkowicz Россия  
Дата: 08.09.15 06:41
Оценка: +1 :)
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.

Микробенчмарки зачастую бесполезное занятие. Есть куча примеров, где Java догоняет С++ по скорости. Хотя, в среднем, по больнице, это конечно же не так. Есть просто концептуальные решения, которые в Java будут быстрее. Тот же GC, очень эффективно собирает объекты по сравнению с вызовом кучи деструкторов в С++.
Re[2]: Java vs C# vs C++
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 08.09.15 06:53
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?


Сортировку — конечно. А пузырьковую в компьютерной графике используют. Как ни странно, иногда это правильный выбор.
Ce n'est que pour vous dire ce que je vous dis.
Re[3]: Java vs C# vs C++
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 08.09.15 08:11
Оценка: +2
Здравствуйте, Blazkowicz, Вы писали:

N>>Ну и забавные пассажи про оверхед умных указателей — беее.

B>Но толика правды в этом же есть? Умные указатели признаны довольно тормозным решением.

Зависит от типа указателя и от задачи. Да вообще от многих и многих факторов.
Что же мы видим в статье, какую типичную задачу? Сортировку пузырьком. Будут ли умные указатели вносить в неё оверхед? Нет, конечно. К чему тогда этот голословный пассаж? Непонятно.
Re[3]: Java vs C# vs C++
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 08.09.15 08:14
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Сортировку — конечно. А пузырьковую в компьютерной графике используют. Как ни странно, иногда это правильный выбор.


На плюсах или на C# ты писал сортировку? В компьютерной графике — это не на шейдерах случайно? Интересно, когда это реально необходимо, можешь рассказать?
Re[4]: Java vs C# vs C++
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 08.09.15 08:52
Оценка: 5 (1)
Здравствуйте, Nuzhny, Вы писали:

N>На плюсах или на C# ты писал сортировку?


На плюсах! Действительно сложно представить, когда это может понадобится в шарпе.

N>В компьютерной графике — это не на шейдерах случайно? Интересно, когда это реально необходимо, можешь рассказать?


Встречал в сортировке по прозрачности, когда предметов в неправильном порядке мало и они идут друг за другом.
Ce n'est que pour vous dire ce que je vous dis.
Re[2]: Java vs C# vs C++
От: Zenden Россия  
Дата: 09.09.15 04:55
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

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


RAZ>>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.

B>Микробенчмарки зачастую бесполезное занятие. Есть куча примеров, где Java догоняет С++ по скорости. Хотя, в среднем, по больнице, это конечно же не так. Есть просто концептуальные решения, которые в Java будут быстрее. Тот же GC, очень эффективно собирает объекты по сравнению с вызовом кучи деструкторов в С++.

Чо же тогда браузеры не пишут на языке с GC? Там же куча объектов, куча деструкторов.....
Re: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.09.15 06:32
Оценка: +3 -1 :)
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


И на C# и на Java (и даже на JavaScript!) можно писать быстрый код, грубо говоря с незначительным отставанием от C++.
Если выйти за рамки примитивнейшего примера обработки массива целых целиком внутри одной функции — то такой код на Java/C# будет сложнее чем аналогичного кода на C++, такого кода будет больше и он будет намного ниже уровнем.
Основная причина этого в том, что в C++ многие механизмы абстракции бесплатны, либо крайне дешёвые — в то время как на Java/C# они вносят overhead, и для того чтобы догнать C++ от них приходится отказываться.
То есть на C#/Java (да и на JavaScript) стоит выбор — либо использовать высокоуровневые средства и получать тормоза, либо отказываться от них, пилить низкоуровневый boilerplate и получать производительность близкую к высокоуровнему коду C++.

Вот в этой ветке
Автор: mik1
Дата: 02.06.15
есть конкретные примеры на тему — там и C++, и C#, и Java, и даже C++ скомпилированный в JavaScript.
Отредактировано 09.09.2015 6:33 Evgeny.Panasyuk . Предыдущая версия .
Re[3]: Java vs C# vs C++
От: Blazkowicz Россия  
Дата: 09.09.15 06:36
Оценка:
Здравствуйте, Zenden, Вы писали:

Z>Чо же тогда браузеры не пишут на языке с GC? Там же куча объектов, куча деструкторов.....

Во-первых графика. Куча графики с серьезными требованиями к производительности. Особенно учитывая то как клиентская JVM тупит для десктопных приложений.
Во-вторых, а кто сказал, что в браузерах нет GC?
Re[3]: Java vs C# vs C++
От: Poopy Joe Бельгия  
Дата: 09.09.15 07:59
Оценка:
Здравствуйте, Zenden, Вы писали:

Z>Чо же тогда браузеры не пишут на языке с GC? Там же куча объектов, куча деструкторов.....

Можно подумать, что браузеры пишут какие-то небожители, которые всегда знают как сделать правильно.
Re[3]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.09.15 11:05
Оценка: 136 (6)
Здравствуйте, Zenden, Вы писали:

Z>Чо же тогда браузеры не пишут на языке с GC?

Потому что mark-and-sweep gc довольно плохо работает когда много долгоживущих связанных объектов. Время работы GC пропорционально размеру дерева живых объектов. В обычной программе большинство объектов короткоживущие и GC работает хорошо. В сценариях тип браузера гораздо хуже.

Z>Там же куча объектов, куча деструкторов.....

Каких деструкторов? В движках браузера есть свой GC, вернее даже два, один для DOM, другой для JS. В ранних версиях они были не связаны, поэтому циклические ссылки между DOM и объектами JS вызывали утечку. Стандартный аллокатор C++ и любое подобие умных указателей (которые освобождают память в деструкторе) на такой задаче будет тормозить не меньше Java.

В отличие от GC джавы или .net, gc в браузере не пытается убирать весь мусор. Он в первую очередь заточен на низкую латентность. Поэтому каждая страница в современном браузере кушает 50-100мб памяти и очень легко на странице сожрать больше памяти, чем на сервере, который эти страницы раздает тысячам клиентов.

GC в браузере срабатывает не в момент выделения памяти, а в момент когда JS\DOM перестает работать. Это позволяет скрыть задержку GC, которая зачастую доходит до десятков мс (что сильно больше gen1 и на уровне gen2 сборки для C# и Java). То же самое можно и на managed языках сделать. Более того, в .NETном WPF делается примерно тоже, что в браузере, ибо там тоже мелких объектов.
Re[2]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.09.15 12:48
Оценка: +1
Здравствуйте, Nuzhny, Вы писали:

N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?


Я писал сортировки и на плюсах и на шарпе. Вот на джаваскрипте пока не довелось, для продакшна, разумеется.

Вообще сортировки интересны совсем не тем, что их иногда таки нужно писать. 90% простейших алгоритмов в софте это видоизмененные версии сортировок. Если у человека проблема с сортировками, его незачем вообще в код пускать.
Re[2]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.09.15 15:13
Оценка:
Здравствуйте, Nuzhny, Вы писали:



N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?


Я.
http://rsdn.ru/forum/message/577195
Автор: Serginio1
Дата: 22.03.04

http://rsdn.ru/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03

http://rsdn.ru/forum/philosophy/577195.1
Автор: Serginio1
Дата: 22.03.04


http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 09.09.2015 15:18 Serginio1 . Предыдущая версия . Еще …
Отредактировано 09.09.2015 15:17 Serginio1 . Предыдущая версия .
Re: Java vs C# vs C++
От: vsb Казахстан  
Дата: 09.09.15 16:38
Оценка:
В среднем C++ будет быстрее, C# и Java будут идти на одном уровне, C# вероятно немного быстрее. При необходимости C# и Java можно оптимизировать довольно близко к уровню C++ или переписать нужную часть на C++.

В чём C++ будет идти вне конкуренции это в потреблении памяти (Java, C# будут потреблять в разы больше) и в предсказуемости времени выполнения (Java, C# могут включить сборщик мусора в любой момент и приложение может перестать отвечать некоторое время). С последним можно пытаться бороться более-менее успешно, но лучше писать такой код на C++.
Re[2]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.09.15 17:22
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?


Там дело не в том что это bubble sort, а в её интерфейсе.
Реальная сортировка (например std::sort) позволяет сортировать последовательности из разных типов контейнеров, с разными типами элементов, и с разными предикатами сравнения, задаваемыми например замыканиями. Если сделать такой интерфейс, то C#, и тем более Java, будут серьёзно проигрывать.
Re: Java vs C# vs C++
От: lpd Черногория  
Дата: 09.09.15 18:11
Оценка: +1
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Однажды скомпилировал на Java целочисленные вычисления(БПФ), написанные на C++. Разница была в 8 раз.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Re: Java vs C# vs C++
От: MTD https://github.com/mtrempoltsev
Дата: 09.09.15 20:05
Оценка: +1
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре


Это все бессмысленные пиписько-замеры. По моему опыту производительности, что шарпа, что явы в большинстве случаев за глаза. Памяти они по сравнению с С++ все же кушают больше раза в 3, но как правило и это не проблема. С++ требует очень высокой квалификации — на нем можно написать реально быстрый код, а можно по невнимательности сделать тормозной.
Re[2]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.09.15 22:55
Оценка: +3
Здравствуйте, Nuzhny, Вы писали:

N>Ну и забавные пассажи про оверхед умных указателей — беее.


Ещё в комментариях, от автора:

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

Именно сразу и превращаются. По большому счету в чем разница между new\delete и malloc\free, если каждый руками выписывать?
...

unique_ptr нельзя передать просто в метод.
...

Интересно, как вы собрались RAII делать без умных указателей?

Отредактировано 09.09.2015 23:08 Evgeny.Panasyuk . Предыдущая версия .
Re[2]: Java vs C# vs C++
От: Yoriсk  
Дата: 21.09.15 10:20
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?


Почему "писал"? Использовал. Сортировка — довольно типичный исполняемый код.
А мерять пузырёк или quicksort, идущий по умолчание в Linq2Object(т.е. в подавлящем большинстве случаев в .net) — действительно разница невелика.
Отредактировано 21.09.2015 11:34 Yoriсk . Предыдущая версия .
Re: Java vs C# vs C++
От: yatagarasu Беларусь  
Дата: 23.09.15 06:39
Оценка:
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.

Как обычно в таких тестах — по всем измерениям видно что с# медленнее чем с++. Но вывод автор делает "Получается в .NET Native быстродействие такое же, как у C++."
Re: Java vs C# vs C++
От: PM  
Дата: 23.09.15 20:43
Оценка:
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Новость из реальной жизни — переписывание проекта с Java на C++ дало ускорение в 10 раз: http://m.slashdot.org/story/300257

At Cassandra Summit opening today, Avi Kivity and Dor Laor (who had previously written KVM and OSv) announced ScyllaDB — an open-source C++ rewrite of Cassandra, the popular NoSQL database. ScyllaDB claims to achieve a whopping 10 times more throughput per node than the original Java code, with sub-millisecond 99%ile latency. They even measured 1 million transactions per second on a single node. The performance of the new code is attributed to writing it in Seastar — a C++ framework for writing complex asynchronous applications with optimal performance on modern hardware.

Re[2]: Java vs C# vs C++
От: alexzz  
Дата: 23.09.15 21:27
Оценка:
Здравствуйте, PM, Вы писали:

PM>Новость из реальной жизни — переписывание проекта с Java на C++ дало ускорение в 10 раз: http://m.slashdot.org/story/300257


Новость из реальной жизни — переписывание проекта с C++ на C# дало ускорение в 10 раз: http://blogs.msdn.com/b/jonathanh/archive/2005/05/20/optimizing-managed-c-vs-native-c-code.aspx


Не, потом C++ разогнали с пятой попытки до скорости C#, но посмотрите, какой ценой!
Re[3]: Java vs C# vs C++
От: PM  
Дата: 24.09.15 01:07
Оценка:
Здравствуйте, alexzz, Вы писали:

PM>>Новость из реальной жизни — переписывание проекта с Java на C++ дало ускорение в 10 раз: http://m.slashdot.org/story/300257


A>Новость из реальной жизни — переписывание проекта с C++ на C# дало ускорение в 10 раз: http://blogs.msdn.com/b/jonathanh/archive/2005/05/20/optimizing-managed-c-vs-native-c-code.aspx

A>

A>Не, потом C++ разогнали с пятой попытки до скорости C#, но посмотрите, какой ценой!


О, еще один синтетический тест 10-летней давности, когда MS активно продвигала .Net и C# был светлым будущим для всех без исключения. "Память больше не ресурс" ага, помню такое на этом сайте.

По вашей же ссылке первый комментатор справедливо указал, что хоть Реймонд Чен и голова, но как-то быстро он скатился в древний C, заново изобретая велосипеды. Скорее всего потому, что C++ он не знал, как не знал и то, что умные указатели, пулы объектов и регулярные выражения уже существовали в Boost в 2005 году.

Думаю современный C++11 компилятор использовал бы перемещение строк вместо копирования при добавлении новых элементов в словарь. Так что даже первая версия с минимальными изменениями показала бы сопоставимые с C# результаты.

Впрочем, это довольно распространённая практика — взять малознакомый инструмент; попытаться сделать что-то игрушечное; получить результаты хуже, чем со своим любимым молотком; сделать и опубликовать далеко идущие выводы. Вот недавний пример: http://eax.me/cpp-regex/
Re[4]: Java vs C# vs C++
От: alexzz  
Дата: 24.09.15 21:37
Оценка:
Здравствуйте, PM, Вы писали:

PM>По вашей же ссылке первый комментатор справедливо указал, что хоть Реймонд Чен и голова, но как-то быстро он скатился в древний C, заново изобретая велосипеды. Скорее всего потому, что C++ он не знал, как не знал и то, что умные указатели, пулы объектов и регулярные выражения уже существовали в Boost в 2005 году.


PM>Думаю современный C++11 компилятор использовал бы перемещение строк вместо копирования при добавлении новых элементов в словарь. Так что даже первая версия с минимальными изменениями показала бы сопоставимые с C# результаты.


PM>Впрочем, это довольно распространённая практика — взять малознакомый инструмент; попытаться сделать что-то игрушечное; получить результаты хуже, чем со своим любимым молотком; сделать и опубликовать далеко идущие выводы. Вот недавний пример: http://eax.me/cpp-regex/


А, ну понятно. Дословный перевод программы с C++ на C# сходу заработал в 10 раз быстрее, потому что исходная программа была написана на C++ неправильно. Вполне такое может быть. Мне искренне любопытно, как должна быть написана программа на C#, чтобы её дословный перевод на C++ заработал в 10 раз быстрее.
Re[5]: Java vs C# vs C++
От: alex_public  
Дата: 24.09.15 23:20
Оценка: +1
Здравствуйте, alexzz, Вы писали:

A>А, ну понятно. Дословный перевод программы с C++ на C# сходу заработал в 10 раз быстрее, потому что исходная программа была написана на C++ неправильно. Вполне такое может быть. Мне искренне любопытно, как должна быть написана программа на C#, чтобы её дословный перевод на C++ заработал в 10 раз быстрее.


Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))
Re[6]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.09.15 05:06
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))

https://msdn.microsoft.com/ru-ru/library/system.numerics(v=vs.110).aspx
и солнце б утром не вставало, когда бы не было меня
Re[6]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.15 08:01
Оценка: +1
Здравствуйте, alex_public, Вы писали:


_>Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))


Если бы программы состояли исключительно из автовекторизуемых циклов, то вообще не нужен был бы никакой язык, кроме C++ .
Re[7]: Java vs C# vs C++
От: alex_public  
Дата: 25.09.15 14:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))

S> https://msdn.microsoft.com/ru-ru/library/system.numerics(v=vs.110).aspx

И какое это имеет отношение к автовекторизации? )
Re[8]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.09.15 14:27
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))

S>> https://msdn.microsoft.com/ru-ru/library/system.numerics(v=vs.110).aspx

_>И какое это имеет отношение к автовекторизации? )

К авто не имеет, а к векторизации полное.

Вектор поддержкой SIMD типы, такие как Vector4, Matrix3x2, Plane, и Quaternion.

Если тебе нужно решать задачу работы с матрицами выбирай нужные типы
http://www.cyberforum.ru/post7461490.html

http://habrahabr.ru/post/219841/
и солнце б утром не вставало, когда бы не было меня
Отредактировано 25.09.2015 14:34 Serginio1 . Предыдущая версия .
Re[5]: Java vs C# vs C++
От: PM  
Дата: 25.09.15 16:54
Оценка: +1
Здравствуйте, alexzz, Вы писали:

PM>>Впрочем, это довольно распространённая практика — взять малознакомый инструмент; попытаться сделать что-то игрушечное; получить результаты хуже, чем со своим любимым молотком; сделать и опубликовать далеко идущие выводы. Вот недавний пример: http://eax.me/cpp-regex/


A>А, ну понятно. Дословный перевод программы с C++ на C# сходу заработал в 10 раз быстрее, потому что исходная программа была написана на C++ неправильно. Вполне такое может быть. Мне искренне любопытно, как должна быть написана программа на C#, чтобы её дословный перевод на C++ заработал в 10 раз


Я думаю в вычислительных задачах типа такой: C# — from indians by indians в настоящее время сложно обогнать С++, может быть разница будет не в 10 раз, но ощутима.

По ссылкам в новости о ScyllaDB написано, как получился такой результат. Разработчики решали конкретные проблемы, а не сравнивали результаты синтетических тестов.
Re[6]: Java vs C# vs C++
От: alexzz  
Дата: 25.09.15 21:42
Оценка: 66 (2)
Здравствуйте, PM, Вы писали:

PM>Я думаю в вычислительных задачах типа такой: C# — from indians by indians в настоящее время сложно обогнать С++, может быть разница будет не в 10 раз, но ощутима.


Там дальше по теме Sinix привёл unsafe вариант на C#, который работает в 1,8 раза быстрее оригинала на C#. Далее цитата самого автора задачи:

Глянул сейчас. В общем на старой машинке (C2D, WinXP 32) C# unsafe вариант кода исполняется почти с той же производительностью, что и C++ вариант с SIMD


Я написал свой вариант на C#, работает ещё быстрее оригинала, в 2,3 раза: http://pastebin.com/v2ZMRu86

original: 9881
optimized: 4342

У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.

PM>По ссылкам в новости о ScyllaDB написано, как получился такой результат. Разработчики решали конкретные проблемы, а не сравнивали результаты синтетических тестов.


Про то, что ускорение в 10 раз вызвал именно переход с Java на C++, упоминается лишь в желтушном заголовке новости.
Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 25.09.15 23:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>И какое это имеет отношение к автовекторизации? )

S>К авто не имеет, а к векторизации полное.

Ну так тогда и код не будет одинаковым, даже близко. ))) В C++ останется изначальный простенький цикл, а в C# надо будет нагородить всяких ужасов. А в вопросе речь шла об одинаковом коде.

S>

S> Вектор поддержкой SIMD типы, такие как Vector4, Matrix3x2, Plane, и Quaternion.

S>Если тебе нужно решать задачу работы с матрицами выбирай нужные типы
S>http://www.cyberforum.ru/post7461490.html
S>http://habrahabr.ru/post/219841/

Это всё было в C++ (в виде библиотек) лет 15 назад и от этого уже давно уходят к совсем другим решениям. А в C# только сейчас к этому пришли. Поздравляю. )))
Re[5]: Java vs C# vs C++
От: Nikе Россия  
Дата: 25.09.15 23:42
Оценка:
Здравствуйте, Don Reba, Вы писали:

DR>Встречал в сортировке по прозрачности, когда предметов в неправильном порядке мало и они идут друг за другом.


Сортировка вставками?
Нужно разобрать угил.
Re: Java vs C# vs C++
От: Nikе Россия  
Дата: 25.09.15 23:50
Оценка: 18 (1)
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Приходится писать на всех языках в зависимости от потребностей. У меня получается так, что:
— ядро рабочего приложения на работе пишется на С++, т.к. он кроссплатформенный.
— кодогенераторы — питон.
— интерфейс — самописный специализированный езыг.
— графика — glsl
— домашние исследования по алгоритмам — C#
— домашний сервак — Ruby
— сейчас вот прожку на андроиде пишу на яве, на ней же писал некоторые серваки пару лет назад.
Если не считать Ruby (который был выбран из любопытства) то остальные языки были практически безальтернативны.
Нужно разобрать угил.
Re[7]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 00:33
Оценка: +1
Здравствуйте, alexzz, Вы писали:

A>Там дальше по теме Sinix привёл unsafe вариант на C#, который работает в 1,8 раза быстрее оригинала на C#.


Угу. Сделав дико страшный код (в сравнение и с C# оригиналом и с C++ оригиналом) он сумел ускориться в пару раз, но при этом отставание в разы от C++ всё равно сохранилось. )))

A>Я написал свой вариант на C#, работает ещё быстрее оригинала, в 2,3 раза: http://pastebin.com/v2ZMRu86

A>original: 9881
A>optimized: 4342

ОК, я протестировал этот код на той же машине, что и в тех сообщения. Так что могу поздравить: в данных результатах http://rsdn.ru/forum/philosophy/6117201.1
Автор: alex_public
Дата: 18.07.15
мы смело можем заменить значение для C# unsafe с 5,0 секунд на 4,6 секунды. Что впрочем вообще никак не меняет общую картину.

Кстати, возник ещё один интересный нюанс. Оригинальный C# из данного исходника исполнялся у меня 8,1 секунды, а не 8,7 секунды, как в изначальном коде. Хотя всё выглядит практически одинаково. Я немного поигрался с кодом и выяснил, что это происходит при передаче данных в Test в виде параметров (у меня это были статические члены класса приложения). Это конечно же характеризует оптимизатор .net с интересной стороны. )))

A>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


Это неверное подозрение. Что очевидно и из практики (см. ссылку выше, там есть цифры для C++ без simd) и из общетеоретических соображений. Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.
Re[8]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.09.15 00:54
Оценка: :)))
Здравствуйте, alex_public, Вы писали

_>Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.


Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным. А достаточно надежный код будет иметь "букет замедляющих факторов".
Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 02:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.

G>Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным. А достаточно надежный код будет иметь "букет замедляющих факторов".

Что-то я не понял этого твоего высказвания) В первом предложение ты выступаешь против моего тезиса, а в следующих 4-ёх излагаешь подтверждающие его аргументы. )))

Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )
Re[10]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.09.15 05:46
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

А где это в .Net "все функции виртуальные"? Ты с Java не спутал?
Другое дело, что С++ может больше использовать инлайн, что может приводить к ускорении при частом вызове таких функций.
и солнце б утром не вставало, когда бы не было меня
Re[10]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.09.15 05:50
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>И какое это имеет отношение к автовекторизации? )

S>>К авто не имеет, а к векторизации полное.

_>Ну так тогда и код не будет одинаковым, даже близко. ))) В C++ останется изначальный простенький цикл, а в C# надо будет нагородить всяких ужасов. А в вопросе речь шла об одинаковом коде.


А зачем городить? Наоборот для решения конкретной задачи свой инструмент.
S>>

S>> Вектор поддержкой SIMD типы, такие как Vector4, Matrix3x2, Plane, и Quaternion.

S>>Если тебе нужно решать задачу работы с матрицами выбирай нужные типы
S>>http://www.cyberforum.ru/post7461490.html
S>>http://habrahabr.ru/post/219841/

_>Это всё было в C++ (в виде библиотек) лет 15 назад и от этого уже давно уходят к совсем другим решениям. А в C# только сейчас к этому пришли. Поздравляю. )))


Это не C#, это .Net. Рано или поздно придут и к другим решениям и бОльшей оптимизации компилятора. Пока для Net куча других задач, а главное быстрота и удобство и безопасность программирования.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Java vs C# vs C++
От: PM  
Дата: 26.09.15 07:57
Оценка:
Здравствуйте, alexzz, Вы писали:

A>Я написал свой вариант на C#, работает ещё быстрее оригинала, в 2,3 раза: http://pastebin.com/v2ZMRu86


A>original: 9881

A>optimized: 4342

Это хорошо, только вы ведь использовали internal unsafe class Program и fixed указатели для обработки массива. Немного волшебства и в этом соревновании двух бегунов C# пришел к финишу вторым, а С++ предпоследним

A>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


PM>>По ссылкам в новости о ScyllaDB написано, как получился такой результат. Разработчики решали конкретные проблемы, а не сравнивали результаты синтетических тестов.


A>Про то, что ускорение в 10 раз вызвал именно переход с Java на C++, упоминается лишь в желтушном заголовке новости.


Ок, если вам интересно как сравнивали Cassandra и Scylla, то разработчики этого не скрывают — http://www.scylladb.com/technology/cassandra-vs-scylla-benchmark/

В заголовок новости не поместилась информация о том, что они:
У меня есть сомнения, что первые 2 пункта легко реализуемы в управляемых средах (не знаю, добавили ли уже в Java value types)
Re[10]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.09.15 12:27
Оценка: :)
Здравствуйте, alex_public, Вы писали:

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


_>>>Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.

G>>Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным. А достаточно надежный код будет иметь "букет замедляющих факторов".

_>Что-то я не понял этого твоего высказвания) В первом предложение ты выступаешь против моего тезиса, а в следующих 4-ёх излагаешь подтверждающие его аргументы. )))


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

_>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

Это ты про Java надо полагать? Или решил показать незнание?
Так вот Java умеет девиртуализировать вызовы и размещать объекты на стеке. Руками не контролируется, делается путем анализа кода в JIT. Именно поэтому Java в математике весьма неплохо себя показывает. Так что недостаток языка вполне может быть (и на практике будет) скомпенсирован рантаймом. А вот когда дело касается реальной безопасности то, здравствуй "букет замедляющих факторов", независимо от языка.
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 13:42
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

_>>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

S> А где это в .Net "все функции виртуальные"? Ты с Java не спутал?

Это было про языки программирования в целом. Тем более, что у нас как раз такой сабж. )

S>Другое дело, что С++ может больше использовать инлайн, что может приводить к ускорении при частом вызове таких функций.


Да, совершенно верно верно. Это один из главных причин. А другая главная причина — это уменьшение косвенности (которую ненавидят кэши процессора).
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 13:44
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Это всё было в C++ (в виде библиотек) лет 15 назад и от этого уже давно уходят к совсем другим решениям. А в C# только сейчас к этому пришли. Поздравляю. )))

S> Это не C#, это .Net. Рано или поздно придут и к другим решениям и бОльшей оптимизации компилятора. Пока для Net куча других задач, а главное быстрота и удобство и безопасность программирования.

Кстати, в C++ от этого уходили когда-то исключительно из-за неудобства такой работы для программиста. Но сейчас актуальны и другие причины. К примеру на современных компьютерах при таком подходе необходимо использовать уже vector8, а не vector4. А в ближайшем будущем понадобится уже и vector16. )))
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 13:52
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

_>>Что-то я не понял этого твоего высказвания) В первом предложение ты выступаешь против моего тезиса, а в следующих 4-ёх излагаешь подтверждающие его аргументы. )))

G>Специально для тебя повторю — замедляющих факторов полно в любом языке. Даже в С++ (одни смартпоинтеры чего стоят). А дальше логичный вывод — чем безопаснее программа, тем больше "замедляющих факторов" будет.

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

Ну и насчёт смартпоинтеров... Интересно глянуть где ты там найдёшь замедление скажем у std::unique_ptr (основной современный инструмент для таких целей).

_>>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

G>Это ты про Java надо полагать? Или решил показать незнание?

И Java и многие другие. )

G>Так вот Java умеет девиртуализировать вызовы и размещать объекты на стеке. Руками не контролируется, делается путем анализа кода в JIT. Именно поэтому Java в математике весьма неплохо себя показывает. Так что недостаток языка вполне может быть (и на практике будет) скомпенсирован рантаймом. А вот когда дело касается реальной безопасности то, здравствуй "букет замедляющих факторов", независимо от языка.


Да, для меня было весьма неожиданно, что жабка обошла C# (хотя и совсем на копейки) в обсуждаемом выше тесте. Но до реального быстродействия ей всё равно далеко.
Re[8]: Java vs C# vs C++
От: alexzz  
Дата: 26.09.15 17:05
Оценка:
Здравствуйте, alex_public, Вы писали:

A>>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


_>Это неверное подозрение. Что очевидно и из практики (см. ссылку выше, там есть цифры для C++ без simd) и из общетеоретических соображений. Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.


Но ведь твоя таблица как раз подтверждает мои подозрения: C++ no-simd — 3,5 c, мой код на C# — 4,6 с. Разница в 1,3 раза. Не в два и даже не в полтора. Это как 1,3 vs 1,0 с (и то, и другое быстро) или 130 vs 100 с (и то, и другое медленно). Ощутимо быстрее C++ стал, только когда компилятор сумел что-то векторизовать. Я об этом и говорил — С++ становится ощутимо быстр, если повезёт с векторизацией; если нет, то С++ либо незначительно быстрее, либо вообще не быстрее.

Кстати, можно посмотреть бинарники C++, которые показывают 1,3 и 0,6 с? Мне любопытно посмотреть, что там наколдовано.

И ещё, пользуясь случаем, вопросы не в тему:
— Код делает HDR-blur? Если нет, то почему int[], а не byte[]?
— Зачем там условие внутри циклов?
Re[8]: Java vs C# vs C++
От: alexzz  
Дата: 26.09.15 17:19
Оценка:
Здравствуйте, PM, Вы писали:

A>>original: 9881

A>>optimized: 4342

PM>Это хорошо, только вы ведь использовали internal unsafe class Program и fixed указатели для обработки массива.


Это же штатный функционал. Надо — используешь, не надо — не используешь. Я давно заметил, что у некоторых товарищей (обычно в основном пишущих на C++) имеется фобия на указатели в C#, но ни я, ни C# в этом не виноваты
Re[9]: Java vs C# vs C++
От: xRAZORx  
Дата: 26.09.15 18:05
Оценка:
Здравствуйте, alexzz, Вы писали:

A>Но ведь твоя таблица как раз подтверждает мои подозрения: C++ no-simd — 3,5 c, мой код на C# — 4,6 с. Разница в 1,3 раза. Не в два и даже не в полтора. Это как 1,3 vs 1,0 с (и то, и другое быстро) или 130 vs 100 с (и то, и другое медленно). Ощутимо быстрее C++ стал, только когда компилятор сумел что-то векторизовать. Я об этом и говорил — С++ становится ощутимо быстр, если повезёт с векторизацией; если нет, то С++ либо незначительно быстрее, либо вообще не быстрее.


То есть получается, что джава вообще в хвосте плетется как всегда, да?
Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 21:02
Оценка: 18 (1)
Здравствуйте, alexzz, Вы писали:

_>>Это неверное подозрение. Что очевидно и из практики (см. ссылку выше, там есть цифры для C++ без simd) и из общетеоретических соображений. Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.

A>Но ведь твоя таблица как раз подтверждает мои подозрения: C++ no-simd — 3,5 c, мой код на C# — 4,6 с. Разница в 1,3 раза. Не в два и даже не в полтора. Это как 1,3 vs 1,0 с (и то, и другое быстро) или 130 vs 100 с (и то, и другое медленно). Ощутимо быстрее C++ стал, только когда компилятор сумел что-то векторизовать. Я об этом и говорил — С++ становится ощутимо быстр, если повезёт с векторизацией; если нет, то С++ либо незначительно быстрее, либо вообще не быстрее.

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

A>Кстати, можно посмотреть бинарники C++, которые показывают 1,3 и 0,6 с? Мне любопытно посмотреть, что там наколдовано.


Эмм, так код для варианта 3,5 секунды и 1,3 секунды абсолютно одинаковый. Разница только в опциях компилятора. И этот код я уже показывал в том обсуждение: http://rsdn.ru/forum/flame.comp/6072279.1
Автор: alex_public
Дата: 09.06.15


Что касается варианта с 0,6 секунды, то его сейчас под рукой нет, но я могу его описать: там уже используется ручная векторизация (intrinsics), а не автовекторизация. И да, код там уже не такой симпатичный, но зато выжимает из процессора всю теоретически допустимую мощь (в расчёте на ядро).

A>И ещё, пользуясь случаем, вопросы не в тему:

A>- Код делает HDR-blur? Если нет, то почему int[], а не byte[]?

Ну вообще то изначально этот код был просто специально для теста выбран (до него кстати в тесте был другой, с плавающей точкой, но там возникли большие неоднозначности в сравнения разных языков). Но у него естественно есть реальный прообраз. И нет, это естественно не blur (зачем может быть blur настолько многократный?), а одна из разновидностей клеточного автомата. Кстати, сразу замечу, что подобные автоматы — это не обязательно весёлая игрушка программистов. К примеру подобный код может моделировать различные физические процессы (соответствующие диф. уравнения совпадают), скажем распространения тепла в твёрдом теле. Ну и в любом случае, даже без понимания сути процессов, таким образом можно получать весьма любопытные картинки. Т.е. вот даже та жалкая тысяча итераций из нашего теста даёт вот такое:
  Скрытый текст
А если сделать в 100 раз больше итерация, то пойдут уже весьма сюрреалистичные картинки. )

A>- Зачем там условие внутри циклов?


1. С точки зрения теста хотелось что посложнее (данный if сильно гадит оптимизатору в любом языке).
2. С точки зрения клеточного автомата это означает, что белые точки (задаются в изначальном изображение) немодифицируемы.
3. С точки зрения моделирования процессов (того же тепла в твёрдом теле) это означает наличие источников тепла с фиксированной температурой.
Re[10]: Java vs C# vs C++
От: alexzz  
Дата: 26.09.15 23:45
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну во-первых твой код — это не C#, а unsafe C#, что существенно. Причём даже не просто unsafe (в смысле модификатора), а ещё и дико страшный из-за необходимости обхода всех штатных тормозов.


Не понял конец фразы. Тормоза, связанные с закреплением объектов в памяти, они как Лохнесское чудовище — все про них слышали, но никто не видел. Надо просто соблюдать рекомендации.

_>Т.е. писать так код постоянно — это убиться. )))


Навскидку для 90% кода скорость вообще не важна — делаешь его красивым и удобным в обслуживании. Для ещё 9% просто используешь быстрый алгоритм, подходящие типы коллекций, многопоточность. В оставшихся случаях можно пошаманить:
— самодельные специфические коллекции,
— unsafe,
— Mono.Simd / System.Numerics,
— вызов нативного кода (самый неудобный вариант).

Короче, такого кода, где unsafe имеет смысл, надо пол-процента (если вообще надо). И пофиг, как он выглядит. Ты же не пишешь весь свой код интринзиками.

_>Ну вообще то изначально этот код был просто специально для теста выбран (до него кстати в тесте был другой, с плавающей точкой, но там возникли большие неоднозначности в сравнения разных языков). Но у него естественно есть реальный прообраз. И нет, это естественно не blur (зачем может быть blur настолько многократный?), а одна из разновидностей клеточного автомата.


Прикольно. Я свой вариант кода без изменений взял из моего старого исходника блюра Но раз это не он, то у меня надо заменить
var buffer = new int[image.Length];
на
var buffer = (int[])image.Clone();

Впрочем, на скорость расчётов это не влияет.

Имхо, с тысячами итераций тебе бы надо на GPU перейти, а не мучить С++.
Отредактировано 26.09.2015 23:46 alexzzzz . Предыдущая версия .
Re[3]: Java vs C# vs C++
От: uncommon Ниоткуда  
Дата: 27.09.15 01:58
Оценка: :))
Здравствуйте, alexzz, Вы писали:

A>Новость из реальной жизни — переписывание проекта с C++ на C# дало ускорение в 10 раз: http://blogs.msdn.com/b/jonathanh/archive/2005/05/20/optimizing-managed-c-vs-native-c-code.aspx

A>

A>Не, потом C++ разогнали с пятой попытки до скорости C#, но посмотрите, какой ценой!


О! Rico Mariani. Знаем, знаем. Пустослов известный. Больше всего он любит пи31415деть о процессе организации процесса улучшения процесса оптимизации процесса.
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 27.09.15 02:53
Оценка: 36 (1) +1
Здравствуйте, alexzz, Вы писали:

_>>Ну во-первых твой код — это не C#, а unsafe C#, что существенно. Причём даже не просто unsafe (в смысле модификатора), а ещё и дико страшный из-за необходимости обхода всех штатных тормозов.

A>Не понял конец фразы. Тормоза, связанные с закреплением объектов в памяти, они как Лохнесское чудовище — все про них слышали, но никто не видел. Надо просто соблюдать рекомендации.

Нет, здесь речь шла о том, что ты используешь *array вместо array[], чтобы обойти штатные тормоза из-за проверки границ массива. И это явно не способствует красоте кода. )))

_>>Т.е. писать так код постоянно — это убиться. )))

A>Навскидку для 90% кода скорость вообще не важна — делаешь его красивым и удобным в обслуживании. Для ещё 9% просто используешь быстрый алгоритм, подходящие типы коллекций, многопоточность. В оставшихся случаях можно пошаманить:
A>- самодельные специфические коллекции,
A>- unsafe,
A>- Mono.Simd / System.Numerics,
A>- вызов нативного кода (самый неудобный вариант).
A>Короче, такого кода, где unsafe имеет смысл, надо пол-процента (если вообще надо). И пофиг, как он выглядит. Ты же не пишешь весь свой код интринзиками.

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

Ну точнее если говорить по честному, то в 6+ раз оно будет быстрее только на подобном коде (с обработкой массивов и т.п.), а в обычном коде скорее всего будет 2+ раза. Но это тоже совсем не мало. ))) Да и обработка массивов тоже частенько встречается. )

A>Имхо, с тысячами итераций тебе бы надо на GPU перейти, а не мучить С++.


Ну вообще то по реальным делам у меня скорее вещи типа blur'a возникают (причём в реальном времени), а не конечные автоматы. Только последние гораздо удобнее для подобного теста, при почти одинаковом коде.

Но вообще может и попробую здесь GPU в ближайшее время — с появлением openacc это стало настолько же тривиально, как и распараллеливания по ядрам CPU с помощью openmp.
Re[12]: Java vs C# vs C++
От: alexzz  
Дата: 27.09.15 12:39
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Нет, здесь речь шла о том, что ты используешь *array вместо array[], чтобы обойти штатные тормоза из-за проверки границ массива. И это явно не способствует красоте кода. )))


Нифига, звёздочки в два раза красивее квадратных скобочек!
Имхо, это очень субъективно. Мне лично оригинал с кучей [] и вычислений индексов тоже сильно не нравится, как выглядит. Это скорее вопрос форматирования/оформления кода.
Re[4]: Java vs C# vs C++
От: alexzz  
Дата: 27.09.15 13:10
Оценка:
Здравствуйте, uncommon, Вы писали:

U>О! Rico Mariani. Знаем, знаем. Пустослов известный. Больше всего он любит пи31415деть о процессе организации процесса улучшения процесса оптимизации процесса.


Во-первых, там не пиздё%, а сплошные циферки.
Во-вторых, браузер Edge таки очень шустр.
Re[7]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 27.09.15 13:58
Оценка: 6 (1) -1
Здравствуйте, alexzz, Вы писали:

A>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


1. Возьми тест из обсуждаемой статьи и сделай нормальный интерфейс для сортировки (например как у std::sort) — позволяющий сортировать последовательности из разных типов контейнеров, с разными типами элементов, и с разными предикатами сравнения, задаваемыми например замыканиями. Для пущей уверенности выключи любую автовекторизацию при замерах.

2. Посмотри вот этот пример
Автор: Evgeny.Panasyuk
Дата: 23.12.14
— оптимизаторы C++ щёлкают такой код на раз-два, выдавая ASM код идентичный ручной низкоуровневой версии.

3. Ещё такой пример
Автор: Evgeny.Panasyuk
Дата: 20.06.15
: высокоуровневый код C++ скомпилированный в JavaScript почти в два раза быстрее аналога на C# в своей родной среде.
JavaScript, в веб-браузере, Карл!

Во всех случаях никакой векторизации
Отредактировано 27.09.2015 14:04 Evgeny.Panasyuk . Предыдущая версия .
Re[2]: Java vs C# vs C++
От: airatsa Россия  
Дата: 28.09.15 04:38
Оценка: +1
Здравствуйте, lpd, Вы писали:

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


RAZ>>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


lpd>Однажды скомпилировал на Java целочисленные вычисления(БПФ), написанные на C++. Разница была в 8 раз.


В чью сторону?
Re[6]: Java vs C# vs C++
От: vdimas Россия  
Дата: 28.09.15 08:36
Оценка:
Здравствуйте, Nikе, Вы писали:

DR>>Встречал в сортировке по прозрачности, когда предметов в неправильном порядке мало и они идут друг за другом.

N>Сортировка вставками?

Пузырьковая для лучшего случая однопроходная.
Re[2]: Java vs C# vs C++
От: vdimas Россия  
Дата: 28.09.15 08:57
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

RAZ>>Тот же GC, очень эффективно собирает объекты по сравнению с вызовом кучи деструкторов в С++.


Если в С++ у некоего типа тривиальный деструктор, то он не вызывается. А если во время разрушения должен быть выполнен некий код, то он должен быть выполнен на любом языке.

Среды с GC делают одну интересную вещь — создают объекты в одном потоке, а удаляют из другого. В С++ тоже используют подобные механизмы при надобности — такое поведение хорошо подходит для систем с характерными неравномерными нагрузками, которые можно сгладить за счет памяти.

Опять же, системные менеджеры памяти, начиная еще со времен Висты, уже много лет как сделали ненужным разработку таких самописных менеджеров памяти, которые писались исключительно для целей, скажем, "однопоточности", т.е. для того, чтобы разные потоки не сталкивались на мьютексе глобального менеджера памяти С/С++. В мире Линукс примерно в то же самое время происходили аналогичные изменения.

Т.е., в плане конкурентной работы у нейтивных менеджеров в последние годы всё очень даже неплохо.
Re[8]: Java vs C# vs C++
От: alexzz  
Дата: 28.09.15 21:25
Оценка: +1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

A>>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


EP>1. Возьми тест из обсуждаемой статьи и сделай нормальный интерфейс для сортировки (например как у std::sort) — позволяющий сортировать последовательности из разных типов контейнеров, с разными типами элементов, и с разными предикатами сравнения, задаваемыми например замыканиями. Для пущей уверенности выключи любую автовекторизацию при замерах.


Моё большое имхо: код, который оперирует разными универсальными обобщёнными абстракциями, ― это те 90%, от которых не требуется скорости. Он пишется так, чтобы было легко писать, читать и поддерживать, без оглядки на производительность. Если явно не тормозит, то и замечательно. По крайней мере, у меня дела обычно обстоят именно так.

Сравнивать скорость имеет смысл у того кода, который в самом деле её требует и который пишется с оглядкой на скорость, а не на удобство, и использует все доступные в языке средства оптимизации.

EP>3. Ещё такой пример
Автор: Evgeny.Panasyuk
Дата: 20.06.15
: высокоуровневый код C++ скомпилированный в JavaScript почти в два раза быстрее аналога на C# в своей родной среде.

EP>JavaScript, в веб-браузере, Карл!

Вот в этом посте
Автор: greenpci
Дата: 05.06.15
я нашёл рядом два исходника на C++ и C#. У варианта С++ в настройках Optimization включил всё, что было на максимум. У варианта на C# сделал очевидную оптимизацию в коде (ценой в несколько миллисекунд), поменял

for (int i = 0; i < n; i++)
    v[i] = v[i] * u[i];

на
for (int i = 0; i < v.Length; i++)
    v[i] *= u[i];


Запустил оба варианта раз по десять, лучшие результаты такие:

C#
.NET Elapsed: 52,0000 ms

C++
Elapsed = 51.3899 ms

С++ победил!
Отредактировано 28.09.2015 21:29 alexzzzz . Предыдущая версия . Еще …
Отредактировано 28.09.2015 21:27 alexzzzz . Предыдущая версия .
Отредактировано 28.09.2015 21:26 alexzzzz . Предыдущая версия .
Re[9]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 28.09.15 22:05
Оценка:
Здравствуйте, alexzz, Вы писали:

EP>>1. Возьми тест из обсуждаемой статьи и сделай нормальный интерфейс для сортировки (например как у std::sort) — позволяющий сортировать последовательности из разных типов контейнеров, с разными типами элементов, и с разными предикатами сравнения, задаваемыми например замыканиями. Для пущей уверенности выключи любую автовекторизацию при замерах.

A>Моё большое имхо: код, который оперирует разными универсальными обобщёнными абстракциями, ― это те 90%, от которых не требуется скорости. Он пишется так, чтобы было легко писать, читать и поддерживать, без оглядки на производительность. Если явно не тормозит, то и замечательно. По крайней мере, у меня дела обычно обстоят именно так.

А у меня тот код который быстрый обычно оперирует обобщёнными абстракциями — это более высокий уровень — because I can. И в таком коде я спокойно могу использовать например ФВП и замыкания, а не расписывать вручную каждую комбинацию алгоритма, контейнера и предиката — because I can.

A>Сравнивать скорость имеет смысл у того кода, который в самом деле её требует и который пишется с оглядкой на скорость, а не на удобство, и использует все доступные в языке средства оптимизации.


Это же одна из главных фишек C++ — удобно писать быстрый код. Цитата в тему:

"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu


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

EP>>3. Ещё такой пример
Автор: Evgeny.Panasyuk
Дата: 20.06.15
: высокоуровневый код C++ скомпилированный в JavaScript почти в два раза быстрее аналога на C# в своей родной среде.

EP>>JavaScript, в веб-браузере, Карл!
A>Вот в этом посте
Автор: greenpci
Дата: 05.06.15
я нашёл рядом два исходника на C++ и C#. У варианта С++ в настройках Optimization включил всё, что было на максимум. У варианта на C# сделал очевидную оптимизацию в коде (ценой в несколько миллисекунд), поменял

A>
for (int i = 0; i < n; i++)
A>    v[i] = v[i] * u[i];

A>на
A>
for (int i = 0; i < v.Length; i++)
A>    v[i] *= u[i];

A>Запустил оба варианта раз по десять, лучшие результаты такие:
A>C#
A>.NET Elapsed: 52,0000 ms
A>C++
A>Elapsed = 51.3899 ms
A>С++ победил!

C++ с ФВП и лямбдой дал результат сравнимый с рукопашным низкоуровневым циклом C# А теперь попробуй сравни аналогичный код на C# с ФВП и лямбдой.

Вообще, я в и той теме говорил, да уже и в этой сказал: и на C# и на Java можно писать быстрый код, который будет отставать от C++ буквально на десятки процентов (не считая удары ниже пояса типа автовекторизации/автопареллизации). Но при этом на C++ будет высокоуровневый код, а на C#, и тем более на Java — низкоуровневая возня, что ты успешно и продемонстрировал.
Re[10]: Java vs C# vs C++
От: alexzz  
Дата: 28.09.15 23:37
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>А у меня тот код который быстрый обычно оперирует обобщёнными абстракциями — это более высокий уровень — because I can. И в таком коде я спокойно могу использовать например ФВП и замыкания, а не расписывать вручную каждую комбинацию алгоритма, контейнера и предиката — because I can.


A>>Сравнивать скорость имеет смысл у того кода, который в самом деле её требует и который пишется с оглядкой на скорость, а не на удобство, и использует все доступные в языке средства оптимизации.


EP>Это же одна из главных фишек C++ — удобно писать быстрый код. Цитата в тему:

EP>

EP>"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu


Точно подмечено, легко писать быстрый код и трудно весь остальной. Которого на порядки больше

Теоретически должно быть удобно писать основной код на C#/Java и вызывать функции на C++ там, где нужна чистая скорость — что-нибудь типа перемолотить большой объём данных или миллион раз перемножить несколько матриц. Но практически [у меня] получается, что удобнее в нескольких ограниченных местах снизить уровень абстракции и запачкать руки низкоуровневым кодом, чем смешивать в проекте несколько языков и таскать за управляемой сборкой пару нативных бинарников для x86/x64. Потому что дополнительная прибавка в скорости не оправдывает лишней мороки.

EP>C++ с ФВП и лямбдой дал результат сравнимый с рукопашным низкоуровневым циклом C# А теперь попробуй сравни аналогичный код на C# с ФВП и лямбдой.


С лямбдой C# показывает 81мс. С++ быстрее всего в полтора раза. Как обычно.
Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 29.09.15 00:52
Оценка:
Здравствуйте, alexzz, Вы писали:

A>Запустил оба варианта раз по десять, лучшие результаты такие:

A>C#
A>.NET Elapsed: 52,0000 ms
A>C++
A>Elapsed = 51.3899 ms
A>С++ победил!

Что-то какие-то сомнительные результаты. Я сейчас запустил у себя прямо этот код и получил:
.NET Elapsed: 96,0000 ms
Elapsed = 38.0022 ms.

Причём если отличие второго твоего результата я ещё могу объяснить использованием какого-нибудь сомнительного компилятора C++ (типа старого msvc) или же более слабым процессором, то первый результат для меня очень удивителен, т.к. компилятор C# вроде как только один (вариант что у тебя процессор в 2 раза быстрее моего Haswell Xeon отпадает сам собой).
Re: Java vs C# vs C++
От: Zenden Россия  
Дата: 29.09.15 02:03
Оценка: :)
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Скажите, что принципиально нельзя написать написать на C++ но можно на java или C#?
Re[2]: Java vs C# vs C++
От: airatsa Россия  
Дата: 29.09.15 05:58
Оценка:
Здравствуйте, Zenden, Вы писали:

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


RAZ>>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Z>Скажите, что принципиально нельзя написать написать на C++ но можно на java или C#?


На C++ можно написать java и C# и остальные языки.
И в конечном итоге все это сводится к машине Тьюринга.

Так что дело в выразительности языков и, как следствие, производительности программиста.
Re[10]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 29.09.15 07:20
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>А у меня тот код который быстрый обычно оперирует обобщёнными абстракциями — это более высокий уровень — because I can. И в таком коде я спокойно могу использовать например ФВП и замыкания, а не расписывать вручную каждую комбинацию алгоритма, контейнера и предиката — because I can.


А как написать сортировку, не расписав вручную для каждого контейнера?
Хотя я задавался таким вопросом помню, и таки да, такая сортировка существует, но от оптимальной она далека.
Так что обобщённость тоже имеет свой предел.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[10]: Java vs C# vs C++
От: v6  
Дата: 29.09.15 10:12
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Что-то какие-то сомнительные результаты. Я сейчас запустил у себя прямо этот код и получил:

_>.NET Elapsed: 96,0000 ms
_>Elapsed = 38.0022 ms.

_>Причём если отличие второго твоего результата я ещё могу объяснить использованием какого-нибудь сомнительного компилятора C++ (типа старого msvc) или же более слабым процессором, то первый результат для меня очень удивителен, т.к. компилятор C# вроде как только один (вариант что у тебя процессор в 2 раза быстрее моего Haswell Xeon отпадает сам собой).


Ну как "один"? Есть Roslyn, в котором большой упор сделан как раз на оптимизацию кода.
А тут даже непонятно под какую платформу код компилился, для x86 и x64 IL может быть в некоторых случаях сильно разным.
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 29.09.15 21:17
Оценка:
Здравствуйте, v6, Вы писали:

v6>Ну как "один"? Есть Roslyn, в котором большой упор сделан как раз на оптимизацию кода.


В смысле один производитель. Понятно, что могут быть разные версии, но сомневаюсь что из-за этого может быть разница в 2 раза. Тем более, что у меня тоже не совсем древняя версия стоит (хотя и не Roslyn).

v6>А тут даже непонятно под какую платформу код компилился, для x86 и x64 IL может быть в некоторых случаях сильно разным.


Так там же в коде одни вычисления с double.
Re[10]: Java vs C# vs C++
От: alexzz  
Дата: 29.09.15 21:31
Оценка:
Здравствуйте, alex_public, Вы писали:

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


A>>Запустил оба варианта раз по десять, лучшие результаты такие:

A>>C#
A>>.NET Elapsed: 52,0000 ms
A>>C++
A>>Elapsed = 51.3899 ms
A>>С++ победил!

_>Что-то какие-то сомнительные результаты. Я сейчас запустил у себя прямо этот код и получил:

_>.NET Elapsed: 96,0000 ms
_>Elapsed = 38.0022 ms.

Я посмотрел. У меня достаточно скомпилировать C#-пример под любую версию .Net Framework от 4 и выше (CLR > 2.0), чтобы скорость не отличалась от С++. Посмотрел дизассемблер. Если выбрать 3.5, то оператор умножения не инлайнится, а внутри него ещё есть вызов конструктора, который тоже не инлайнится. В более поздних версиях инлайнится всё.

Версию x86 особо не разглядывал, она всего на несколько миллисекунд медленнее x64. Непринципиально.
Отредактировано 29.09.2015 21:38 alexzzzz . Предыдущая версия .
Re[11]: Java vs C# vs C++
От: alexzz  
Дата: 29.09.15 21:35
Оценка:
Здравствуйте, v6, Вы писали:

v6>Ну как "один"? Есть Roslyn, в котором большой упор сделан как раз на оптимизацию кода.

v6>А тут даже непонятно под какую платформу код компилился, для x86 и x64 IL может быть в некоторых случаях сильно разным.

IL же на то и IL, что одинаковый на всех платфоормах. Иначе в нём смысла нет. Разницу в скорости, если она есть, делает JIT.
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 29.09.15 22:06
Оценка:
Здравствуйте, alexzz, Вы писали:

A>Я посмотрел. У меня достаточно скомпилировать C#-пример под любую версию .Net Framework от 4 и выше (CLR > 2.0), чтобы скорость не отличалась от С++. Посмотрел дизассемблер. Если выбрать 3.5, то оператор умножения не инлайнится, а внутри него ещё есть вызов конструктора, который тоже не инлайнится. В более поздних версиях инлайнится всё.


Внутри 4.0-4.6 происходит замена компилятора. Так что какую бы целевую не выбрать, всё равно будет использоваться один и тот же jit.

Я тут разобрался с вопросом. У меня стояла самая последняя версия .net, которая присутствует у обычных пользователей — 4.5.2 (4.6 не ставится автоапдейтами). И она выдаёт именно тот результат, что я показывал в сообщениях раньше. Сейчас я ради развлечения поставил себе .net 4.6 (скачав руками с сайта MS) и получил результат в 42 мс. Это всё объясняет и делает все цифры похожими на правду. Похоже что RyuJIT действительно работает и ускоряет более чем вдвое (на данном примере). Хотя и всё равно немного уступает нормальному компилятору C++ (там 37 мс).

P.S. Вот теперь думаю, удалить ли 4.6 с компьютера (а то ведь все тесты тогда будут соответствовать не тому, что будет на компьютерах у конечных пользователей) или оставить ради 1,5 сомнительных .net программок, установленных на компьютере.
Re[12]: Java vs C# vs C++
От: alex_public  
Дата: 29.09.15 22:26
Оценка: +1
Скомпилировал тот свой старый тест (с клеточным автоматом) с помощью .net 4.6. Так вот нормальная версия C# стала заметно медленнее (9+ секунд, вместо 8)! А unsafe версия стала заметно быстрее (4 секунды вместо 4,6). Очень забавно и непредсказуемо. Хорошо что обычных пользователей это пока почти не затрагивает (win10 — это всё же ещё экзотика).
Re[11]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 29.09.15 23:01
Оценка: +1
Здравствуйте, alexzz, Вы писали:

EP>>Это же одна из главных фишек C++ — удобно писать быстрый код. Цитата в тему:

EP>>

EP>>"The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier [to write in C++ than in other languages]." – Herb Sutter at //build/, quoting Andrei Alexandrescu

A>Точно подмечено, легко писать быстрый код и трудно весь остальной.

Не трудно, а труднее. Да и основные трудности например от отсутствия модулей, зоопарка целевых платформ, исторически сложившихся шероховатостей языка и в среднем более слабой поддержкой всяких рефакторингов со стороны IDE, а не от отсутствия каких-то фич (их-то как раз много уникальных среди остального mainstream).
Причём местами даже легче — взять то же мета-программирование, оно не только про скорость, но и про удобство (например EDSL). Или та же кроссплатформенность с самым широким охватом.

A>Которого на порядки больше

A>Теоретически должно быть удобно писать основной код на C#/Java и вызывать функции на C++ там, где нужна чистая скорость — что-нибудь типа перемолотить большой объём данных или миллион раз перемножить несколько матриц.

Во многих областях так и делают, например всякие инженерные дела — только там не C#/Java (Java вообще тут не к месту — самый отсталый mainstream язык), а например Python + C++.

A>Но практически [у меня] получается, что удобнее в нескольких ограниченных местах снизить уровень абстракции и запачкать руки низкоуровневым кодом, чем смешивать в проекте несколько языков и таскать за управляемой сборкой пару нативных бинарников для x86/x64. Потому что дополнительная прибавка в скорости не оправдывает лишней мороки.


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

EP>>C++ с ФВП и лямбдой дал результат сравнимый с рукопашным низкоуровневым циклом C# А теперь попробуй сравни аналогичный код на C# с ФВП и лямбдой.

A>С лямбдой C# показывает 81мс. С++ быстрее всего в полтора раза.

Ты какой код с каким сравнивал, и на каких компиляторах? Там по ссылке есть архив с js+html, я его запускал в Firefox.

A>Как обычно.


Это всего лишь небольшой пример. Обычно слоёв абстракций больше. И в C#/Java обычно pointer semantics, в то время как в C++ value semantics — тоже приличный источник для кратной разницы.
Re[11]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 29.09.15 23:56
Оценка:
Здравствуйте, T4r4sB, Вы писали:

EP>>А у меня тот код который быстрый обычно оперирует обобщёнными абстракциями — это более высокий уровень — because I can. И в таком коде я спокойно могу использовать например ФВП и замыкания, а не расписывать вручную каждую комбинацию алгоритма, контейнера и предиката — because I can.

TB>А как написать сортировку, не расписав вручную для каждого контейнера?

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

TB>Хотя я задавался таким вопросом помню, и таки да, такая сортировка существует, но от оптимальной она далека.


С сортировкой много разных моментов связанно. Выбор оптимальной зависит не только от типа контейнера/элемента.
Например тот же связный список можно отсортировать слияниями через жонглирование связями (никак не перемещая сами элементы), а можно сначала переместить данные в массив, отсортировать интроспективной сортировкой, и переместить обратно. Оптимальный выбор зависит от ситуации, к примеру перелинковка может быть крайне нежелательна, так как может сильно нарушить последовательность узлов в памяти. Тем не менее, оба из этих вариантов сортировок могут быть реализованы обобщённо.

TB>Так что обобщённость тоже имеет свой предел.


Естественно имеет. В подобных случаях кстати отлично работает перегрузка/специализация. Каноничный пример std::advance — для RandomAccess он Θ(1), для остальных Θ(n).
Отредактировано 30.09.2015 0:00 Evgeny.Panasyuk . Предыдущая версия .
Re[12]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 30.09.15 07:52
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Абстрагировав интерфейс доступа к элементам последовательности в отдельную концепцию, например в итераторы. Один вариант итератора соответствует множеству контейнеров.


Да, это я понимаю, а дальше что? А дальше тебе придётся учитывать, что на каждом контейнере оптимальная сортировка — своя.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[13]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 30.09.15 08:24
Оценка: +1
Здравствуйте, T4r4sB, Вы писали:

EP>>Абстрагировав интерфейс доступа к элементам последовательности в отдельную концепцию, например в итераторы. Один вариант итератора соответствует множеству контейнеров.

TB>Да, это я понимаю, а дальше что? А дальше тебе придётся учитывать, что на каждом контейнере оптимальная сортировка — своя.

Не на каждом контейнере, а на каждой концепции контейнеров/итераторов. Для std::array и std::vector оптимальная сортировка одинаковая, для safe и unsafe random access итераторов тоже одинаковая. Для разных реализаций односвязного списка — тоже одинаковая.

При этом возможность использовать самую общую сортировку для разных типов контейнеров, не теряя в скорости по сравнению с ручным расписыванием этой же сортировки для каждого контейнера — вполне себе фича.
Re[7]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 30.09.15 08:34
Оценка:
Здравствуйте, vdimas, Вы писали:

DR>>>Встречал в сортировке по прозрачности, когда предметов в неправильном порядке мало и они идут друг за другом.

N>>Сортировка вставками?
V>Пузырьковая для лучшего случая однопроходная.

Для таких случаев и сортировка вставками однопроходная, плюс для многих других. Её кстати используют в реализациях std::sort на одном из финальных этапов.
Re[12]: Java vs C# vs C++
От: v6  
Дата: 30.09.15 09:25
Оценка:
Здравствуйте, alexzz, Вы писали:

v6>>Ну как "один"? Есть Roslyn, в котором большой упор сделан как раз на оптимизацию кода.

v6>>А тут даже непонятно под какую платформу код компилился, для x86 и x64 IL может быть в некоторых случаях сильно разным.

A>IL же на то и IL, что одинаковый на всех платфоормах. Иначе в нём смысла нет. Разницу в скорости, если она есть, делает JIT.


Ты прав, что-то я не то написал. А вот JIT действительно может давать разницу.
Re[12]: Java vs C# vs C++
От: v6  
Дата: 30.09.15 09:29
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Так там же в коде одни вычисления с double.


Если я правильно помню, JIT-64 использует SSE2, а x86 — нет.
Re[8]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 00:30
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Для таких случаев и сортировка вставками однопроходная, плюс для многих других.


Сортировка вставками и так однопроходная. Но дороже пузырьковой при ситуации, близкой к лучшей.
Re[9]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 00:36
Оценка:
Здравствуйте, vdimas, Вы писали:

EP>>Для таких случаев и сортировка вставками однопроходная, плюс для многих других.

V>Сортировка вставками и так однопроходная.

Точно, подразумевал линейную сложность.

V>Но дороже пузырьковой при ситуации, близкой к лучшей.


Например? Дороже по какому параметру?
Re[9]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 00:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным.


Считается наоборот. Код с дырами в безопасности не может быть оптимальным.
Re[11]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 00:53
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Специально для тебя повторю — замедляющих факторов полно в любом языке. Даже в С++ (одни смартпоинтеры чего стоят).


Сами смарт-поинтеры ничего не стоят. Они не делают никакой лишней работы, которая не была бы сделана "ручками" в их отсутствие.


G>Так вот Java умеет девиртуализировать вызовы


Плюсы всегда девиртуализируют вызовы, когда известен точный тип объекта. Умели это еще до джавы.
Отредактировано 02.10.2015 0:54 vdimas . Предыдущая версия .
Re[12]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.10.15 01:02
Оценка:
Здравствуйте, vdimas, Вы писали:

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


G>>Специально для тебя повторю — замедляющих факторов полно в любом языке. Даже в С++ (одни смартпоинтеры чего стоят).


V>Сами смарт-поинтеры ничего не стоят. Они не делают никакой лишней работы, которая не была бы сделана "ручками" в их отсутствие.

Ты о smart_ptr или о какой-то магии?


G>>Так вот Java умеет девиртуализировать вызовы

V>Плюсы всегда девиртуализируют вызовы, когда известен точный тип объекта. Умели это еще до джавы.
"Всегда" это сколько по времени? Когда я занимался C++ в далеком 2006 не было девиртуализации в Visual Studio. А у джавы уже была насколько я знаю.
Re[10]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.10.15 01:05
Оценка:
Здравствуйте, vdimas, Вы писали:

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


G>>Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным.


V>Считается наоборот. Код с дырами в безопасности не может быть оптимальным.

Не понял о чем ты. Представь типичную программу на C++ до C++11, теперь прикинь сколько и где надо добавить проверок в рантайме, чтобы исключить обращения к освобожденной памяти?
Re[13]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 10:51
Оценка: +1 -1
Здравствуйте, gandjustas, Вы писали:

G>>>Специально для тебя повторю — замедляющих факторов полно в любом языке. Даже в С++ (одни смартпоинтеры чего стоят).

V>>Сами смарт-поинтеры ничего не стоят. Они не делают никакой лишней работы, которая не была бы сделана "ручками" в их отсутствие.
G>Ты о smart_ptr или о какой-то магии?

Я довольно точно выразил свою мысль.
Смарт-поинтеры — это лишь элемент автоматизации имеющейся функциональности, а не привнесения новой.

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

Такая же ситуация с другими смарт-поинтерами со счетчиками владения, типа intrusive_ptr.
Или без счетчиков, типа unique_ptr/auto_ptr.


G>>>Так вот Java умеет девиртуализировать вызовы

V>>Плюсы всегда девиртуализируют вызовы, когда известен точный тип объекта. Умели это еще до джавы.
G>"Всегда" это сколько по времени? Когда я занимался C++ в далеком 2006 не было девиртуализации в Visual Studio.

Ну вот так хорошо ты занимался.
struct A {
    virtual void m() {
        std::cout << "A";
    }
};

struct B : A {
    virtual void m() {
        std::cout << "B";
        A::m();
    }
};

int main(int argc, char* argv[]) 
{
    B b;
    b.m();

    return 0;
}


В дебажной-сборке вызывается без виртуализации по обычному call с прямой адресацией:
    b.m();
00E15F90  lea         ecx,[b]  
00E15F93  call        B::m (0E11159h)


В релизной инлайнится нафик и тело B::m и A::m. Инлайнится строго по той причине, что никакого виртуального вызова не происходит.
Re[11]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 11:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

V>>Считается наоборот. Код с дырами в безопасности не может быть оптимальным.

G>Не понял о чем ты. Представь типичную программу на C++ до C++11, теперь прикинь сколько и где надо добавить проверок в рантайме, чтобы исключить обращения к освобожденной памяти?

А что изменилось после C++11 в этом плане? Это такой же дырявый язык по-умолчанию, как и C#.

Протягивать динамику в статику можно только через зависимые типы. В этом случае некая проверка происходит лишь однажды, при "динамическом преобразовании" неких исходных данных (взятых с IO, скажем) в "типизированную версию", а затем все гарантии распространяются автоматом, не требуя дальнейших проверок в рантайме. Именно отсюда растут ноги эффективности — из ГАРАНТИЙ безопасности.

Но С++ закрывает хотя бы часть амбразуры, если размерности массивов известны в compile-time. Т.е. можно так построить систему типов, чтобы протянуть всю безопасность далее по вызовам, сделав ненужным лишние проверки в каждом публичном методе. Например, хорошо это ложится на обработку данных порциями — мы выбираем размер порции в design-time, а затем в рантайм обрабатываем данные этими порциями, где все динамические проверки происходят аккурат в момент заполнения некоего начального "типизированного" буфера. Ну а далее будет уже как в языках с зависимыми типами — вся обработка будет уже без лишних проверок. К тому же это очень эффективно, т.к. все циклы задаются константными счетчиками, т.е. раскрутка цикла или операция сравнения на выход из цикла происходят в самых благоприятных для компилятора условиях.
Re[10]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 11:14
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Например? Дороже по какому параметру?


По операции поиска места для вставки. Эта операция одинаково сложная для случая, когда надо поменять пару соседних или не соседних элементов.

В общем, каждая сортировка хороша для своего сценария (если этот сценарий достоверно известен, разумеется).
Re[11]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 11:58
Оценка:
Здравствуйте, vdimas, Вы писали:

EP>>Например? Дороже по какому параметру?

V>По операции поиска места для вставки. Эта операция одинаково сложная для случая, когда надо поменять пару соседних или не соседних элементов.

Приведи пример. После swap'а пузырёк будет делать ещё проход.
Re[14]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.10.15 13:35
Оценка: -1
Здравствуйте, vdimas, Вы писали:

V>Я довольно точно выразил свою мысль.

V>Смарт-поинтеры — это лишь элемент автоматизации имеющейся функциональности, а не привнесения новой.
То есть нечто в C++ делает подсчет ссылок без smart_ptr? Что это?

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

COM имеет подсчет ссылок независимо от C++.

V>Такая же ситуация с другими смарт-поинтерами со счетчиками владения, типа intrusive_ptr.

V>Или без счетчиков, типа unique_ptr/auto_ptr.
Ты дурачка включил чтоли? Без умных указателей везде будут передаваться T*. А если мы все T* заменим на smart_ptr<T>, то подсчет ссылок сожрет производительность. Зато гарантированно не будет обращения к освобожденной памяти.


G>>>>Так вот Java умеет девиртуализировать вызовы

V>>>Плюсы всегда девиртуализируют вызовы, когда известен точный тип объекта. Умели это еще до джавы.
G>>"Всегда" это сколько по времени? Когда я занимался C++ в далеком 2006 не было девиртуализации в Visual Studio.

V>Ну вот так хорошо ты занимался.

V>
V>struct A {
V>    virtual void m() {
V>        std::cout << "A";
V>    }
V>};

V>struct B : A {
V>    virtual void m() {
V>        std::cout << "B";
V>        A::m();
V>    }
V>};

V>int main(int argc, char* argv[]) 
V>{
V>    B b;
V>    b.m();

V>    return 0;
V>}
V>

Эээ, а где здесь виртуальный вызов вообще? В таком коде VMT не задействуется в принципе.

Девиртуализация вызовов это когда из кода:
struct A {
    virtual void m() {
        std::cout << "A";
    }
};

struct B : A {
    virtual void m() {
        std::cout << "B";
        A::m();
    }
};

void f(A* a)
{
    a->m();
}

int main(int argc, char* argv[]) 
{
   auto b = new B();
   f(b);
}

Компилируется вызов b.m() без использования VMT.
Re[12]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.10.15 13:40
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>>>Считается наоборот. Код с дырами в безопасности не может быть оптимальным.

G>>Не понял о чем ты. Представь типичную программу на C++ до C++11, теперь прикинь сколько и где надо добавить проверок в рантайме, чтобы исключить обращения к освобожденной памяти?

V>А что изменилось после C++11 в этом плане?

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

V>Протягивать динамику в статику можно только через зависимые типы. В этом случае некая проверка происходит лишь однажды, при "динамическом преобразовании" неких исходных данных (взятых с IO, скажем) в "типизированную версию", а затем все гарантии распространяются автоматом, не требуя дальнейших проверок в рантайме. Именно отсюда растут ноги эффективности — из ГАРАНТИЙ безопасности.

Это тебя в сторону унесло. Не нужны произвольные гарантии, их компилятор не обеспечит. Нужны базовые гарантии безопасности — отсутствие обращений к освобожденным объектам, отсутствие обращений к неинициализированной памяти, запрет реинтерпретации памяти. C++ с голыми указателями этого не дает. А совсем без голых указателей — привет тормоза и счетчиками ссылок.
Re[15]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 13:54
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

V>>Я довольно точно выразил свою мысль.

V>>Смарт-поинтеры — это лишь элемент автоматизации имеющейся функциональности, а не привнесения новой.
G>То есть нечто в C++ делает подсчет ссылок без smart_ptr? Что это?

Не в C++, а непосредственно в прикладной области возникают задачи, в которых точка удаления зависит от внешних параметров, неизвестных заранее.

V>>Такая же ситуация с другими смарт-поинтерами со счетчиками владения, типа intrusive_ptr.

V>>Или без счетчиков, типа unique_ptr/auto_ptr.
G>Ты дурачка включил чтоли?

Не хами.

G>Без умных указателей везде будут передаваться T*.


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

Пример: есть две параллельные (не пересекающиеся) асинхронные цепочки, у которых есть общие разделяемые ресурсы (отсюда и shared), которые должны быть освобождены после завершения обеих цепочек. Какая цепочка закончится первой — заранее неизвестно. Решить эту задачу можно например подсчётом ссылок, причём неважно — ручным или автоматическим. Но простого проставления освобождения ресурса в фиксированном месте здесь недостаточно.

G>А если мы все T* заменим на smart_ptr<T>, то подсчет ссылок сожрет производительность.


smart_ptr бывают разные, не обязательно с подсчётом ссылок. Подсчёт ссылок по факту нужен редко.
Re[13]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 14:28
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

V>>>>Считается наоборот. Код с дырами в безопасности не может быть оптимальным.

G>>>Не понял о чем ты. Представь типичную программу на C++ до C++11, теперь прикинь сколько и где надо добавить проверок в рантайме, чтобы исключить обращения к освобожденной памяти?
V>>А что изменилось после C++11 в этом плане?
G>После C++ умные указатели вошли в стандарт

Там где требовалось их и так использовали. Стандартизировали лишь существующую практику, и то отчасти.
Самое существенное изменение C++11 относительно умных указателей это move семантика. Она конечно эмулировалась и в предыдущей версии стандарта, но с ограничениями.

G>и стали основным способом работы.


Основным способом работы с чем?

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


Что значит "по старинке"? По какой именно старинке?
И кстати голые не владеющие указатели прекрасно уживаются с умными.

G>Это тебя в сторону унесло. Не нужны произвольные гарантии, их компилятор не обеспечит. Нужны базовые гарантии безопасности — отсутствие обращений к освобожденным объектам, отсутствие обращений к неинициализированной памяти, запрет реинтерпретации памяти. C++ с голыми указателями этого не дает. А совсем без голых указателей — привет тормоза и счетчиками ссылок.


Это типичное заблуждение Java/C# программиста, мол там где у него new и владеющие указатели, то в C++ обязательно будет какой-нибудь умный/обычный указатель. Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984
По факту же в большинстве кода не нужны никакие владеющие указатели.
Re[14]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 14:48
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>Это типичное заблуждение Java/C# программиста, мол там где у него new и владеющие указатели, то в C++ обязательно будет какой-нибудь умный/обычный указатель. Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984

EP>По факту же в большинстве кода не нужны никакие владеющие указатели.
Так в итоге C#, Java, JS в топку? Все на С++?
и солнце б утром не вставало, когда бы не было меня
Re[15]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 14:53
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Это типичное заблуждение Java/C# программиста, мол там где у него new и владеющие указатели, то в C++ обязательно будет какой-нибудь умный/обычный указатель. Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984

EP>>По факту же в большинстве кода не нужны никакие владеющие указатели.
S> Так в итоге C#, Java, JS в топку? Все на С++?

Не, не в топку. Я сам частенько использую Python. И по секрету скажу, недавно даже на C# написал несколько сотен строк — правда это был пример использования C++ библиотеки, но тем не менее.
А вообще непонятно как ты сделал вывод про "в топку"
Отредактировано 02.10.2015 14:54 Evgeny.Panasyuk . Предыдущая версия .
Re[15]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 16:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>То есть нечто в C++ делает подсчет ссылок без smart_ptr? Что это?


Это методы, навроде addRef/release.

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

G>COM имеет подсчет ссылок независимо от C++.

COM-технология зиждется на таблице виртуальных ф-ий, генерённых компилятором С++.
Никакой "независимости" тут нет.

G>Ты дурачка включил чтоли?


началось...

G>Без умных указателей везде будут передаваться T*.


У меня и с умными указателями везде передаётся T*, и?


G>А если мы все T* заменим на smart_ptr<T>, то подсчет ссылок сожрет производительность.


Если у тебя везде передавался smart_ptr<T> в бытность твою плюсовиком, то прими мои поздравления с... да много с чем... ))

Скажи, зачем вот сюда подавать smart_ptr<T>:
void process(T * data) {
  process1(data);
  process2(data);
  process3(data);
  process4(data);
  process5(data);
}


Для какой надобности?

G>Зато гарантированно не будет обращения к освобожденной памяти.


G>Девиртуализация вызовов это когда из кода:


G>
...
G>void f(A* a)
G>{
    a->>m();
G>}
...
G>


G>Компилируется вызов b.m() без использования VMT.


Для девиртуализации необходимо изменение тела ф-ии под конкретный подаваемый тип. Это происходит при инлайнинге, например.

Никаких проблем:
int main(int argc, _TCHAR* argv[]) 
{
    B b;
    f(&b);
    return 0;
}


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

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

Причем, для С++ это работает и в случае вложенных друг в друга объектах:
struct C {
    B b;
};

int main(int argc, _TCHAR* argv[]) 
{
    C c;
    f(&c.b);

    return 0;
}


А в случае Джавы — уже дудки.
Отредактировано 02.10.2015 16:53 vdimas . Предыдущая версия .
Re[13]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 16:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

V>>А что изменилось после C++11 в этом плане?

G>После C++ умные указатели вошли в стандарт и стали основным способом работы.

А по-факту — ничего не изменилось в реальных проектах, бо в стандарт вошли смарт-поинтеры из буста.
Смарт-поинтеры активно применяют примерно с середины 90-х.


G>Это, кстати, позволяет намного сократить количество ошибок, но путем повышения тормозов.


Я уже указывал на эту ошибку в этих рассуждениях. Ты фундаментально не прав. Смарт-поинтеры НЕ вносят тормозов, потому что не вносят никакой функциональности.


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


Дело не в старинке. Дело в том, что надо понимать, что ты делаешь.
А ты не понимаешь, очевидно.

Сосредоточься, плиз: смарт-поинтер нужен ровно там, где мы изменяем текущего владельца или расшариваем владение. Причем, при изменении текущего владельца через swap даже счетчики ссылок не дергаются.

А во всей остальной обработке никакие смарт-поинтеры не нужны:
http://rsdn.ru/forum/philosophy/6201064.1
Автор: vdimas
Дата: 02.10.15



V>>Протягивать динамику в статику можно только через зависимые типы. В этом случае некая проверка происходит лишь однажды, при "динамическом преобразовании" неких исходных данных (взятых с IO, скажем) в "типизированную версию", а затем все гарантии распространяются автоматом, не требуя дальнейших проверок в рантайме. Именно отсюда растут ноги эффективности — из ГАРАНТИЙ безопасности.

G>Это тебя в сторону унесло.

Да нет, не в сторону. Речь-то пошла о гарантиях, даваемых языком / системой типов.


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


Ну я-то готов обсуждать вполне конкретные гарантии, например, гарантии не выхода за пределы массива или гарантии необращения к удалённому объекту. И утверждаю, что в этом плане голый С++ стоит на уровне голого C#, бо оба языка НЕ обеспечивают таких гарантий.

G>Нужны базовые гарантии безопасности — отсутствие обращений к освобожденным объектам, отсутствие обращений к неинициализированной памяти,



G>запрет реинтерпретации памяти.


Для полного запрета реинтерпретации памяти необходимо отменить весь интероп, к примеру. А как вызывать ф-ии операционки?


G>C++ с голыми указателями этого не дает. А совсем без голых указателей — привет тормоза и счетчиками ссылок.


Похоже, ты опять не понимаешь, о чем говоришь. ))

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

Некий участок, где возможен вылет за границы массива может быть не обнаружен никакими тестами в C#, потому что, например, может находиться в самом редком из комбинаций входных данных... Но у самого важного клиента оно обязательно вылетит, причем, в момент совершения важной сделки на 1 мегабакс. )) Программа всё-равно не сможет обработать транзакцию, как ты её не пинай, будет выдавать ошибку.

В общем, вылеты в рантайм — это ср-ва диагностики, ОК, сильно помогает искать ошибки. Эти ср-ва тебе так же доступны в С++. Но вне разработки —
это будет всё так же неработающая программа, которую "пропустил" тупой компилятор.

Я же рассуждал о возможности, скажем, исключить проверку на границы диапазонов в рантайм (все-равно это не защищает от ошибок), а сделать так, чтобы эту проверку производил компилятор С++ в compile-time. В этом случае, если обращение к такому массиву скомпилировалось, то выхода за границы заведомо не будет. В C# такой трюк недостижим.
Re[16]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 16:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Когда твоя джава получит указатель на объект "откуда-то еще", никакой девиртуализации при вызове не происходит, оно происходит аккурат в аналогичном приведенному сценарии.


Справедливости ради, в некоторых из таких случаев девиртуализацию может сделать JIT (который может быть в том числе и у программ C++; другое дело что на C++ обычно таких вызовов меньше).

Кстати, тут недавно был синтетический бенчмарк, в котором как раз был сделан сильный упор на JIT/девиртуализацию и GC, буквально задача на которой они раскрываются во всей красе — так даже и его получилось забороть
Автор: Evgeny.Panasyuk
Дата: 29.06.15
подсчётом ссылок и изначально меньшей виртуальностью (примерно то о чём ты говорил).
Re[14]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 16:52
Оценка: +1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Это типичное заблуждение Java/C# программиста, мол там где у него new и владеющие указатели, то в C++ обязательно будет какой-нибудь умный/обычный указатель. Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984

EP>По факту же в большинстве кода не нужны никакие владеющие указатели.

Та да. Я как-то давал уже статистику, что в довольно большом проекте из более 250 прикладных типов, встречалось всего 17 (!!!) операций new.

В С++ типы чаще всего агрегируются по значению, если посмотреть на иерархию владения. По new обычно выделяются объекты из самого верха иерархии и то, далеко не всегда. ))
Re[13]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 02.10.15 16:58
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

V>>А что изменилось после C++11 в этом плане?

G>После C++ умные указатели вошли в стандарт и стали основным способом работы. Это, кстати, позволяет намного сократить количество ошибок, но путем повышения тормозов. Если писать по старинке, через голые указатели, то очень много ошибок обращений к освобожденной памяти возникает, и довольно часто возникают утечки.

Расскажите мне про тормоза умных указателей. Я не понимаю.
Может быть потому, что я не фигачу шареды направо и налево, потому что обычно я знаю, кто у ресурса хозяин, и мне хватает уника, у которого тормозить вообще нечему.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[17]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 16:59
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

V>>Когда твоя джава получит указатель на объект "откуда-то еще", никакой девиртуализации при вызове не происходит, оно происходит аккурат в аналогичном приведенному сценарии.


EP>Справедливости ради, в некоторых из таких случаев девиртуализацию может сделать JIT


Справделивости ради — нет. ))
Если JIT "не видел", откуда получен объект, то никакой девиртуализации не будет. А если видел — то это он всего-лишь проинлайнил тот самый вызов, в котором встретилось new для целевого объекта. Дык, возможности инлайна в С++ на порядки больше.


EP>Кстати, тут недавно был синтетический бенчмарк, в котором как раз был сделан сильный упор на JIT/девиртуализацию и GC, буквально задача на которой они раскрываются во всей красе — так даже и его получилось забороть
Автор: Evgeny.Panasyuk
Дата: 29.06.15
подсчётом ссылок и изначально меньшей виртуальностью (примерно то о чём ты говорил).


Синтетические бечмарки фтопку. Реально. Потому что они заставляют на С++ писать АНАЛОГИЧНЫЙ управляемому код исключительно с целью бенчмарка. ))

А в реальной жизни на С++ пишут нифига не аналогичный код, бо система типов такова, что там, где на Джаве или дотнете всё разруливается через интерфейсы и виртуальные вызовы (и только через них, родимых), на С++ всё разруливается на шаблонах еще на этапе компиляции.
Re[16]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 17:11
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Это типичное заблуждение Java/C# программиста, мол там где у него new и владеющие указатели, то в C++ обязательно будет какой-нибудь умный/обычный указатель. Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984

EP>>>По факту же в большинстве кода не нужны никакие владеющие указатели.
S>> Так в итоге C#, Java, JS в топку? Все на С++?

EP>Не, не в топку. Я сам частенько использую Python. И по секрету скажу, недавно даже на C# написал несколько сотен строк — правда это был пример использования C++ библиотеки, но тем не менее.

EP>А вообще непонятно как ты сделал вывод про "в топку"
Да в том, что считать нужно не тики, а удобство языков для решения определенных задач. Я уже приводил, ссылку что самые востребованные программисты это 1С овцы. А никто в здравом уме не станет сравнивать по скорости С++ и 1С. Порядок и так известен. На самом деле большую часть нагрузки это SQL базы, и доля вычислений на 1С не такая большая. Для вэб,HTTP сервисов сайтов во главе угла удобство использования библиотек и распараллеливания кода. Await ооочень удобен.
Все больше построение DOM выносится на клиента, где уже востребованы TS, AngularJS, JQuery итд.
Я к тому, что для каждого языка свои задачи. А порядок скоростей давно известен. И многие задачи решаются за счет оптимального подбора алгоритмов.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Java vs C# vs C++
От: alexzz  
Дата: 02.10.15 17:13
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Синтетические бечмарки фтопку. Реально. Потому что они заставляют на С++ писать АНАЛОГИЧНЫЙ управляемому код исключительно с целью бенчмарка. ))


И наоборот тоже.

V>А в реальной жизни на С++ пишут нифига не аналогичный код, бо система типов такова, что там, где на Джаве или дотнете всё разруливается через интерфейсы и виртуальные вызовы (и только через них, родимых), на С++ всё разруливается на шаблонах еще на этапе компиляции.


Во! Именно по этой причине я нахожу практически бессмысленным сравнивать скорость работы одинакового кода в разных языках. Разве что из любопытства. Сравнивать имеет смысл время решения одинаковой задачи, независимо от того, какими средствами она была решена.
Re[18]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 17:40
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Когда твоя джава получит указатель на объект "откуда-то еще", никакой девиртуализации при вызове не происходит, оно происходит аккурат в аналогичном приведенному сценарии.

EP>>Справедливости ради, в некоторых из таких случаев девиртуализацию может сделать JIT
V>Справделивости ради — нет. ))
V>Если JIT "не видел", откуда получен объект, то никакой девиртуализации не будет. А если видел — то это он всего-лишь проинлайнил тот самый вызов, в котором встретилось new для целевого объекта. Дык, возможности инлайна в С++ на порядки больше.

Трассирующий JIT может заинлайнить виртуальные вызовы внутри цикла. Грубо говоря вынести проверку наружу цикла.

EP>>Кстати, тут недавно был синтетический бенчмарк, в котором как раз был сделан сильный упор на JIT/девиртуализацию и GC, буквально задача на которой они раскрываются во всей красе — так даже и его получилось забороть
Автор: Evgeny.Panasyuk
Дата: 29.06.15
подсчётом ссылок и изначально меньшей виртуальностью (примерно то о чём ты говорил).

V>Синтетические бечмарки фтопку. Реально. Потому что они заставляют на С++ писать АНАЛОГИЧНЫЙ управляемому код исключительно с целью бенчмарка. ))
V>А в реальной жизни на С++ пишут нифига не аналогичный код, бо система типов такова, что там, где на Джаве или дотнете всё разруливается через интерфейсы и виртуальные вызовы (и только через них, родимых), на С++ всё разруливается на шаблонах еще на этапе компиляции.

Так там по ссылке разный код, но решающий одну задачу. Абсолютно всё разрулить на этапе компиляции не получится, так как есть runtime условия. Частично — да, возможно, отчасти поэтому там и получилось обогнать JIT.
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 17:54
Оценка:
Здравствуйте, alexzz, Вы писали:

V>>А в реальной жизни на С++ пишут нифига не аналогичный код, бо система типов такова, что там, где на Джаве или дотнете всё разруливается через интерфейсы и виртуальные вызовы (и только через них, родимых), на С++ всё разруливается на шаблонах еще на этапе компиляции.

A>Во! Именно по этой причине я нахожу практически бессмысленным сравнивать скорость работы одинакового кода в разных языках. Разве что из любопытства.

Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест

A>Сравнивать имеет смысл время решения одинаковой задачи, независимо от того, какими средствами она была решена.


Ха, как раз в этой теме
Автор: Sinclair
Дата: 03.06.15
на Java потратили намного больше времени, потому что пришлось писать низкоуровневую лапшу (из-за того что высокоуровневый код там бы многократно тормозил), причём в самом характерном низкоуровневом месте которой выполз баг (у высокоуровневого C++ кода нет места для такой ошибки)
Re[20]: Java vs C# vs C++
От: alexzz  
Дата: 02.10.15 18:33
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

A>>Во! Именно по этой причине я нахожу практически бессмысленным сравнивать скорость работы одинакового кода в разных языках. Разве что из любопытства.

EP>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест

Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее. Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.

A>>Сравнивать имеет смысл время решения одинаковой задачи, независимо от того, какими средствами она была решена.


EP>Ха, как раз в этой теме
Автор: Sinclair
Дата: 03.06.15
на Java потратили намного больше времени, потому что пришлось писать низкоуровневую лапшу (из-за того что высокоуровневый код там бы многократно тормозил), причём в самом характерном низкоуровневом месте которой выполз баг (у высокоуровневого C++ кода нет места для такой ошибки)


Пардон, я двусмысленно написал. Под «временем решения» я имел ввиду время, за которое написанная программа решает поставленную задачу.

На счёт ошибок – был бы программист, а место для ошибок всегда найдётся.
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 19:03
Оценка:
Здравствуйте, alexzz, Вы писали:

A>>>Во! Именно по этой причине я нахожу практически бессмысленным сравнивать скорость работы одинакового кода в разных языках. Разве что из любопытства.

EP>>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест
A>Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее.

Так я и не говорю что нужно сразу бежать на другой язык. Где-то да, вполне уместно остаться в рамках одного языка, пусть и напедалив error-prone boilerplate низкоуровневого кода

A>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.


В каком смысле?

A>Пардон, я двусмысленно написал. Под «временем решения» я имел ввиду время, за которое написанная программа решает поставленную задачу.


Так я же говорю, что если брать теоретически-сферический потолок по скорости который можно достигнуть, то Java/C# от C++ будут отставать не сильно, я даже не настаиваю на ударах ниже пояса типа автовекторизации.
Но это при том что на Java/C# придётся писать error-prone boilerplate low-level код, отказываясь от удобств и абстракций.

A>На счёт ошибок – был бы программист, а место для ошибок всегда найдётся.


Это понятно, если бы ошибка была в каком-то другом месте, я бы даже не обратил внимания — все ошибаются. Но в этом случае она как раз в том месте, которое появилось из-за спускания на низкий уровень.
На высоком уровне там две отдельных простых операции: std::transform и перемножение двух отдельных комплексных чисел:
Complex operator*(Complex x, Complex y)
{
    return {x.re*y.re - x.im*y.im, x.re*y.im + x.im*y.re};
}
// ...
transform(v, u, v.begin(), [](auto x, auto y) { return x*y; });


Перейдя на низкий уровень ему пришлось делать одну толстую рукопашную операцию: перемножение комплексных чисел в двух массивах. И в результате он допустил ошибку как раз в месте склейки этих двух операций:
for ( int i = 0; i < u_ar.length / 2; ++i ) {
    v.re(i, u.re(i) * v.re(i) - u.im(i) * v.im(i) );
    v.im(i, u.re(i)*v.im(i) + u.im(i)*v.re(i));
}
Re[17]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 19:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Не, не в топку. Я сам частенько использую Python. И по секрету скажу, недавно даже на C# написал несколько сотен строк — правда это был пример использования C++ библиотеки, но тем не менее.

EP>>А вообще непонятно как ты сделал вывод про "в топку"
S> Да в том, что считать нужно не тики, а удобство языков для решения определенных задач.

Так я же и говорю, одно из основных/главных преимуществ C++ в том, что быстрый код на нём получается удобнее чем на других языках

S>Я уже приводил, ссылку что самые востребованные программисты это 1С овцы.


Водители ещё более востребованы, и что из этого?

S>А никто в здравом уме не станет сравнивать по скорости С++ и 1С. Порядок и так известен. На самом деле большую часть нагрузки это SQL базы, и доля вычислений на 1С не такая большая. Для вэб,HTTP сервисов сайтов во главе угла удобство использования библиотек и распараллеливания кода. Await ооочень удобен.


await есть и в C++

S>Все больше построение DOM выносится на клиента, где уже востребованы TS, AngularJS, JQuery итд.


А ещё туда внезапно проникает C++

S> Я к тому, что для каждого языка свои задачи.


А я разве говорил обратное?

S>А порядок скоростей давно известен.


Видимо не всем — иначе не было бы этого топика

S>И многие задачи решаются за счет оптимального подбора алгоритмов.


Я не предлагаю сравнивать решения с разными алгоритмами.
Re[22]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 19:21
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>
EP>Complex operator*(Complex x, Complex y)
EP>{
EP>    return {x.re*y.re - x.im*y.im, x.re*y.im + x.im*y.re};
EP>}
EP>// ...
EP>transform(v, u, v.begin(), [](auto x, auto y) { return x*y; });
EP>


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

EP>
EP>for ( int i = 0; i < u_ar.length / 2; ++i ) {
EP>    v.re(i, u.re(i) * v.re(i) - u.im(i) * v.im(i) );
EP>    v.im(i, u.re(i)*v.im(i) + u.im(i)*v.re(i));
EP>}
EP>


На C# https://msdn.microsoft.com/en-us/library/system.numerics.complex.op_multiply(v=vs.110).aspx
Complex c1 = Complex.One;
Complex c2 = new Complex(1.4, 2.3);
Complex c3 = c1 * c2;
и солнце б утром не вставало, когда бы не было меня
Re[12]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 19:35
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Например? Дороже по какому параметру?

V>>По операции поиска места для вставки. Эта операция одинаково сложная для случая, когда надо поменять пару соседних или не соседних элементов.

EP>Приведи пример.


1 2 3 4 6 5 7 8 9

Сортировка вставкой обнаружит 5 после 6 и начнёт искать для 5 место перед 6. Сам поиск может быть как линейный (с самого начала), так и двоичный, золотого сечения и т.д.


EP>После swap'а пузырёк будет делать ещё проход.


Не будет. Простой пузырёк протягивает флаг наличия несортированных элементов, а модифицированный вместо этого протягивает границы несортированной области (индекс начала и индекс конца) и работает в оба направления туда-сюда, сужая к центру (обычно) несортированную область.
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 19:42
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S> На C# https://msdn.microsoft.com/en-us/library/system.numerics.complex.op_multiply(v=vs.110).aspx

S>
S>Complex c1 = Complex.One;
S>Complex c2 = new Complex(1.4, 2.3);
S>Complex c3 = c1 * c2;
S>


Где перемножение массивов?

А вообще речь-то совсем не об этом. Так-то C++:
#include <iostream>
#include <valarray>
#include <complex>

using namespace std;
using namespace literals;

int main()
{
    constexpr auto n = 5;
    valarray<complex<double>> x(2.5 + 10i, n), y(1.2 - 20i, n);
    x *= y;
    for(auto c : x)
        cout << c << endl;
}
Re[13]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 02.10.15 19:42
Оценка: +1
Здравствуйте, vdimas, Вы писали:

EP>>После swap'а пузырёк будет делать ещё проход.


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


Ах эта сверхманевренность. Так тупо съехать с пузырька на шейкер — верх мастерства.
Re[18]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 19:53
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


S>> Да в том, что считать нужно не тики, а удобство языков для решения определенных задач.


EP>Так я же и говорю, одно из основных/главных преимуществ C++ в том, что быстрый код на нём получается удобнее чем на других языках

А вот это как раз и нужно сравнивать. Например типичные задачи Asp.Net на C# и C++

S>>Я уже приводил, ссылку что самые востребованные программисты это 1С овцы.


EP>Водители ещё более востребованы, и что из этого?

А разве водители это программисты?

S>>А никто в здравом уме не станет сравнивать по скорости С++ и 1С. Порядок и так известен. На самом деле большую часть нагрузки это SQL базы, и доля вычислений на 1С не такая большая. Для вэб,HTTP сервисов сайтов во главе угла удобство использования библиотек и распараллеливания кода. Await ооочень удобен.


EP>await есть и в C++

Очень рад за вас.

S>>Все больше построение DOM выносится на клиента, где уже востребованы TS, AngularJS, JQuery итд.


EP>А ещё туда внезапно проникает C++

И каково соотношение?

S>> Я к тому, что для каждого языка свои задачи.


EP>А я разве говорил обратное?


S>>А порядок скоростей давно известен.


EP>Видимо не всем — иначе не было бы этого топика

Это было известно лет 10 назад после выхода Net 2.0 с дженериками.

S>>И многие задачи решаются за счет оптимального подбора алгоритмов.


EP>Я не предлагаю сравнивать решения с разными алгоритмами.

Так давай сравнивать реальную предметную область, а не сортировки
и солнце б утром не вставало, когда бы не было меня
Re[24]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 19:59
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>> На C# https://msdn.microsoft.com/en-us/library/system.numerics.complex.op_multiply(v=vs.110).aspx

S>>
S>>Complex c1 = Complex.One;
S>>Complex c2 = new Complex(1.4, 2.3);
S>>Complex c3 = c1 * c2;
S>>


EP>Где перемножение массивов?

https://msdn.microsoft.com/en-us/library/system.numerics.complex.multiply(v=vs.110).aspx
Не это? https://msdn.microsoft.com/en-us/library/dn877695(v=vs.110).aspx
и солнце б утром не вставало, когда бы не было меня
Re[13]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 20:01
Оценка:
Здравствуйте, vdimas, Вы писали:

EP>>>>Например? Дороже по какому параметру?

V>>>По операции поиска места для вставки. Эта операция одинаково сложная для случая, когда надо поменять пару соседних или не соседних элементов.
EP>>Приведи пример.
V>1 2 3 4 6 5 7 8 9
V>Сортировка вставкой обнаружит 5 после 6 и начнёт искать для 5 место перед 6. Сам поиск может быть как линейный (с самого начала),

Линейный поиск обычно идёт с конца, а не сначала. То есть 5 сравнится напрямую только с 6 и 4.

EP>>После swap'а пузырёк будет делать ещё проход.

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

Даже с этими модификациями получается больше сравнений — дойдёт до 6, сделает swap, дойдёт до конца, а потом ещё сделает проход от 5 до 1.
Re[8]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.10.15 20:02
Оценка:
Здравствуйте, PM, Вы писали:

PM>В заголовок новости не поместилась информация о том, что они:

PM> PM>У меня есть сомнения, что первые 2 пункта легко реализуемы в управляемых средах (не знаю, добавили ли уже в Java value types)

То есть, язык ни при чём. Чтд.
Re[25]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 20:15
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

EP>>Где перемножение массивов?

S>https://msdn.microsoft.com/en-us/library/system.numerics.complex.multiply(v=vs.110).aspx

foreach из примера что-ли? До вот этой красоты всё равно не дотягивает:
valarray<complex<double>> x(2.5 + 10i, n), y(1.2 - 20i, n);
x *= y;


А вообще там задача была именно сделать свой complex и перемножить массивы (это просто конкретный пример), а не заиспользовать что-то полностью готовое

S>Не это? https://msdn.microsoft.com/en-us/library/dn877695(v=vs.110).aspx


При чём тут это "Transforms a two-dimensional vector by a specified 4x4 matrix."
Re[22]: Java vs C# vs C++
От: alexzz  
Дата: 02.10.15 20:34
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Смысл есть. Например выше сравнили скорость работы высокоуровневого кода — вполне полезный тест

A>>Я не вижу практического смысла. Пишу, допустим, я программу на языке А. Вижу, что в одном месте тормозит. Беру и оптимизирую в рамках, допускаемых языком А. На язык Б я начну смотреть, только когда предел оптимизации достигнут, а всё равно тормозит, и точно понятно, что можно сделать быстрее.
EP>Так я и не говорю что нужно сразу бежать на другой язык. Где-то да, вполне уместно остаться в рамках одного языка, пусть и напедалив error-prone boilerplate низкоуровневого кода

A>>Но к этому времени никакого высокоуровнего кода уже не останется ― нечего сравнивать.

EP>В каком смысле?

Смотри, допустим, есть метод на C#, который принимает ICollection<T>, как-то сложно её анализирует и даёт на выходе IDictionary<TKey, TValue>. И при этом тормозит. Допустим, кто-нибудь пишет аналог этого метода на C++ и указывает, что он работает в сто раз быстрее. Что это знание даёт практически?

Я ведь не смогу из C# передать в C++ ICollection<T> и получить IDictionary<TKey, TValue>.
— либо код на C++ должен будет понимать детали реализации типов в .Net, и получится уже не высокоуровневый код;
— либо передавать и возвращать придётся не абстрактные коллекции абстрактных типов, а какие-нибудь банальные массивы с числами или указатели на блоки памяти с числами, и снова получится не высокоуровневый код.

Логичный вариант ― не смотреть на другие языки, а сначала убрать лишние абстракции и чё-нибудь оптимизировать в коде на исходном языке. Стало достаточно быстро ― замечательно. Не стало ― смотрим в сторону С++, пробуем написать на нём аналог и сравниваем скорость. При этом сравниваем, естественно, с оптимизированной низкоуровневой версией. Ведь обогнать теперь нужно именно её.
Отредактировано 02.10.2015 20:35 alexzzzz . Предыдущая версия .
Re[26]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 20:43
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:


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
и солнце б утром не вставало, когда бы не было меня
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 20:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Я уже приводил, ссылку что самые востребованные программисты это 1С овцы.

EP>>Водители ещё более востребованы, и что из этого?
S> А разве водители это программисты?

А причём востребованность?

S>>> Я к тому, что для каждого языка свои задачи.

EP>>А я разве говорил обратное?
S>>>А порядок скоростей давно известен.
EP>>Видимо не всем — иначе не было бы этого топика
S> Это было известно лет 10 назад после выхода Net 2.0 с дженериками.

Тему не я поднял.

S>>>И многие задачи решаются за счет оптимального подбора алгоритмов.

EP>>Я не предлагаю сравнивать решения с разными алгоритмами.
S> Так давай сравнивать реальную предметную область, а не сортировки

Сравнивать чтобы выяснить что?
Тема про производительность, обсуждение внезапно тоже.
Ты же зачем-то начинаешь переходить на сравнение востребованности языков, какие-то конкретные области типа ASP.NET, причём до конца не говоришь что конкретно хочешь этим выяснить.
Re[14]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 20:56
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

K>Ах эта сверхманевренность. Так тупо съехать с пузырька на шейкер — верх мастерства.


Для описанного случая пофиг. Я напоминаю коллеге принципы работы пузырьковой сортировки.
К тому же, шейкерная сортировка официально является разновидностью пузырьковой.
Re[14]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 20:57
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Линейный поиск обычно идёт с конца, а не сначала.


Обычно он идёт двоичный.


EP>Даже с этими модификациями получается больше сравнений — дойдёт до 6, сделает swap, дойдёт до конца, а потом ещё сделает проход от 5 до 1.


И с этими и без этих модификацией НЕ будет лишнего прохода.
Напиши реализацию этого алгоритма и убедись.
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 21:08
Оценка:
Здравствуйте, 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'а.
Re[20]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 21:11
Оценка:
Здравствуйте, 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, причём до конца не говоришь что конкретно хочешь этим выяснить.

Еще раз повторю, что порядок скоростей был известен лет 10 назад. Я делал тесты на C#,Delphi http://rsdn.ru/forum/philosophy/555869.flat
Автор: VladD2
Дата: 02.03.04
. Просил сделать на С++ но народ не стал делать. Тогда уже порядок был известен и за счет чего.
Смысл даже был в том, что было предубеждение по поводу байт кода итд. Проигрыш в 2 раза был вполне удовлетворителен. Мало, того была куча библиотек где можно было на своих алгоритмах увеличивать скорость раза в 4 http://rsdn.ru/article/alg/tlsd.xml#EZD
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.
внизу сравнения.
Так большинство будет использовать стандартную библиотеку, чем более быструю, но неизвестно от кого.

Еще раз экономическая целесообразность (стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности. Вот, что нужно считать.
и солнце б утром не вставало, когда бы не было меня
Re[15]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 21:17
Оценка:
Здравствуйте, vdimas, Вы писали:

EP>>Линейный поиск обычно идёт с конца, а не сначала.

V>Обычно он идёт двоичный.

Обычно он линейный. Сортировка вставками чаще всего применяется для случаев где элементы находятся недалеко от своего места — например на нижних уровнях std::sort — в этих случаях делать обычный двоичный поиск невыгодно.

Или например вот визуализация insertion sort:
http://www.youtube.com/watch?v=8oJS1BMKE64

Вот визуализация реализации std::sort — там сортировка вставками на последнем этапе.
http://www.youtube.com/watch?v=67ta5WTjjUo

EP>>Даже с этими модификациями получается больше сравнений — дойдёт до 6, сделает swap, дойдёт до конца, а потом ещё сделает проход от 5 до 1.

V>И с этими и без этих модификацией НЕ будет лишнего прохода.

Каким образом?

V>Напиши реализацию этого алгоритма и убедись.


В тех реализациях что я представляю — лишний проход есть. Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код.
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 21:46
Оценка:
Здравствуйте, 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
Автор: VladD2
Дата: 02.03.04
. Просил сделать на С++ но народ не стал делать.


Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++.
Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости.

S>Еще раз экономическая целесообразность (стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности. Вот, что нужно считать.


Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше.
Во-вторых, даже если брать твой сценарий — чтобы прикинуть вычислительную мощность на одном устройстве нужно внезапно проводить те же тесты, против которых ты выступаешь
Re[22]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.15 22:06
Оценка:
Здравствуйте, 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
Автор: VladD2
Дата: 02.03.04
. Просил сделать на С++ но народ не стал делать.


EP>Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++.

EP>Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости.
Ну в Net есть дженерики. Да они медленнее примерно в 2 раза за счет отсутствия инлайна. Но все зависит от структур и версии Jit а который совершенствуется.

S>>Еще раз экономическая целесообразность (стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности. Вот, что нужно считать.


EP>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше.

EP>Во-вторых, даже если брать твой сценарий — чтобы прикинуть вычислительную мощность на одном устройстве нужно внезапно проводить те же тесты, против которых ты выступаешь
Я не против тестов, я против синтетических тестов. В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд. Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.
Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.
Нужно учитывать, что очень хороших программистов очень мало. Поэтому нужно брать средних программистов типа меня.
и солнце б утром не вставало, когда бы не было меня
Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 02.10.15 22:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>В заголовок новости не поместилась информация о том, что они:

PM>> PM>>У меня есть сомнения, что первые 2 пункта легко реализуемы в управляемых средах (не знаю, добавили ли уже в Java value types)
I>То есть, язык ни при чём. Чтд.

Если подразумевается язык в смысле синтаксиса, то конечно ни при чём. Если же говорить про платформу (clr vs jvm vs native), то как раз очень даже причём. ))) Собственно в этом почти всё дело и есть.

Ну и ещё не забываем про то, что у главных компиляторов C++ в данным момент мощнейшие в мире оптимизаторы. Что впрочем обычно влияет на быстродействие не более чем в пару раз (если не считать таких нюансов как автовекторизация), а не в 10, как в новости. Так что главное естественно не в этом, а в рантайме платформы, но про этот нюанс тоже стоит помнить.
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 22:48
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>А причём востребованность?

S>>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация,
EP>>Пишут что? В каких случаях? Удобнее для чего?
S> Удобнее для написания сайтов, учетных систем массовых задач.

И? Это единственные существующие задачи?

S>>>а не на тех, что быстрее, но менее удобный.

EP>>Для быстрого кода C++ удобный
S> Еще раз повторю формулу экономической целесообразности
S>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности

ОК, повторил, что ты этим хочешь сказать? (причем это одна из возможных формул, а не единственная)
Да, целесообразность тоже нужно учитывать, с этим не спорю — кроме этого ты что-то ещё подразумевал?

S>>>Я делал тесты на C#,Delphi http://rsdn.ru/forum/philosophy/555869.flat
Автор: VladD2
Дата: 02.03.04
. Просил сделать на С++ но народ не стал делать.

EP>>Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++.
EP>>Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости.
S> Ну в Net есть дженерики. Да они медленнее примерно в 2 раза за счет отсутствия инлайна.

Это цифра с потолка.

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

Во-вторых даже если брать только цену вызова ~T нужно понимать что цена каждого вызова суммируется, то есть N*T. А чтобы посчитать "во сколько раз" — нужно знать цену конечной полезной операции P. Получается формула (N*T + P)/P, и чем мельче сама операция P — тем в большее число раз разрыв. На C++ можно без проблем оборачивать в абстракции даже мелкие операции без потерь: конкретный пример
Автор: Evgeny.Panasyuk
Дата: 23.12.14
.

В-третьих помимо тормозов дженериков/лямбд есть тормоза лишних косвенностей по памяти. Потому что default это pointer semantics, а не value semantics как в C++. Да есть структуры, но они далеко не всегда применимы: например
Автор: Evgeny.Panasyuk
Дата: 11.10.14
. Нельзя произвольный класс превратить в структуру, например List и т.п.
Вот небольшой пример
Автор: Sinix
Дата: 05.06.15
для оценки эффекта: заменили 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> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.


Дальше-то ты какой вывод делаешь?
Re[23]: Java vs C# vs C++
От: alex_public  
Дата: 02.10.15 22:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Пишут что? В каких случаях? Удобнее для чего?

S> Удобнее для написания сайтов, учетных систем массовых задач.

Сайты удобнее делать на скриптовых языках. А что такое "учетные системе массовых задач"?.

S> Еще раз повторю формулу экономической целесообразности

S>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности

Да, всё верно. Именно из-за этого факта и существуют такие вещи как Java/C#. И как раз сейчас в связи со стагнацией в росте производительности процессоров, ростом мобильного рынка (где вообще печаль с производительностью) и начинающейся модой на "интернет вещей" (а туда вообще даже сами платформы jvm/clr не лезут по нормальному, не говоря уже о какой-то производительности) в этом вопрос возможны существенные корректировки.

S> Я не против тестов, я против синтетических тестов. В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд. Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.

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

Из этого текста создаётся такое впечатление, что все эти sql серверы, http серверы, браузеры и т.п., в которых происходит основное время исполнения задачи (по твоим же словам) и которые кстати в подавляющем большинстве написаны на C/C++, пишутся не программистами, а какими-то инопланетянами. )))
Re[16]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 23:12
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Линейный поиск обычно идёт с конца, а не сначала.

V>>Обычно он идёт двоичный.
EP>Обычно он линейный.

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


EP>Сортировка вставками чаще всего применяется для случаев где элементы находятся недалеко от своего места — например на нижних уровнях std::sort — в этих случаях делать обычный двоичный поиск невыгодно.


Сортировка вставками — это один из наиэффективнейших алгоритмов сам по себе для случая, когда в массиве немного неотсортированных элементов. А "далеко" или "недалеко" — это всё спекуляции. В std::sort идет линейный поиск по той причине, которую уже многократно обсуждали на этом сайте — до, примерно, 16-ти элементов на современных процессорах выгодней искать элемент линейно, а не двоичным поиском. В общем же случае это утверждение совершенно не верно.


EP>Или например вот визуализация insertion sort:

EP>http://www.youtube.com/watch?v=8oJS1BMKE64

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


EP>В тех реализациях что я представляю — лишний проход есть.


Мммм...
Похоже, что в тех реализациях, что ты представляешь — пузырьковая сортировка отработает N! (факториал) раз независимо от исходных данных. ))


EP>Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код.


Стандартная и есть без лишнего прохода. Из вики:

Введение индикатора (флажка F) действительно произошедших во внутреннем цикле обменов уменьшает число лишних проходов в случаях с частично отсортированными массивами на входе. Перед каждым проходом по внутреннему циклу флажок сбрасывается в 0, а после действительно произошедшего обмена устанавливается в 1. Если после выхода из внутреннего цикла флажок равен 0, то обменов не было, то есть массив отсортирован и можно досрочно выйти из программы сортировки.

Re[16]: Java vs C# vs C++
От: vdimas Россия  
Дата: 02.10.15 23:28
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Вот визуализация реализации std::sort — там сортировка вставками на последнем этапе.


Оттуда же ролик:
https://www.youtube.com/watch?v=kPRA0W1kECg

Сортировка прямым выбором заборола быструю почти в два раза, ы-ы-ы.

Кста, сортировка прямым выбором одна из наипростейших для реализации...
Т.е., от исходных данных сильно всё зависит.
Re[17]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 23:47
Оценка:
Здравствуйте, 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, то обменов не было, то есть массив отсортирован и можно досрочно выйти из программы сортировки.


И? Берём твой пример 1 2 3 4 6 5 7 8 9, начинаем:

* "Перед каждым проходом по внутреннему циклу флажок сбрасывается в 0"
flag = 0

В этом цикле у нас будет один swap/обмен 6<->5 :
* "а после действительно произошедшего обмена устанавливается в 1"
Устанавливаем flag = 1

* "Если после выхода из внутреннего цикла флажок равен 0, то обменов не было, то есть массив отсортирован и можно досрочно выйти из программы сортировки."
flag == 1, значит досрочно выйти мы не можем.
Делаем ещё один проход, опять вначале устанавливаем flag в 0 — на этот раз без обменов, и после этого второго прохода можем выйти досрочно.
Re[17]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 02.10.15 23:58
Оценка:
Здравствуйте, vdimas, Вы писали:

EP>>Вот визуализация реализации std::sort — там сортировка вставками на последнем этапе.

V>Оттуда же ролик:
V>https://www.youtube.com/watch?v=kPRA0W1kECg
V>Сортировка прямым выбором заборола быструю почти в два раза, ы-ы-ы.
V>Кста, сортировка прямым выбором одна из наипростейших для реализации...
V>Т.е., от исходных данных сильно всё зависит.

Конечно зависит, размер данных решает — в данном ролике он разный в каждом эпизоде

P.S. Сортировка выбором (не стабильный вариант) даёт наименьшее возможное количество перемещений элементов, вполне полезное свойство.
Re[18]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 00:13
Оценка:
V>>Т.е., от исходных данных сильно всё зависит.
EP>Конечно зависит, размер данных решает — в данном ролике он разный в каждом эпизоде

А вот параллельное сравнение на одинаковом небольшом размере:
http://www.youtube.com/watch?v=ZZuD6iUe3Pc
Re[24]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 07:24
Оценка:
Здравствуйте, alex_public, Вы писали:

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


EP>>>Пишут что? В каких случаях? Удобнее для чего?

S>> Удобнее для написания сайтов, учетных систем массовых задач.

_>Сайты удобнее делать на скриптовых языках. А что такое "учетные системе массовых задач"?.

Учетные системы ERP это ERP Microsoft Dynamics,SAP, Oracle E-Business Suite ну и конечно 1С.

По поводу сайтов, то Asp.Net MVC очень востребована. Мало того сейчас серверная часть больше похожа на HTTP сервис, где выдается начальная страница, а с клиента через AJAX данные подгружаются ввиде Json и вся работа по построению DOM лежит на клиенте с помощью AJAX и JS библиотек
Например
http://itchief.ru/lessons/bootstrap-3/92-bootstrap-3-visual-editors
http://metanit.com/sharp/mvc5/17.3.php
http://demos.telerik.com/kendo-ui/grid/index
http://w2ui.com/web/demo/grid
http://demo.qooxdoo.org/current/showcase/#Tree

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++, пишутся не программистами, а какими-то инопланетянами. )))

Вот посмотри мои разработки http://infostart.ru/profile/82159/public/
Большинство сделаны для связи 1С с внешним миров и со связью из внешнего мира с 1С. Я ими активно пользуюсь. И посмтори сколько комментариев и какие.
Народ просто не понимает о чем речь. И вместо использования готовых компонентов для хэширования использует побитовые операции на 1C.
http://forum.infostart.ru/forum86/topic136695/
http://infostart.ru/public/99739/ А ты говоришь про скорость

Народ в большинстве случаев варится в своем тесном мирке. Разработка SQL серверов и Вэб серверов весьма нетривиальная задача, которая для среднестатистического программиста далека как Марс от Земли.
и солнце б утром не вставало, когда бы не было меня
Re[24]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 07:41
Оценка:
Здравствуйте, 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
Автор: VladD2
Дата: 02.03.04
. Просил сделать на С++ но народ не стал делать.

EP>>>Я уже и в этой теме много раз сказал, что если брать низкоуровневый код, типа как по твоей ссылке — где сортируется конкретный тип массива, с конкретным типом элементов, с конкретным типом предиката — то скорость на Java/C# будет очень близкой к C++.
EP>>>Основное преимущество по скорости у C++ в другом — в том что можно подняться на более высокий уровень абстракции не теряя, либо практически не теряя скорости.
S>> Ну в Net есть дженерики. Да они медленнее примерно в 2 раза за счет отсутствия инлайна.

EP>Это цифра с потолка.


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

поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много. Кстати по поводу использования структур.
http://rsdn.ru/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03
Смысл в том, что если прошла сборка мусора, то джит собирает 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>Дальше-то ты какой вывод делаешь?

Вывод в том, что существование тех или иных языков или платформ вызвано не только скоростью выполнения, и от количества специалистов. А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит
и солнце б утром не вставало, когда бы не было меня
Re[25]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 10:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>>>А причём востребованность?

S>>>>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация,
EP>>>>Пишут что? В каких случаях? Удобнее для чего?
S>>> Удобнее для написания сайтов, учетных систем массовых задач.
EP>>И? Это единственные существующие задачи?
S> Такими задачами занимаются большинство программистов.

ОК, дальше-то какой вывод?

S>>> Еще раз повторю формулу экономической целесообразности

S>>>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
EP>>ОК, повторил, что ты этим хочешь сказать? (причем это одна из возможных формул, а не единственная)
EP>>Да, целесообразность тоже нужно учитывать, с этим не спорю — кроме этого ты что-то ещё подразумевал?
S> К тому, что нужны специалисты со снанием конкретного языка.

Когда как. Бывает заказчику всё равно какой там язык, главное результат.

S>Какова доля программистов С++ в программистском мире?


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

S>А задач таких полно. И нужна скорость решения, а не скорость выполнения.


С этим никто не спорил, и в общем-то это очевидные вещи.

S>У меня куча отчетов где скорость новых быстрее раз в 10.

S>Но например этот отчет бухгалтер делает раз в месяц. И он может подождать даже пол часа, занимаясь другой работой.

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

S>Иногда нужно быстро решить задачу, а сколько она будет выполняться не имеет значения.


Расшифруй.

S> поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много.


Много, и тормоза отнюдь не двукратные.

S>Кстати по поводу использования структур.

S>http://rsdn.ru/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03
Смысл в том, что если прошла сборка мусора, то джит собирает 0 поколения, а старые поколения если ссылки на них не менялись не трогает. А вот для если они менялись, то он их помечает и в итоге происходят тормоза. Поэтому Хэш таблицы например сделаны на массиве структур. Но при этом и сборщики мусора совершенствуются


А я вообще забыл упомянуть тормоза от GC, это отдельная тема. Тормоза для pointer semantics style есть даже без учёта бОльшей нагрузки на GC.
И если активно использовать pointer semantics в C++ — то и там появятся точно такие же тормоза как и в Java/C#/etc: пример
Автор: Evgeny.Panasyuk
Дата: 18.10.14
— заменили плотно упакованные элементы, на структуру ссылочного вида — в результате разница по скорости 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>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит


Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?
Re[18]: Java vs C# vs C++
От: vdimas Россия  
Дата: 03.10.15 10:17
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

V>>Линейный он лишь для случая одновременного поиска и сдвига элементов массива.

V>>В этом случае он представляет из себя разновидность пузырьковой сортировки.
EP>Это не разновидность пузырьковой сортировки.

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

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


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

EP>Может, не спорю что есть вариант с двоичным поиском, и что у него есть область применения. Я говорю что обычно он линейный.

"Обычно" — это из-за std::sort, что ле? ))
Там, как раз, всё очень необычно, а весьма специфично для специфичного этапа сортировки.


V>>В std::sort идет линейный поиск по той причине, которую уже многократно обсуждали на этом сайте — до, примерно, 16-ти элементов на современных процессорах выгодней искать элемент линейно, а не двоичным поиском.

EP>В том числе и по этой причине.

На самом деле только по этой причине.
Как раз для поиска в маленьких массивах использование линейного поиска — обычно.


EP>Там вообще говоря swap использовать не выгодно — там нет необходимости менять каждый соседний элемент между собой. Оптимальнее переместить текущий элемент в temp, все остальные переместить вправо, а потом переместить temp в левый край. Это операция ЕМНИП rotate_by_one.


Об этом и речь, чтобы не производить на каждом шаге сравнение с перестановкой. Но искать-то выгодней двоично, а не линейно, для массива из более 16-ти элементов на современных машинах!


V>>Похоже, что в тех реализациях, что ты представляешь — пузырьковая сортировка отработает N! (факториал) раз независимо от исходных данных. ))

EP>Очень смешно. Пузырьковая сортировка квадратична в худщем случае.

Вот как раз не смешно. Самый простой вариант пузырьковой сортировки отрабатывает фиксированное кол-во раз, независимо от содержимого массива:
for(int end = size - 1, end > 0, end--)
  for(int i = 0; i < end; i++)
    swap_if_needed(array[i], array[i+1]);

Чуть меньше, чем квадратичная, не?

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


EP>>>Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код.

V>>Стандартная и есть без лишнего прохода.
EP>Код в студию, иначе наш спор не разрешится.

В западной литературе шейкерную выделяют в отдельный вид сортировки, нам же её давали как разновидность пузырьковой.
Более того, самих разновидностей шейкерной как минимум три. Визуализация шейкерной сортировки на видео — самая неэффективная, ы-ы-ы.

В одной из разновидностей шейкерной запоминают последнее место обмена, при движении вперед это будет верхняя граница, при движении назад аналогично обнаруживается нижняя граница. Т.е. сужение диапазона на каждом проходе будет происходить не на 1 элемент (как на видео), а до фактического места последнего обмена.

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

Код тривиальный, но длинный, открывать студию и писать не буду. ))

Вербально как-то так:

1. движение вперед от нижней до верхней границы неотсортированной области, поиск первой пары для обмена, запоминание нижней границы отсортированного диапазона (минус одна позиция от текущей); если обмена не было — выход.

2. продолжаем движение вперед, обмен при необходимости, запоминание верхней границы отсортированного диапазона.

3. сравнение с первым элементом из отсортированной области, при необходимости продолжаем "всплытие" (в любом случае, запомненная на предыдущем шаге граница не изменяется).

4. движение назад аналогично, потом goto 1.

На каждом шаге у нас "всплывает" максимальный (или "тонет" минимальный) элемент из неотсортированной области к её краю, т.е. применяется обычный пузырёк; на границе отсортированной области алгоритм меняется — мы движемся лишь до тех пор, пока необходим обмен.
Отредактировано 03.10.2015 11:07 vdimas . Предыдущая версия .
Re[25]: Java vs C# vs C++
От: alex_public  
Дата: 03.10.15 10:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Сайты удобнее делать на скриптовых языках. А что такое "учетные системе массовых задач"?.

S> Учетные системы ERP это ERP Microsoft Dynamics,SAP, Oracle E-Business Suite ну и конечно 1С.

Я в курсе что такое ERP (их кстати намного больше, причём как наших закрытых, так и иностранных opensource). Просто не думал, что это можно так расшифровать на русский. )))

S>По поводу сайтов, то Asp.Net MVC очень востребована. Мало того сейчас серверная часть больше похожа на HTTP сервис, где выдается начальная страница, а с клиента через AJAX данные подгружаются ввиде Json и вся работа по построению DOM лежит на клиенте с помощью AJAX и JS библиотек


1. Раз всё делается на JS, то тогда причём тут собственно .net?
2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно).

_>>Да, всё верно. Именно из-за этого факта и существуют такие вещи как Java/C#. И как раз сейчас в связи со стагнацией в росте производительности процессоров, ростом мобильного рынка (где вообще печаль с производительностью) и начинающейся модой на "интернет вещей" (а туда вообще даже сами платформы jvm/clr не лезут по нормальному, не говоря уже о какой-то производительности) в этом вопрос возможны существенные корректировки.

S> Ну сейчас идут по пути распараллеливания кода. Кстати многие сортировки можно распараллелить.

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

S> Вот посмотри мои разработки http://infostart.ru/profile/82159/public/

S>Большинство сделаны для связи 1С с внешним миров и со связью из внешнего мира с 1С. Я ими активно пользуюсь. И посмтори сколько комментариев и какие.
S>Народ просто не понимает о чем речь. И вместо использования готовых компонентов для хэширования использует побитовые операции на 1C.
S>http://forum.infostart.ru/forum86/topic136695/
S>http://infostart.ru/public/99739/ А ты говоришь про скорость

Скорость безусловно нужна. На своём уровне. В данном случае она нужна в языке, на котором написана сама платформа 1C (надеюсь ты в курсе, на чём она написана?). Ситуация полностью аналогичная раскладу браузер (все написаны на C++) и JS в нём. Ну точнее аналогично ситуации с браузерами 15 летней давности — с тех пор JS оптимизировался, обзавёлся JIT'ом и почти догнал по скорости C#/Java. Интересно, а в 1C не планируют такого же? )

S>Народ в большинстве случаев варится в своем тесном мирке. Разработка SQL серверов и Вэб серверов весьма нетривиальная задача, которая для среднестатистического программиста далека как Марс от Земли.


SQL сервер действительно не простая вещь (если конечно хочется нормального быстродействия), хотя вполне подъёмная. Только вот даже если заняться таким, то будут очень сомнительны перспективы выхода на рынок. А вот например NoSQL решения (которые во многих случаях совсем не проще) появляются вокруг как грибы. Как раз потому, что данный рынок ещё только формируется.

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

Да, кстати, а авторы того же 1C — они значит с Марса всё же? )))
Re[9]: Java vs C# vs C++
От: PM  
Дата: 03.10.15 10:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>В заголовок новости не поместилась информация о том, что они:

PM>> PM>>У меня есть сомнения, что первые 2 пункта легко реализуемы в управляемых средах (не знаю, добавили ли уже в Java value types)

I>То есть, язык ни при чём. Чтд.


Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR

Почитайте на досуге как авторы LMAX героически боролись (и вроде бы продолжают бороться) с JVM — пытаясь выровнять данные по границе кэш-линии; как затюнинговать сборку мусора, чтобы система не замерзала в неподходящий момент (и перезапускать всё разв в сутки в конечном итоге)

Короче, сплошной <троллейбус из буханки хлеба.jpeg>
Re[26]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 10:42
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Сайты удобнее делать на скриптовых языках. А что такое "учетные системе массовых задач"?.

S>> Учетные системы ERP это ERP Microsoft Dynamics,SAP, Oracle E-Business Suite ну и конечно 1С.

_>Я в курсе что такое ERP (их кстати намного больше, причём как наших закрытых, так и иностранных opensource). Просто не думал, что это можно так расшифровать на русский. )))


S>>По поводу сайтов, то Asp.Net MVC очень востребована. Мало того сейчас серверная часть больше похожа на HTTP сервис, где выдается начальная страница, а с клиента через AJAX данные подгружаются ввиде Json и вся работа по построению DOM лежит на клиенте с помощью AJAX и JS библиотек


_>1. Раз всё делается на JS, то тогда причём тут собственно .net?

Ну например есть TypeScript. Да и серверную часть тоже нужно писать на Asp.Net mvs писать запросы к базе итд. Клиентская часть далеко не все.

_>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно).

А где же высокоскоростной C++?

_>>>Да, всё верно. Именно из-за этого факта и существуют такие вещи как Java/C#. И как раз сейчас в связи со стагнацией в росте производительности процессоров, ростом мобильного рынка (где вообще печаль с производительностью) и начинающейся модой на "интернет вещей" (а туда вообще даже сами платформы jvm/clr не лезут по нормальному, не говоря уже о какой-то производительности) в этом вопрос возможны существенные корректировки.

S>> Ну сейчас идут по пути распараллеливания кода. Кстати многие сортировки можно распараллелить.

_>Распараллеливание может быть актуально (собственно только в этом направление и есть прогресс в последнее время) для серверных решений. А для всего остального, из выше перечисленного, это абсолютно не актуально.

Ну почему. Сейчас все пишется через await, Ajax ы. Это конечно не System.Threading.Tasks.Parallel но ассинхронные вычисления.
Но мы то говаорим о вытеснении C++ более медленных платформ.

S>> Вот посмотри мои разработки http://infostart.ru/profile/82159/public/

S>>Большинство сделаны для связи 1С с внешним миров и со связью из внешнего мира с 1С. Я ими активно пользуюсь. И посмтори сколько комментариев и какие.
S>>Народ просто не понимает о чем речь. И вместо использования готовых компонентов для хэширования использует побитовые операции на 1C.
S>>http://forum.infostart.ru/forum86/topic136695/
S>>http://infostart.ru/public/99739/ А ты говоришь про скорость

_>Скорость безусловно нужна. На своём уровне. В данном случае она нужна в языке, на котором написана сама платформа 1C (надеюсь ты в курсе, на чём она написана?). Ситуация полностью аналогичная раскладу браузер (все написаны на C++) и JS в нём. Ну точнее аналогично ситуации с браузерами 15 летней давности — с тех пор JS оптимизировался, обзавёлся JIT'ом и почти догнал по скорости C#/Java. Интересно, а в 1C не планируют такого же? )

Да какая разница на чем написана сама платформа, а то с какой скоростью работает интерпретатор. До сих пор основная часть нагрузки идет на сервере.
Например в свое время при работе в терминалах очень тормозила печать при слабой связи. На толстом клиенте сделал связь по Tcp/IP и передавал данные по которым уже строил печатные формы. Трафик сократился в тысячи раз. Но пока 1С в управляемых формах формирует печатную форму на сервере.
Там даже не ввели замыканий http://its.1c.ru/docs/v8nonmodal/

S>>Народ в большинстве случаев варится в своем тесном мирке. Разработка SQL серверов и Вэб серверов весьма нетривиальная задача, которая для среднестатистического программиста далека как Марс от Земли.


_>SQL сервер действительно не простая вещь (если конечно хочется нормального быстродействия), хотя вполне подъёмная. Только вот даже если заняться таким, то будут очень сомнительны перспективы выхода на рынок. А вот например NoSQL решения (которые во многих случаях совсем не проще) появляются вокруг как грибы. Как раз потому, что данный рынок ещё только формируется.



_>Что же касается http-серверов, то это достаточно тривиальная вещь, которую частенько реализуют заново в разных проектах. Более того, есть множество гораздо более сложных вещей, которыми заняты "среднестатистические программисты". К примеру любая современная онлайновая игрушка на порядок сложнее.

Ты путаешь сервисы с серверами. Мы говорим об IIS, апаче https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2

_>Да, кстати, а авторы того же 1C — они значит с Марса всё же? )))

Они отличаются от среднестатистических программистов. Еще раз повторю, что есть рынок на котором требуются решения задач.
Есть рынок средств и программистов с разной квалификацией итд. И побеждает тот кто предлагает лучшее по критерию цена качество время
и солнце б утром не вставало, когда бы не было меня
Re[26]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 11:08
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>>>А причём востребованность?

S>>>>>> При том, что пишут на тех языках на которых удобнее и нужна меньшая квалификация,
EP>>>>>Пишут что? В каких случаях? Удобнее для чего?
S>>>> Удобнее для написания сайтов, учетных систем массовых задач.
EP>>>И? Это единственные существующие задачи?
S>> Такими задачами занимаются большинство программистов.

EP>ОК, дальше-то какой вывод?

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

S>>>> Еще раз повторю формулу экономической целесообразности

S>>>>(стоимость разработки) + (стоимость железа) для достижения одинаковой вычислительной мощности
EP>>>ОК, повторил, что ты этим хочешь сказать? (причем это одна из возможных формул, а не единственная)
EP>>>Да, целесообразность тоже нужно учитывать, с этим не спорю — кроме этого ты что-то ещё подразумевал?
S>> К тому, что нужны специалисты со снанием конкретного языка.

EP>Когда как. Бывает заказчику всё равно какой там язык, главное результат.

Еще раз соотношение цена качество время

S>>Какова доля программистов С++ в программистском мире?


EP>Не знаю, но уж точно не маленькая. И не только из-за его скорости или других удобств, например у него самый широкий из mainstream охват по платформам, и например есть ещё и legacy.


http://www.it-dominanta.ru/ru/news/272

Традиционно в авангарде — Java-разработчики, последние 5-6 лет это была самая востребованная категория ИТ-специалистов, также как и программисты на С++/C#: в количественном отношении рынок нуждается в них более всего.

При этом в последние годы самыми высокооплачиваемыми программистами были мобильные разработчики: средний уровень их зарплат рос гораздо быстрее, чем у других категорий. Но итоги 2014 года показывают, что в этом сегменте рынка труда в ИТ-сфере наметились перемены, и существенные. Он остывает, кадровый дефицит в сфере мобильной разработки во многом преодолен, и темпы роста зарплат пошли на снижение.

Более всего на рынке разработки ценятся Java-девелоперы. Средний уровень их зарплаты составляет 95 500 рублей, а выросли они за год примерно на 26%. Второе место по уровню дохода занимают Android-разработчики, но самые «хлебные» времена для этой категории программистов миновали. Рост зарплат здесь невелик – всего 12% в год. Еще хуже перспективы у разработчиков приложений для iOS. Их средняя зарплата составляет 80500 рублей, и выросла она за год всего на 6%.

Относительно спокойны могут быть девелоперы, которые специализируются на C# и С++. Первые получают в среднем 82000 рублей, при этом рост зарплат в прошлом году составил 24%. Вторые «стоят» дешевле, 80000 рублей, а уровень их дохода подрос на 18%.


http://аутсорсинг1с.рф/blog/96

По данным Superjob.ru, наиболее востребованными в 2012 году были разработчики, особенно — опытные (JAVA). Так же в 2012 году среди разработчиков были востребованы веб разработчики C#, PHP. Второе место по востребованности на рынке труда продолжают занимать специалисты службы поддержки. Третье место по праву занимают тестировщики.

В 2013 году аналитики прогнозировали рост спроса на ИТ-специалистов на фоне умеренного увеличения численности соискателей, сохранение дефицита программистов и разработчиков. Причем самыми востребованными программистами остаются специалисты, пишущие на «1С» и PHP. Также на рынке ИТ-кадров ожидался опережающий другие рынки рост зарплатных предложений.


S>>А задач таких полно. И нужна скорость решения, а не скорость выполнения.


EP>С этим никто не спорил, и в общем-то это очевидные вещи.


S>>У меня куча отчетов где скорость новых быстрее раз в 10.

S>>Но например этот отчет бухгалтер делает раз в месяц. И он может подождать даже пол часа, занимаясь другой работой.

EP>Бывают и такие варианты.

EP>А бывают и другие, например бухгалтер генерирует отчёт, потом проверяет его, исправляет ошибки, и опять запускает — и так может быть несколько раз.
EP>Или например инженер делает расчёт, ждать результата он может долго скажем день, но при этом бОльшая доступная вычислительная мощность переходит в качество — он может сделать более густую расчётную сетку, произвести большее количество нелинейных расчётов и т.д. и т.п.
Ты меня не читаешь. Я говорю, что ускоряю скорость отчетов в 100 раз. Все довольны, но иногда прихожу к буху и спрашиваю каким отчетом пользутесь, а они говоря, что по привычке старым. При этом это не доли секунд, а пол часа.

S>>Иногда нужно быстро решить задачу, а сколько она будет выполняться не имеет значения.


EP>Расшифруй.

Есть задача и её решить нужно еще вчера. Берешь и решаешь задачу без оглядки на выбор более оптимальных алгоритмов, языков. Нужна скорость разработки.
S>> поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много.

EP>Много, и тормоза отнюдь не двукратные.

Правильно, значительно меньше при правильном написании алгоритма. Все твои примеры это выбор самого плохого подбора алгоритма.

S>>Кстати по поводу использования структур.

S>>http://rsdn.ru/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03
Смысл в том, что если прошла сборка мусора, то джит собирает 0 поколения, а старые поколения если ссылки на них не менялись не трогает. А вот для если они менялись, то он их помечает и в итоге происходят тормоза. Поэтому Хэш таблицы например сделаны на массиве структур. Но при этом и сборщики мусора совершенствуются


EP>А я вообще забыл упомянуть тормоза от GC, это отдельная тема. Тормоза для pointer semantics style есть даже без учёта бОльшей нагрузки на GC.

EP>И если активно использовать pointer semantics в C++ — то и там появятся точно такие же тормоза как и в Java/C#/etc: пример
Автор: Evgeny.Panasyuk
Дата: 18.10.14
— заменили плотно упакованные элементы, на структуру ссылочного вида — в результате разница по скорости 208.6x, и это без учёта работы менеджера памяти.

EP>Но в C++ default это value semantics, и там его намного легче использовать чем в языках заточенных под pointer semantics.

Тормоза от GC зависят от задач. В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало.
Не все так однозначно.
S>>Это
EP>>>>>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше.
S>> Или если таких приложений будет 1-2 он уйдет к тем у кого 1000-100000.

EP>Не понял этого тезиса.

Да в том, что нужна скорость разработки и количество специалистов которые могут решить эти задачи. Если таких специалистов оочень мало, то будут побеждать те языки где сложность входа значительно меньше. Как ты думаешь, что проще для изучения 1С++ или 1С?

S>>Везде нужна экономическая целесообразность. Поэтому и существуют С++,С# и 1С.


EP>Нужна, я этого не отрицал.


S>>>>В реальных приложениях занятость процессора очень далека до 100%. Большинство время уходит на ожидание запроса к SQL, HTTP запроса, итд.

EP>>>Старая шарманка "всё в базу упираются"
EP>>>У меня в продукте вообще нет никакой никакого SQL и никаких HTTP, не надо проецировать какие-то свои личные задачи на всех, и делать далеко идущие выводы
S>> И какова занятость процессора в твоих приложениях?

EP>Это надо у клиентов спросить, так как это библиотека

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

S>>>>Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.

EP>>>ASM.JS достаточно быстрый. Я даже выше приводил ссылку. C++ скомпилированный в ASM.JS обогнал C# в своей родной среде практически в два раза
EP>>>JavaScript, в веб-браузере, Карл!
S>> В итоге все зависит от компилятора. Например TS тоже транслируется в JS и ничто не мешает транслировать в более оптимальный. Здесь проблема не языков а компиляторов которые совершенствуются.

EP>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.


S>>>> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.

EP>>>Дальше-то ты какой вывод делаешь?
S>> Вывод в том, что существование тех или иных языков или платформ вызвано не только скоростью выполнения

EP>В целом да, а в частности нет. Например сделали язык заточенный под скорость, потому что нужна скорость — вопрос, чем вызвано его существование?

Тем, что у него есть своя ниша. А вот какова емкость этой ниши?

S>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит


EP>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?

Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С
и солнце б утром не вставало, когда бы не было меня
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 11:14
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Линейный он лишь для случая одновременного поиска и сдвига элементов массива.

V>>>В этом случае он представляет из себя разновидность пузырьковой сортировки.
EP>>Это не разновидность пузырьковой сортировки.
V>Извини, но сравнение и обмен строго с соседним элементом — это характеристика сортировок из семейства пузырьковой.
V>Не помнишь, почему сортировка названа "пузырьковой"?

Я же говорю, что при повороте swap не нужен — это точно не пузёрок.

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


Тебе сказали что описанный тобой вариант это shaker sort. Утверждений того что пузырьковая только одна — не было.

V>Аналогично по сортировкам слиянием — мы их штук пять-шесть проходили (если склероз не изменяет). А на визуализации я вижу лишь один из вариантов.


Естественно там далеко не все разновидности. Сортировку слияниям кстати хорошо разбирает Степанов в своей книге Elements of Programming.

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

EP>>Может, не спорю что есть вариант с двоичным поиском, и что у него есть область применения. Я говорю что обычно он линейный.
V>"Обычно" — это из-за std::sort, что ле? ))
V>Там, как раз, всё очень необычно, а весьма специфично для специфичного этапа сортировки.

Обычно — это значит типичный код реализации.

EP>>Там вообще говоря swap использовать не выгодно — там нет необходимости менять каждый соседний элемент между собой. Оптимальнее переместить текущий элемент в temp, все остальные переместить вправо, а потом переместить temp в левый край. Это операция ЕМНИП rotate_by_one.

V>Об этом и речь, чтобы не производить на каждом шаге сравнение с перестановкой.

Не, как раз из-за того что бывает выгодней производить и сравнение и перемещения одновременно — то эти два этапа сливают. А выгодно потому что условных операций / ветвей меньше — достаточно дать гарантию что в самом начале есть guard element, тогда на каждой итерации достаточно одного вызова предиката сравнения, без проверки выхода за пределы массива.

V>Но искать-то выгодней двоично, а не линейно, для массива из более 16-ти элементов на современных машинах!


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

V>>>Похоже, что в тех реализациях, что ты представляешь — пузырьковая сортировка отработает N! (факториал) раз независимо от исходных данных. ))

EP>>Очень смешно. Пузырьковая сортировка квадратична в худщем случае.
V>Вот как раз не смешно. Самый простой вариант пузырьковой сортировки отрабатывает фиксированное кол-во раз, независимо от содержимого массива.

С квадратичной сложностью, а не факториалом

V>Я же тебе намекаю уже многократно,


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

V>что пузырьковая сортировка — это целое семейство алгоритмов.


А теперь прочитай ещё раз мой ответ на эту тему:

V>>Не будет. Простой пузырёк протягивает флаг наличия несортированных элементов, а модифицированный вместо этого протягивает границы несортированной области (индекс начала и индекс конца) и работает в оба направления туда-сюда, сужая к центру (обычно) несортированную область.
EP>Даже с этими модификациями получается больше сравнений — дойдёт до 6, сделает swap, дойдёт до конца, а потом ещё сделает проход от 5 до 1.


EP>>>>Покажи реализацию без лишнего прохода, или хотя бы дай ссылку на код.

V>>>Стандартная и есть без лишнего прохода.
EP>>Код в студию, иначе наш спор не разрешится.
V>В западной литературе шейкерную выделяют в отдельный вид сортировки, нас же её давали как разновидность пузырьковой.

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

V>Более того, визуализация шейкерной сортировки на видео — ошибочна, ы-ы-ы.


Какое видео?

V>В шейкерной необходимо запоминать первое и последнее место обмена, т.е. должно происходить сужение диапазона.


Да, но только самое правое место обмена запоминается/важно при проходе направо, а левое — при проходе налево.

V>На прямом проходе обнаруживается единственный обмен 5 с 6, на обратном проходе должно быть одно сравнение 5 с 4 и сразу выход.


Нет там выхода сразу после сравнения 4 vs 5. У пузырьковой/шейкера нет break внутри цикла. Вместо пятёрки там мог быть ноль: 1 2 3 4 6 0 7 8 9.

Да даже если допустить что там выход после 4 vs 5 — это всё равно опровергает твой тезис о том что вставками здесь дороже, так как там столько же сравнений.

V>Код тривиальный, писать не буду. ))


Можешь скопировать откуда-нибудь, хоть псевдокод. Только не тяни, не надо растягивать это на десятки сообщений
Re[27]: Java vs C# vs C++
От: vdimas Россия  
Дата: 03.10.15 11:24
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно).

S> А где же высокоскоростной C++?

Там, где latency в микросекундах или единиц миллисекунд измеряется, вестимо.
Пока сайты будут по нескольку секунд каждую страницу открывать, клиента и сервера можно писать хоть на руби, хоть на питоне.


S> Ну почему. Сейчас все пишется через await, Ajax ы. Это конечно не System.Threading.Tasks.Parallel но ассинхронные вычисления.

S>Но мы то говаорим о вытеснении C++ более медленных платформ.

Из последнего что создаёт информационный шум — во всём мире начинают потихоньку переходить на терабитные сетки. Это нормальный процесс, рано или поздно он начался бы... Посмотрим, как это скажется на требованиях к быстрому клиенту и серверу. Пока что эти требования, мягко говоря, несерьезные, бо сетка съедает всё быстродействие.
Re[28]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 11:35
Оценка:
Здравствуйте, vdimas, Вы писали:

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


_>>>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно).

S>> А где же высокоскоростной C++?

V>Там, где latency в микросекундах или единиц миллисекунд измеряется, вестимо.

V>Пока сайты будут по нескольку секунд каждую страницу открывать, клиента и сервера можно писать хоть на руби, хоть на питоне.


S>> Ну почему. Сейчас все пишется через await, Ajax ы. Это конечно не System.Threading.Tasks.Parallel но ассинхронные вычисления.

S>>Но мы то говаорим о вытеснении C++ более медленных платформ.

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

Я уже писал, что сейчас сервер передает только Json данные. А DOM уже строится на клиенте, при этом используется кэширование на клиенте. То есть скорость передачи при этом не является ограничением.
Проблема в уже в JS.
и солнце б утром не вставало, когда бы не было меня
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 11:43
Оценка:
Пока я отвечал, ты существенно изменил сообщение. Отвечу на разницу, на которую ещё не ответил.

V>>>Похоже, что в тех реализациях, что ты представляешь — пузырьковая сортировка отработает N! (факториал) раз независимо от исходных данных. ))

EP>>Очень смешно. Пузырьковая сортировка квадратична в худщем случае.
V>Вот как раз не смешно. Самый простой вариант пузырьковой сортировки отрабатывает фиксированное кол-во раз, независимо от содержимого массива:
V>
V>for(int end = size - 1, end > 0, end--)
V>  for(int i = 0; i < end; i++)
V>    swap_if_needed(array[i], array[i+1]);
V>

V>Чуть меньше, чем квадратичная, не?

Квадратичная в чистом виде, потому что сумма арифметической прогрессии квадратична. Никакого факториала.

V>Код тривиальный, но длинный, открывать студию и писать не буду. ))


Да не надо писать, скопируй откуда-нибудь, или дай ссылку.

V>Вербально как-то так:

V>1. движение вперед от нижней до верхней границы неотсортированной области, поиск первой пары для обмена, запоминание нижней границы отсортированного диапазона (минус одна позиция от текущей); если обмена не было — выход.

V>2. продолжаем движение вперед, обмен при необходимости, запоминание верхней границы отсортированного диапазона.


V>3. сравнение с первым элементом из отсортированной области, при необходимости продолжаем "всплытие" (в любом случае, запомненная на предыдущем шаге граница не изменяется).


V>4. движение назад аналогично, потом goto 1.


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


И не одонго break'а внутри цикла, да?

Попробуй примени этот алгоритм к последовательности с нулём: 1 2 3 4 6 0 7 8 9
И к последовательности с пятёркой: 1 2 3 4 6 5 7 8 9
Если нет break'а, то в обоих случаях при обратном проходе должен дойти до самого начала
Re[10]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 12:03
Оценка:
Здравствуйте, PM, Вы писали:

PM>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR


Зато C/С++ есть для JVM и .Net и шота не видно никаких чудес. Джава и шарп рвут всё на своих платформах. Как то так.

PM>Почитайте на досуге как авторы LMAX героически боролись


Неинтересно, это разница в платформах.
Re[10]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 12:05
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну и ещё не забываем про то, что у главных компиляторов C++ в данным момент мощнейшие в мире оптимизаторы.


Только что сам сказал 'язык ни при чем,платформа при чем' и теперь оказывыется, что язык таки наше всё ?

Определись. ПОчему не видно никаких чудес у С/С++ на платформе джава или дотнет ?
Re[8]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 12:12
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>3. Ещё такой пример
Автор: Evgeny.Panasyuk
Дата: 20.06.15
: высокоуровневый код C++ скомпилированный в JavaScript почти в два раза быстрее аналога на C# в своей родной среде.

EP>JavaScript, в веб-браузере, Карл!

Сколько ты будешь мусолить этот булшыт ?

1 Вроде как очевидно, что здесь разные платформы. Попробуй тот же мега-с++ код скомпилировать в дотнет и открой для себя страшное — скорость сильно вряд ли будет отличаться от C#.

2 Попробуй скомпилировать C# в тот же javascript, получишь ровно тот же перформанс, что и после С++. А все почему ? Потому что js, а не потому что С++.

Вот скомпилить Шарп в натив сильно вряд ли выйдет, т.к. язык принципиально требует специальную платформу, как и js.
Re[9]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.10.15 12:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вот скомпилить Шарп в натив сильно вряд ли выйдет, т.к. язык принципиально требует специальную платформу, как и js.


А как же .net native?
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 12:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>

Причем самыми востребованными программистами остаются специалисты, пишущие на «1С» и PHP.


И что? Вывод дальше какой? Эникейщики ещё более востребованы

S>>>Но например этот отчет бухгалтер делает раз в месяц. И он может подождать даже пол часа, занимаясь другой работой.

EP>>Бывают и такие варианты.
EP>>А бывают и другие, например бухгалтер генерирует отчёт, потом проверяет его, исправляет ошибки, и опять запускает — и так может быть несколько раз.
EP>>Или например инженер делает расчёт, ждать результата он может долго скажем день, но при этом бОльшая доступная вычислительная мощность переходит в качество — он может сделать более густую расчётную сетку, произвести большее количество нелинейных расчётов и т.д. и т.п.
S> Ты меня не читаешь.

Читаю.

S>Я говорю, что ускоряю скорость отчетов в 100 раз. Все довольны, но иногда прихожу к буху и спрашиваю каким отчетом пользутесь, а они говоря, что по привычке старым. При этом это не доли секунд, а пол часа.


А ещё раз говорю, это один из вариантов. И я не оспариваю то что этот вариант реальный.

S>>> поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много.

EP>>Много, и тормоза отнюдь не двукратные.
S> Правильно, значительно меньше при правильном написании алгоритма. Все твои примеры это выбор самого плохого подбора алгоритма.

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

EP>>А я вообще забыл упомянуть тормоза от GC, это отдельная тема. Тормоза для pointer semantics style есть даже без учёта бОльшей нагрузки на GC.

EP>>И если активно использовать pointer semantics в C++ — то и там появятся точно такие же тормоза как и в Java/C#/etc: пример
Автор: Evgeny.Panasyuk
Дата: 18.10.14
— заменили плотно упакованные элементы, на структуру ссылочного вида — в результате разница по скорости 208.6x, и это без учёта работы менеджера памяти.

EP>>Но в C++ default это value semantics, и там его намного легче использовать чем в языках заточенных под pointer semantics.
S> Тормоза от GC зависят от задач.

Ещё раз, это пример не про сборку мусора и т.п., а чисто на случай когда используются указатели вместо value sematnics.

S>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало.

S>Не все так однозначно.

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

S>>>Это

EP>>>>>>Во-первых, это всего лишь один вариант целесообразности. Например железо может быть уже на миллионах устройств клиентов — и вместо покупки нового девайса, они пойдут к конкурентам, софт которых работает на текущем железе, пусть и стоимость его разработки была выше.
S>>> Или если таких приложений будет 1-2 он уйдет к тем у кого 1000-100000.
EP>>Не понял этого тезиса.
S> Да в том, что нужна скорость разработки и количество специалистов которые могут решить эти задачи.

Это важно в том числе

S>Если таких специалистов оочень мало, то будут побеждать те языки где сложность входа значительно меньше.


Побеждать в чём? В задачах неприхотливых ни к скорости, ни к потреблению энергии, ни к потреблению памяти? Да, конечно будут.

S>Как ты думаешь, что проще для изучения 1С++ или 1С?


Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще.

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

EP>>Например женщина в среднем вынашивает ребёнка в течении скажем 2% от продолжительности своей жизни, размазать этот процент по всем годам никак не получится, и она не сможет родить ребёнка через день после зачатия
S> Они нужны. Но у них своя ниша.

Несомненно

S>>>>>Заметь, что в браузерах победил JS. Опять же какая разница для пользователя в ожидании 0.1 или 0.2 секунды.

EP>>>>ASM.JS достаточно быстрый. Я даже выше приводил ссылку. C++ скомпилированный в ASM.JS обогнал C# в своей родной среде практически в два раза
EP>>>>JavaScript, в веб-браузере, Карл!
S>>> В итоге все зависит от компилятора. Например TS тоже транслируется в JS и ничто не мешает транслировать в более оптимальный. Здесь проблема не языков а компиляторов которые совершенствуются.
EP>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.
S> В C# еще больше.

Ещё больше чего? Бесплатных высокоуровневых абстракций?

S>Посмотри на тот же Code First и Linq.


Это C# Linq бесплатный?
Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.

S>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.


Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке.

S>>>>> Берем какую то задачу и программируем. Зная ЗП среднестатистического программиста вычисляем стоимость. Затем берем тесты и вычисляем стоимость железа для достижения одинакового результата.

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

Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да.
Дальше что? Ты можешь сразу сказать к чему ты подводить?

S>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит

EP>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?
S> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С

И??? Вывод какой?!
Re[11]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 12:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR

I>Зато C/С++ есть для JVM

Покажи нормальный компилятор C++ для JVM.
Re[28]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 12:23
Оценка: :)
Здравствуйте, vdimas, Вы писали:

S>> А где же высокоскоростной C++?


V>Там, где latency в микросекундах или единиц миллисекунд измеряется, вестимо.

V>Пока сайты будут по нескольку секунд каждую страницу открывать, клиента и сервера можно писать хоть на руби, хоть на питоне.

Там где latency в микросекундах и единицах миллисекунд нужен не высокоскоростной С++, а корректный код, предельно предсказуемый по издержкам и соответсвующая архитектура, фактически система реального времени. Вместо "выполним всё быстро-быстро" используется "вызов x занимает не более Y тактов".
А вот там, где обработка данных, т.е. нужна пропускная способность экстремальнее некуда — там да, без высокоскоростного С++ никак. Более того — и С++ часто не хватает, приходится или вставки ассемблера делать или генерить хитрый код или вытеснять вычисление в специализированый процессор, тот же gpu и тд.
Re[12]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 12:29
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

PM>>>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR

I>>Зато C/С++ есть для JVM

EP>Покажи нормальный компилятор C++ для JVM.


Не следил за вопросом. Качество генерации байткода у джавы и шарпа вполне нормальное. Основные проблемы с производительностью даёт сам джыт. Какой бы ты наипрекрасный байткод не подсунул, джыт всё равно его опаскудит.
Re[9]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 12:29
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

EP>>3. Ещё такой пример
Автор: Evgeny.Panasyuk
Дата: 20.06.15
: высокоуровневый код C++ скомпилированный в JavaScript почти в два раза быстрее аналога на C# в своей родной среде.

EP>>JavaScript, в веб-браузере, Карл!
I>Сколько ты будешь мусолить этот булшыт ?

А сколько ты ещё будешь нести свой "булшыт"?

I>1 Вроде как очевидно, что здесь разные платформы. Попробуй тот же мега-с++ код скомпилировать в дотнет и открой для себя страшное — скорость сильно вряд ли будет отличаться от C#.


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

I>2 Попробуй скомпилировать C# в тот же javascript, получишь ровно тот же перформанс, что и после С++. А все почему ? Потому что js, а не потому что С++.


Да нет же, ты пример не смотрел, сути тезиса не понял, зато "мнение имеешь" Правильно выше сказали "буквы не читай, сообщения пиши".
В C# скомпилированном в JavaScript точно также как и на .NET не будет заинлайненной лямбды, и от этого точно также будут тормоза.
Re[10]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 12:33
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

I>>Вот скомпилить Шарп в натив сильно вряд ли выйдет, т.к. язык принципиально требует специальную платформу, как и js.


G>А как же .net native?


native в данном вопросе это просто маркетинговый буллшит от микрософта. Примерно как light на сигаретах — не означает отсутствие вреда здоровью.
Re[27]: Java vs C# vs C++
От: PM  
Дата: 03.10.15 12:34
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

EP>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.

Kenny Kerr, автор ModernCPP, сделал генератор С++ библиотеки из Windows Runtime API. Вот свежий пример современного высокоуровневого С++ кода: http://moderncpp.com/2015/05/12/when-standard-c-isnt-enough/

I’ve created a currency formatter, set the rounding algorithm, and formatted a value. What about Standard C++? A lot of developers seem to think that C# is the most popular language on the Windows platform today because it is so much better than C++. It’s not, instead it’s all about the tooling. One of the main arguments for .NET was that it avoided the reference counting hell that C++ apparently produced. Proponents of this position would like to show you the example above written in Standard C++:

HSTRING_HEADER header = {};
HSTRING string = nullptr;
WindowsCreateStringReference(L"Windows.Globalization.NumberFormatting.CurrencyFormatter", 56, &header, &string);
ICurrencyFormatterFactory * factory = nullptr;
RoGetActivationFactory(string, __uuidof(factory), reinterpret_cast<void **>(&factory));
 
WindowsCreateStringReference(L"USD", 3, &header, &string);
ICurrencyFormatter * currency = nullptr;
factory->CreateCurrencyFormatterCode(string, &currency);
factory->Release();
 
ICurrencyFormatter2 * currency2 = nullptr;
currency->QueryInterface(&currency2);
currency2->ApplyRoundingForCurrency(RoundingAlgorithm_RoundDown);
currency2->Release();
 
INumberFormatter * formatter = nullptr;
currency->QueryInterface(&formatter);
currency->Release();
 
HSTRING result = nullptr;
formatter->FormatDouble(123.456, &result);
formatter->Release();
 
assert(wcscmp(WindowsGetStringRawBuffer(result, nullptr), L"$123.45") == 0);
WindowsDeleteString(result);

But no C++ developer in his right mind would ever write code like this (and I haven’t even included error handling). Instead the C++ developer would naturally write something like this:

CurrencyFormatter currency(L"USD");
currency.ApplyRoundingForCurrency(RoundingAlgorithm::RoundDown);
 
String result = currency.Format(123.456);
assert(result == L"$123.45");
Re[13]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 12:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>>>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR

I>>>Зато C/С++ есть для JVM
EP>>Покажи нормальный компилятор C++ для JVM.
I>Не следил за вопросом.

А знание про "С++ есть для JVM" тебе внутреизвилинно прямо с Альфа Центавры пришло?

I>Качество генерации байткода у джавы и шарпа вполне нормальное. Основные проблемы с производительностью даёт сам джыт. Какой бы ты наипрекрасный байткод не подсунул, джыт всё равно его опаскудит.


Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
Согласен?
Re[27]: Java vs C# vs C++
От: alex_public  
Дата: 03.10.15 12:42
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>1. Раз всё делается на JS, то тогда причём тут собственно .net?

S> Ну например есть TypeScript. Да и серверную часть тоже нужно писать на Asp.Net mvs писать запросы к базе итд. Клиентская часть далеко не все.

А причём тут TypeScript и .Net? )

_>>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно).

S> А где же высокоскоростной C++?

Он там везде — на нём написаны: сервер (nginx), интерпретатор скриптов (Python), база данных (PostgreSQL/MySQL/SQlite).

_>>Распараллеливание может быть актуально (собственно только в этом направление и есть прогресс в последнее время) для серверных решений. А для всего остального, из выше перечисленного, это абсолютно не актуально.

S> Ну почему. Сейчас все пишется через await, Ajax ы. Это конечно не System.Threading.Tasks.Parallel но ассинхронные вычисления.
S>Но мы то говаорим о вытеснении C++ более медленных платформ.

Причём тут программная часть? ) Я говорю про проблемы быстродействия железа. Они решаемы распараллеливанием только в серверах (и то там не всё так просто). В мобильных устройствах производительность ограничена не процессором, а аккумулятором. А в embedded (частью чего и является новомодный интернет вещей) у нас вообще оперативная память в 64 КБ, в которые jvm/clr даже теоретически не лезут.

_>>Что же касается http-серверов, то это достаточно тривиальная вещь, которую частенько реализуют заново в разных проектах. Более того, есть множество гораздо более сложных вещей, которыми заняты "среднестатистические программисты". К примеру любая современная онлайновая игрушка на порядок сложнее.

S>Ты путаешь сервисы с серверами. Мы говорим об IIS, апаче https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2

Я не путаю))) И нормальный сервер это как раз не апач или IIS, а скажем Nginx. В качестве законченного решения. А подобные же вещи в качестве библиотеки встречаются в разных проектах на каждом шагу. )))

_>>Да, кстати, а авторы того же 1C — они значит с Марса всё же? )))

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

Во многих местах нет возможности выбрать технологию, как раз потому что аналоги слишком жирные/медленные. )))
Re[28]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 13:05
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>

EP>Причем самыми востребованными программистами остаются специалисты, пишущие на «1С» и PHP.


EP>И что? Вывод дальше какой? Эникейщики ещё более востребованы

Где. И ктот такие эникейщики? На каком языке программируют?



S>> Ты меня не читаешь.


EP>Читаю.


S>>Я говорю, что ускоряю скорость отчетов в 100 раз. Все довольны, но иногда прихожу к буху и спрашиваю каким отчетом пользутесь, а они говоря, что по привычке старым. При этом это не доли секунд, а пол часа.


EP>А ещё раз говорю, это один из вариантов. И я не оспариваю то что этот вариант реальный.


S>>>> поскипано. Это все понятно. Я не стал выводить выкладки. Понятно, что факторов очень много.

EP>>>Много, и тормоза отнюдь не двукратные.
S>> Правильно, значительно меньше при правильном написании алгоритма. Все твои примеры это выбор самого плохого подбора алгоритма.

EP>Это уже пошло отрицание реальности. Все мои примеры вообще алгоритм не меняют. Меняют уровень абстракции.

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

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

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

EP>Если вместо ручной склейки умножения массивов и операции умножения элементов мы реализуем их по отдельности, а склейку делает сам компилятор — это не замена алгоритма.
EP>И т.д. и т.п.
Опять же это сейчас для компилятора главное не скорость, а безопасность. В свое время VladD2 еще на видби показывал пример где в качестве компаратора выступала структура и методы инлайнились.



S>>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало.

S>>Не все так однозначно.

EP>А обход графа это бесплатно что-ли?

EP>Ты видимо слышал про сдвиг указателя, но приплёл его абсолютно не к месту. Тот самый сдвиг указателя, о котором часто вспоминают, происходит при выделении памяти из первого поколения, а не при сборки мусора. При сборки происходит обход графа живых объектов, с их копированием (зависит от реализации).
Есть разные стратегии. И если граф достижимых объектов очень мал, то это значительно эффективнее Delete. По сути это как структуры на стеке.
Проблемы возникают когда граф большой и есть изменения в старших поколениях. Но в большинстве случаев мало отличается от размещения структур на стеке.




S>>Если таких специалистов оочень мало, то будут побеждать те языки где сложность входа значительно меньше.


EP>Побеждать в чём? В задачах неприхотливых ни к скорости, ни к потреблению энергии, ни к потреблению памяти? Да, конечно будут.

Побеждать в тендере на разработку.

S>>Как ты думаешь, что проще для изучения 1С++ или 1С?


EP>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще.

А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++



S>>>> В итоге все зависит от компилятора. Например TS тоже транслируется в JS и ничто не мешает транслировать в более оптимальный. Здесь проблема не языков а компиляторов которые совершенствуются.

EP>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.
S>> В C# еще больше.

EP>Ещё больше чего? Бесплатных высокоуровневых абстракций?


S>>Посмотри на тот же Code First и Linq.


EP>Это C# Linq бесплатный?

Значительно меньше, чем ожидание запроса к БД. И оочень удобный в применении.
EP>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.
Ну дык в C# то он уже лет 7. Отстаете.

S>>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.


EP>Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке.

Автоматом их не сделать это же Idispath без typeInfo. Но можно вручную написать диспинтерфейсы.


S>>>> Вывод в том, что существование тех или иных языков или платформ вызвано не только скоростью выполнения

EP>>>В целом да, а в частности нет. Например сделали язык заточенный под скорость, потому что нужна скорость — вопрос, чем вызвано его существование?
S>> Тем, что у него есть своя ниша. А вот какова емкость этой ниши?

EP>Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да.

EP>Дальше что? Ты можешь сразу сказать к чему ты подводить?

И спросила Нина тихо:
— Разве плохо быть портнихой?
Кто трусы ребятам шьёт?
Ну конечно, не пилот.
Лётчик водит самолёты —
Это очень хорошо.
Повар делает компоты —
Это тоже хорошо.
Доктор лечит нас от кори,
Есть учительница в школе.
Мамы разные нужны.
Мамы всякие важны.
Дело было вечером,
Спорить было нечего.


S>>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит

EP>>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?
S>> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С

EP>И??? Вывод какой?!

Смотри выше. Если скорость будет во главе угла то будут 2 сценария
1. Оптимизация JIT компилятора. Что и сейчас происходит RyuJIT
2. Платят больше, есть вакансии, значит будут переходить на C++
и солнце б утром не вставало, когда бы не было меня
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 13:43
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>

EP>>Причем самыми востребованными программистами остаются специалисты, пишущие на «1С» и PHP.

EP>>И что? Вывод дальше какой? Эникейщики ещё более востребованы
S> Где. И ктот такие эникейщики? На каком языке программируют?

https://en.wikipedia.org/wiki/Any_key
https://ru.wiktionary.org/wiki/%D1%8D%D0%BD%D0%B8%D0%BA%D0%B5%D0%B9%D1%89%D0%B8%D0%BA

S>>> Правильно, значительно меньше при правильном написании алгоритма. Все твои примеры это выбор самого плохого подбора алгоритма.

EP>>Это уже пошло отрицание реальности. Все мои примеры вообще алгоритм не меняют. Меняют уровень абстракции.
EP>>Если добавили замыкание и ФВП, и в результате чего получили многократные тормоза и отжоры памяти — это не замена алгоритма, это использование более высокоуровневых средств.
S> Где? У тебя только два примера это векторизация и тормоза лямбд в неизвестно в каком алгоритме.

Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса.
А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
Автор: Evgeny.Panasyuk
Дата: 27.09.15
.

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

EP>>Если вместо ручной склейки умножения массивов и операции умножения элементов мы реализуем их по отдельности, а склейку делает сам компилятор — это не замена алгоритма.
EP>>И т.д. и т.п.
S> Опять же это сейчас для компилятора главное не скорость, а безопасность.

Как это относится к контексту? Ты говоришь что я меняю алгоритм, я тебе разъясняю что нет. Ты в ответ отвечаешь "сейчас для компилятора главное не скорость, а безопасность" — где логика

S>>>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало.

S>>>Не все так однозначно.
EP>>А обход графа это бесплатно что-ли?
EP>>Ты видимо слышал про сдвиг указателя, но приплёл его абсолютно не к месту. Тот самый сдвиг указателя, о котором часто вспоминают, происходит при выделении памяти из первого поколения, а не при сборки мусора. При сборки происходит обход графа живых объектов, с их копированием (зависит от реализации).
S> Есть разные стратегии.

В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?
Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.

S>И если граф достижимых объектов очень мал, то это значительно эффективнее Delete.


Какого конкретно Delete?

S>>>Как ты думаешь, что проще для изучения 1С++ или 1С?

EP>>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще.
S> А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++

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

EP>>>>Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S>>> В C# еще больше.
EP>>Ещё больше чего? Бесплатных высокоуровневых абстракций?
S>>>Посмотри на тот же Code First и Linq.
EP>>Это C# Linq бесплатный?
S> Значительно меньше, чем ожидание запроса к БД. И оочень удобный в применении.

Тут где-то рассказывали что упирались во вполне реальные тормоза Linq, так что причислять его к "бесплатным высокоуровневым абстракциям" — в корне не верно

EP>>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.

S> Ну дык в C# то он уже лет 7. Отстаете.

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

S>>>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

EP>>Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке.
S> Автоматом их не сделать это же Idispath без typeInfo.

И что? Схема же есть где-то?
Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?

S>>> Тем, что у него есть своя ниша. А вот какова емкость этой ниши?

EP>>Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да.
EP>>Дальше что? Ты можешь сразу сказать к чему ты подводить?
S>

S> И спросила Нина тихо:
S> — Разве плохо быть портнихой?
S> Кто трусы ребятам шьёт?


Ваганович?

S>>>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит

EP>>>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?
S>>> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С
EP>>И??? Вывод какой?!
S>Смотри выше.

Где? В одном сообщении было "смотри ниже", но вывода не было, сейчас "смотри выше"

S>Если скорость будет во главе угла то будут 2 сценария

S>1. Оптимизация JIT компилятора. Что и сейчас происходит RyuJIT

Ещё раз, дело не только в оптимизаторах, а ещё во многом и в языках. Когда происходит вызов лямбды на C++ — компилятор уже видит без всяких оптимизаций какой конкретно код вызывается — чисто по построению кода, и может его заинлайнить
Прямая аналогия: код на языках с динамической типизацией намного труднее оптимизировать до одного уровня кода со статической типизацией.
Re[28]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 13:44
Оценка:
Здравствуйте, PM, Вы писали:

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


EP>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

PM>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.

С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.
и солнце б утром не вставало, когда бы не было меня
Re[11]: Java vs C# vs C+
От: PM  
Дата: 03.10.15 13:50
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR


I>Зато C/С++ есть для JVM и .Net и шота не видно никаких чудес. Джава и шарп рвут всё на своих платформах. Как то так.


Моё Google-fu дало только NestedVM:

News

2009-08-09: New snapshot posted

2009-06-07: New snapshot posted, move to git

2009-01-03: New snapshot posted

2007-01-12: Support for fsync()

2006-12-16: Now using GCC 3.3.6 to compile out of the box on Ubuntu 6.10

Download

Note that NestedVM uses GCC 3.3.6, which will not compile under GCC 4.1 or later.


Ещё одна картинка <троллейбус из буханки хлеба.jpeg>

Только тролль или эльф может утверждать, что программы в управляемых средах будут выигрывать у native. Сказкам про победную поступь JIT исполнилось уже 20 лет

Ну а кто там в песочнице быстрее между собой Java или Scala, C# или Nemerle это как то выходит за пределы темы.

PM>>Почитайте на досуге как авторы LMAX героически боролись


I>Неинтересно, это разница в платформах.


Как-то быстро вы слились
Re[28]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 13:59
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>1. Раз всё делается на JS, то тогда причём тут собственно .net?

S>> Ну например есть TypeScript. Да и серверную часть тоже нужно писать на Asp.Net mvs писать запросы к базе итд. Клиентская часть далеко не все.

_>А причём тут TypeScript и .Net? )


Как это причем? TypeScript в ASP.NET MVC



_>>>2. Такая схема уже много лет как используется во всех остальных языках. Например у нас сайты работают именно так, только на сервере при этом отвечает на ajax запросы Питон (и без всякого asp естественно).

S>> А где же высокоскоростной C++?

_>Он там везде — на нём написаны: сервер (nginx), интерпретатор скриптов (Python), база данных (PostgreSQL/MySQL/SQlite).

То есть в итоге то ты пишешь на питоне, а не на С++. Мы уже про это говорили, что ниша С++ там где нужна скорость. А там где скорость разработки ты же сам используешь питон.



_>Причём тут программная часть? ) Я говорю про проблемы быстродействия железа. Они решаемы распараллеливанием только в серверах (и то там не всё так просто). В мобильных устройствах производительность ограничена не процессором, а аккумулятором. А в embedded (частью чего и является новомодный интернет вещей) у нас вообще оперативная память в 64 КБ, в которые jvm/clr даже теоретически не лезут.

Вот еще одна ниша для С++

_>>>Что же касается http-серверов, то это достаточно тривиальная вещь, которую частенько реализуют заново в разных проектах. Более того, есть множество гораздо более сложных вещей, которыми заняты "среднестатистические программисты". К примеру любая современная онлайновая игрушка на порядок сложнее.

S>>Ты путаешь сервисы с серверами. Мы говорим об IIS, апаче https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%B2

_>Я не путаю))) И нормальный сервер это как раз не апач или IIS, а скажем Nginx. В качестве законченного решения. А подобные же вещи в качестве библиотеки встречаются в разных проектах на каждом шагу. )))



_>>>Да, кстати, а авторы того же 1C — они значит с Марса всё же? )))

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

_>Во многих местах нет возможности выбрать технологию, как раз потому что аналоги слишком жирные/медленные. )))

Ну и какова емкость этой ниши?
Я не против С++. Я про то, что он не универсален, как тут пытаются заявить. И что скорость в большинстве случаев не является главным критерием, даже во времена когда память в 64 КБ была естественным делом. Помню писал на паскале на ДВК 2 и время компиляции было полчаса. В то же время на Бейсике пусть и с огромными тормозами, но не было задержек с компиляцией. И большинство использовало бейсик
и солнце б утром не вставало, когда бы не было меня
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 14:09
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S>>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

PM>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.

S> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.

Опиши конкретный use-case.
Если нужно вызвать метод с произвольным именем (method) и произвольным количеством аргументов (a1, a2, ...), без всякого предварительного описания — то можно например вот так:
Dynamic x = ...;

x.call("method", a1, a2, ...);
// or
x("method", a1, a2, ...);
// or
x > "method"_(a1, a2, ...);
А если заранее описать список возможных имён методов, то можно и так:
x.method(a1, a2, ...)
Отредактировано 03.10.2015 14:19 Evgeny.Panasyuk . Предыдущая версия .
Re[29]: Java vs C# vs C++
От: PM  
Дата: 03.10.15 14:14
Оценка: +1
Здравствуйте, Serginio1, Вы писали:


PM>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.

S> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.

Ну dynamic ведь тоже не по волшебству работает. Какие сложности получать у IDispatch нужную информацию и вызывать Invoke? В 2007 это не было проблемой: http://www.codeproject.com/Articles/19962/Driving-Microsoft-Word-using-VOLE
Re[30]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 14:19
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:



S>> Где? У тебя только два примера это векторизация и тормоза лямбд в неизвестно в каком алгоритме.


EP>Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса.

EP>А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
Автор: Evgeny.Panasyuk
Дата: 27.09.15
.

Сколько многократные. Результаты сравнения пожалуйста. Максимум там в 2 раза. Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Автор: greenpci
Дата: 05.06.15

Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.

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

EP>>>Если вместо ручной склейки умножения массивов и операции умножения элементов мы реализуем их по отдельности, а склейку делает сам компилятор — это не замена алгоритма.
EP>>>И т.д. и т.п.
S>> Опять же это сейчас для компилятора главное не скорость, а безопасность.

EP>Как это относится к контексту? Ты говоришь что я меняю алгоритм, я тебе разъясняю что нет. Ты в ответ отвечаешь "сейчас для компилятора главное не скорость, а безопасность" — где логика


S>>>>В большинстве случаев сбор мусора, это просто сдвиг указателя конца кучи на начало.

S>>>>Не все так однозначно.
EP>>>А обход графа это бесплатно что-ли?
EP>>>Ты видимо слышал про сдвиг указателя, но приплёл его абсолютно не к месту. Тот самый сдвиг указателя, о котором часто вспоминают, происходит при выделении памяти из первого поколения, а не при сборки мусора. При сборки происходит обход графа живых объектов, с их копированием (зависит от реализации).
S>> Есть разные стратегии.

EP>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?

EP>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.

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

S>>И если граф достижимых объектов очень мал, то это значительно эффективнее Delete.


EP>Какого конкретно Delete?


Это зависит от менеджера памяти. У вас же там зоопарк.

S>>>>Как ты думаешь, что проще для изучения 1С++ или 1С?

EP>>>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще.
S>> А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++

EP>Водители для себя решают ту же задачу что и программисты — зарабатывание денег, именно на эту задачу ты здесь постоянно переключаешься.

То есть водители конкурируют с программистами ? Странное у тебя видение.



EP>>>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.

S>> Ну дык в C# то он уже лет 7. Отстаете.

EP>Ты путаешь "можно реализовать" и "он нужен многим, все его с нетерпением ждут".


В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю

S>>>>Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

EP>>>Если кто-то постоянно пишет низкоуровневый interop, не сделав ни обёрток, или даже не сгенерировав их автоматом — то это ССЗБ в чистом виде, они есть на каждом языке.
S>> Автоматом их не сделать это же Idispath без typeInfo.

EP>И что? Схема же есть где-то?

EP>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики. Я в свое время для Delphi реализовывал Idispath для ускорения и типизации. Был таким же как и ты, пока не понял, что большинству на скорость наплевать.

S>>>> Тем, что у него есть своя ниша. А вот какова емкость этой ниши?

EP>>>Да, для каждого языка есть своя ниша, отчасти они пересекаются. Ёмкости ниш разные, да.
EP>>>Дальше что? Ты можешь сразу сказать к чему ты подводить?
S>>

S>> И спросила Нина тихо:
S>> — Разве плохо быть портнихой?
S>> Кто трусы ребятам шьёт?


EP>Ваганович?


S>>>>>>А количество специалистов зависит от сложности выполнения той или иной задачи и зарплаты за её выполнение. И так по кругу. Рынок рулит

EP>>>>>Дальше что? Это накладывает вето на любое сравнение скорости на разных языках?
S>>>> Это ничего не наклавдывает. Эволюция говорит о том есть борьба и единство противоположностей. Нужна конкуренция и из неё рождаются новые языки и платформы. Именно по этому развивается С++,С#,Java питон и 1С
EP>>>И??? Вывод какой?!
S>>Смотри выше.

EP>Где? В одном сообщении было "смотри ниже", но вывода не было, сейчас "смотри выше"

Кто трусы ребятам шьёт?

S>>Если скорость будет во главе угла то будут 2 сценария
S>>1. Оптимизация JIT компилятора. Что и сейчас происходит RyuJIT

EP>Ещё раз, дело не только в оптимизаторах, а ещё во многом и в языках. Когда происходит вызов лямбды на C++ — компилятор уже видит без всяких оптимизаций какой конкретно код вызывается — чисто по построению кода, и может его заинлайнить

EP>Прямая аналогия: код на языках с динамической типизацией намного труднее оптимизировать до одного уровня кода со статической типизацией.

Это же может видеть как компилятор в MSIL так и в машинный код. Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные
http://infostart.ru/public/402433/

Просто пока это не нужно.
и солнце б утром не вставало, когда бы не было меня
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 14:41
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса.

EP>>А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
Автор: Evgeny.Panasyuk
Дата: 27.09.15
.

S> Сколько многократные. Результаты сравнения пожалуйста. Максимум там в 2 раза.

* В два раза это только один пример, и то там C++ внутри JS.
* Был пример про замыкание
Автор: Evgeny.Panasyuk
Дата: 23.12.14
— там разница больше чем 10x.
* Приводил несколько примеров показывающих что даёт замена на ссылочную структуру (которые дефолтные в управляемых средах) — там было 80x и 200x.

S>Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Автор: greenpci
Дата: 05.06.15


Здесь в C++ варианте лямбда, ФВП и итераторы, а в C# варианте обычный рукопашный цикл

S>Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.


Хочешь отрицать реальность, не хочешь видеть примеры? Твоё право, но мне уже надоедает по несколько раз приводить одни и те же примеры.

EP>>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?

EP>>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.
S> Старшие поколения не используются для анализа. Используются только изменения если изменений не было, значит нет достижимых объектов, значит можно передвинуть указатель кучи на начало.

Указатель какой именно кучи на начало? Какого поколения?

S>>>И если граф достижимых объектов очень мал, то это значительно эффективнее Delete.

EP>>Какого конкретно Delete?
S>Это зависит от менеджера памяти. У вас же там зоопарк.

Разных GC и их настроек тоже зоопарк, а также целый зоопарк всяких off heap решений, возникших не от праздного интереса.

S>>>>>Как ты думаешь, что проще для изучения 1С++ или 1С?

EP>>>>Я 1С не знаю, но предполагаю что порог вхождения ниже. А стать водителем ещё проще.
S>>> А разве водители программисты? 1C это платформа и язык программирования и решает те же задачи, которые можно решать и на С++
EP>>Водители для себя решают ту же задачу что и программисты — зарабатывание денег, именно на эту задачу ты здесь постоянно переключаешься.
S> То есть водители конкурируют с программистами ? Странное у тебя видение.

Причём тут конкуренция? Глобально задача у каждого программиста заработать денег (не считая for fun и т.п.), себе лично, а не конкурировать с кем-то. Ты же в это русло переводишь

EP>>>>Аналог Linq-а кстати возможен и в C++, причём бесплатный — то есть строковые запросы будут формироваться автоматически на этапе компиляции Недавно как раз была подобная тема, с конкретными примерами — если интересно могу найти ссылку.

S>>> Ну дык в C# то он уже лет 7. Отстаете.
EP>>Ты путаешь "можно реализовать" и "он нужен многим, все его с нетерпением ждут".
S> В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю

Конкретно где везде? Для каких задач?

EP>>И что? Схема же есть где-то?

EP>>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
S> Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики.

Не реализуй, используй так — получишь меньше гарантий в compile-time. При этом не обязательно плодить гору boiler-plate, пример в соседнем сообщении.

S> Я в свое время для Delphi реализовывал Idispath для ускорения и типизации. Был таким же как и ты, пока не понял, что большинству на скорость наплевать.


Каким таким? Ты делаешь какие-то неверные предположения.

S>Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные


Опиши в двух словах что конкретно имеешь в виду.
Re[12]: Java vs C# vs C+
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 19:31
Оценка:
Здравствуйте, PM, Вы писали:


PM>Только тролль или эльф может утверждать, что программы в управляемых средах будут выигрывать у native. Сказкам про победную


Где ты видишь, что я пишу "управляемые среды выиграют у нативных" ?

Написано прямо противоположное: "Джава и шарп рвут всё на ____своих____ платформах."

Так что да, буквы не читай.
Re[14]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 19:32
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.

EP>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
EP>Согласен?

Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким
Re[15]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 19:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Качество генерации байткода у джавы и шарпа вполне нормальное. Основные проблемы с производительностью даёт сам джыт. Какой бы ты наипрекрасный байткод не подсунул, джыт всё равно его опаскудит.

EP>>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
EP>>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
EP>>Согласен?
I>Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким

А какой из них какой?
Ты же выше говоришь что основные проблемы от JIT'а, а байткод нормальный? Вот и сравним
Re[10]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 19:41
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>1 Вроде как очевидно, что здесь разные платформы. Попробуй тот же мега-с++ код скомпилировать в дотнет и открой для себя страшное — скорость сильно вряд ли будет отличаться от C#.


EP>Не верно. Низкоуровневый C# быстрее в разы высокоуровневого C# в пределах .NET, потому что язык такой — абстракции дорогие.


Ну вот возьми С++ под дотнет да покажи эти "в разы"

EP>Высокоуровневый код C++ и ручной низкоуровневый аналог даёт зачастую идентичный машинный код, в этом и есть фишка.


"Зачастую" это слишком мутный термин, что бы рассматривать его как аргумент.

EP>В C# скомпилированном в JavaScript точно также как и на .NET не будет заинлайненной лямбды, и от этого точно также будут тормоза.


C# это язык ровно одной платформы. Хочешь сравнить __языки__ — компилируй С++ под дотнет. В противном случае получается или сравнение плохого с хорошим, или сравнение платформ.

Например, инлайн функции в дотнете принято перекладывать на джыт. Отсюда и подсказки джыту — [MethodImpl(MethodImplOptions.AggressiveInlining)]
Re[16]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.15 19:45
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким


EP>А какой из них какой?

EP>Ты же выше говоришь что основные проблемы от JIT'а, а байткод нормальный? Вот и сравним

Сравнивать нужно с С++ под JVM, что бы все были в равных условиях.
Re[11]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 19:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>Высокоуровневый код C++ и ручной низкоуровневый аналог даёт зачастую идентичный машинный код, в этом и есть фишка.

I>"Зачастую" это слишком мутный термин, что бы рассматривать его как аргумент.

Я неоднократно сравнивал ручные аналоги коду с абстракциями, например: 1
Автор: Evgeny.Panasyuk
Дата: 12.10.14
, 2, 3
Автор: Evgeny.Panasyuk
Дата: 23.12.14
— ассемблерный код получался идентичным. Да и вообще часто смотрю во что там скомпилировался код.

I>Например, инлайн функции в дотнете принято перекладывать на джыт. Отсюда и подсказки джыту — [MethodImpl(MethodImplOptions.AggressiveInlining)]


Неважно кто делает инлайн. На C++ его сделать проще из-за свойств самого языка.
Re[17]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 19:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Пудозреваю, ты хочешь сравнить заведомо плохой компилер со средненьким

EP>>А какой из них какой?
EP>>Ты же выше говоришь что основные проблемы от JIT'а, а байткод нормальный? Вот и сравним
I>Сравнивать нужно с С++ под JVM, что бы все были в равных условиях.

А я что предлагаю? Не, ну действительно "буквы не читай, сообщения пиши"

EP>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
EP>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
EP>Согласен?

Re[30]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 20:08
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S>>>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

PM>>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.

S>> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.

EP>Опиши конкретный use-case.

http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=614821&amp;threadtype=0&amp;print=1&amp;partt614821=1
EP>Если нужно вызвать метод с произвольным именем (method) и произвольным количеством аргументов (a1, a2, ...), без всякого предварительного описания — то можно например вот так:
EP>
EP>Dynamic x = ...;

EP>x.call("method", a1, a2, ...);
EP>// or
EP>x("method", a1, a2, ...);
EP>// or
EP>x > "method"_(a1, a2, ...);
EP>
А если заранее описать список возможных имён методов, то можно и так:

EP>
EP>x.method(a1, a2, ...)
EP>


Но согласись все равно убожество. Читать такой код неудобно.
На C# Сделать прокси легко. Вот например как обернуть в Idispatch любой объект .Net
http://infostart.ru/public/238584/

Есть DynamicObject, expandoobject все очень красиво

Кстати про инлайн
http://stackoverflow.com/questions/23374815/creating-inline-functions-and-macros
http://aakinshin.net/ru/blog/dotnet/inlining-and-starg/
и солнце б утром не вставало, когда бы не было меня
Re[30]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 20:15
Оценка:
Здравствуйте, PM, Вы писали:

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



PM>>>Не в первый раз наблюдаю, что при сравнении С++ с другими, более поздними языками, люди активно не использующие С++ приводят примеры кода 10-15 летней давности (MFC, COM). Причем уже в то время в Visual C++ была средства для нормальной работы с COM (ATL, #import, позже _com_ptr_t) которые позволяли писать код без многоэтажных if(SUCCEEDED()) AddRef/Release.

S>> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.

PM>Ну dynamic ведь тоже не по волшебству работает. Какие сложности получать у IDispatch нужную информацию и вызывать Invoke? В 2007 это не было проблемой: http://www.codeproject.com/Articles/19962/Driving-Microsoft-Word-using-VOLE


Но убожество даже в этом виде.
Ничего по волшебству не работает. Однако в Бейсик,Delphi 1С и наконец в C# очень удобно работать с голым Idispatch. При этом удобно переводить с одного языка в другой http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=614821&amp;amp;threadtype=0&amp;amp;print=1&amp;amp;partt614821=1

Согласен, что сделать прокси не проблема. Сам их пишу, но почти все С++ работающих с 1С что я видел работают в рукопашную. Это кстати о квалификации.
и солнце б утром не вставало, когда бы не было меня
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 20:39
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Если нужно вызвать метод с произвольным именем (method) и произвольным количеством аргументов (a1, a2, ...), без всякого предварительного описания — то можно например вот так:

EP>>
EP>>Dynamic x = ...;

EP>>x.call("method", a1, a2, ...);
EP>>// or
EP>>x("method", a1, a2, ...);
EP>>// or
EP>>x > "method"_(a1, a2, ...);
EP>>
А если заранее описать список возможных имён методов, то можно и так:

EP>>
EP>>x.method(a1, a2, ...)
EP>>

S> Но согласись все равно убожество. Читать такой код неудобно.

Немного непривычно — да, возможно. Но не убожество точно. Тем более перечислив имена один раз получаем x.method(a1, a2, ...)
Да и ты разве про это изначально говорил?

S>На C# Сделать прокси легко. Вот например как обернуть в Idispatch любой объект .Net

S>http://infostart.ru/public/238584/

Использовать C++ из Python/Java/C# тоже легко — смотри SWIG. Или например Boost.Python.

S> Кстати про инлайн

S>http://stackoverflow.com/questions/23374815/creating-inline-functions-and-macros
S>http://aakinshin.net/ru/blog/dotnet/inlining-and-starg/

Инлайнинг обычного вызова не особо интересно. Покажи инлайнинг например для замыкания внутри ФВП.
Отредактировано 03.10.2015 20:42 Evgeny.Panasyuk . Предыдущая версия . Еще …
Отредактировано 03.10.2015 20:40 Evgeny.Panasyuk . Предыдущая версия .
Re[32]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 20:42
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Приехали, у меня не было ни одного примера на векторизацию. Я даже явно сказал, что я в своём тезисе векторизацию не учитываю, ибо это удар ниже пояса.

EP>>>А примеры по ссылкам которые я приводил, там и исходный код, и сгенерированный и т.д. и т.п. Например вот тут
Автор: Evgeny.Panasyuk
Дата: 27.09.15
.

S>> Сколько многократные. Результаты сравнения пожалуйста. Максимум там в 2 раза.

EP>* В два раза это только один пример, и то там C++ внутри JS.

EP>* Был пример про замыкание
Автор: Evgeny.Panasyuk
Дата: 23.12.14
— там разница больше чем 10x.

EP>* Приводил несколько примеров показывающих что даёт замена на ссылочную структуру (которые дефолтные в управляемых средах) — там было 80x и 200x.

S>>Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Автор: greenpci
Дата: 05.06.15


EP>Здесь в C++ варианте лямбда, ФВП и итераторы, а в C# варианте обычный рукопашный цикл

Угу при этом Complex свой вместо https://msdn.microsoft.com/ru-ru/library/system.numerics.complex(v=vs.110).aspx


S>>Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.


EP>Хочешь отрицать реальность, не хочешь видеть примеры? Твоё право, но мне уже надоедает по несколько раз приводить одни и те же примеры.

Так не вижу тестов то.

EP>>>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?

EP>>>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.
S>> Старшие поколения не используются для анализа. Используются только изменения если изменений не было, значит нет достижимых объектов, значит можно передвинуть указатель кучи на начало.

EP>Указатель какой именно кучи на начало? Какого поколения?

Нулевого.


EP>Разных GC и их настроек тоже зоопарк, а также целый зоопарк всяких off heap решений, возникших не от праздного интереса.

Каких именно. Я никаких настроек GC не трогаю.

EP>Причём тут конкуренция? Глобально задача у каждого программиста заработать денег (не считая for fun и т.п.), себе лично, а не конкурировать с кем-то. Ты же в это русло переводишь


Ну у тебя совсем плохо с головой, раз ты мешаешь программистов и водителей в одну кучу.
Напомню тебе, что в 90 х основными программистами были С и С++. К ним добавлялись фокспрошники дибейсники бейсики и паскалиты дельфисты.
Ни Java C# ну и конечно 1C не было и в помине. По мере доступности компьютеров нужны были специалисты коих не хватало как для бухгалтерских задач, так и с ростом интернета писателей сайтов итд. Стало понятно, что С++ сложен, а нужны были программисты сейчас в том числе студенты и тд. Стали появляться программы типа 1С, ПХП, ну и Java C#. Кстати многие С++ доказывавших на этом форуме с пеной у рта каков крутой С++ в итоге перешли на C#, Немерле итд.
Многие из них не ездят на машине.


S>> В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю


EP>Конкретно где везде? Для каких задач?

Там где есть коллекции, для доступа к БД
EP>>>И что? Схема же есть где-то?
EP>>>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
S>> Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики.

S>>Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные


EP>Опиши в двух словах что конкретно имеешь в виду.

Я же тебе ссылочку давал http://infostart.ru/public/402433/ там куча ссылок. В двух словах тяжело объяснять.

Так же в Linq можно склеивать запросы, накладывая новые ограничения. Это связано с ленивостью запросов



// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа



            var query = from Константа in бд.ТаблицаКонстанты

                        where Константа.ID == 9697

                        orderby Константа.DATE descending, Константа.TIME descending, Константа.DOCID descending, Константа.ROW_ID descending

                        select Константа;





// Используем query в другом запросе добавив к на нему условия на элемент владелец и дату равную или меньше значение реквизита элемента справочника. В итоге получаем последнее значение и дату периодического элемента на дату заданную в реквизите элемента справочника.




            var query2 = (from спр in бд.Спр_ДляПериодических

                          selectnew

                          {

                              Наименование = спр.Наименование,

                              ДатаСпр = спр.ДатаСпр,

                              Периодические = (from прериод in query.Where(х => х.OBJID == спр.ID && х.DATE <= спр.ДатаСпр).Take(1)

                                               select  new

                                               {

                                                   Значение = прериод.VALUE,

                                                   Дата = прериод.DATE

 

                                               }).FirstOrDefault()

 

                          }

                             );






Например, можно также и расширять условия
http://www.albahari.com/nutshell/predicatebuilder.aspx
https://github.com/scottksmith95/LINQKit

Можно, например, написать условие по OR
Можно написать обобщенную функцию



  public  IQueryable<TEntity> НайтиПоВхождениюВНаименование<TEntity>(paramsstring[] keywords) where TEntity : СправочникПредок

        {

            var predicate = PredicateBuilder.False<TEntity>();

 

            foreach (string keyword in keywords)

            {

                string temp = keyword;

                predicate = predicate.Or(p => p.Наименование.Contains(temp));

            }

            returnthis.Set<TEntity>().AsExpandable().Where(predicate);

        }






И использовать



var бд = Константы1С.ГлобальныйКонтекст.БД;

 

            var запрос = бд.НайтиПоВхождениюВНаименование<Справочник.Номенклатура>("Linq", "Наше", "Все").Select(товар => товар.Наименование);

 

            foreach (varтоварinзапрос)

            {

 

                Console.WriteLine("{0} ", товар);

 

            }


Генерируется следующий запрос


SELECT

    [Extent1].[DESCR] AS [DESCR]

    FROM [dbo].[SC84] AS [Extent1]

 

    WHERE ([Extent1].[DESCR] LIKE @p__linq__0 ESCAPE N'~') 

          OR([Extent1].[DESCR] LIKE @p__linq__1 ESCAPE N'~') 

          OR([Extent1].[DESCR] LIKE @p__linq__2 ESCAPE N'~')
и солнце б утром не вставало, когда бы не было меня
Re[32]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 20:51
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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



EP>Немного непривычно — да, возможно. Но не убожество точно. Тем более перечислив имена один раз получаем x.method(a1, a2, ...)

EP>Да и ты разве про это изначально говорил?

S>>На C# Сделать прокси легко. Вот например как обернуть в Idispatch любой объект .Net

S>>http://infostart.ru/public/238584/

EP>Использовать C++ из Python/Java/C# тоже легко — смотри SWIG. Или например Boost.Python.

В С# только статические методы и то с шаманством. А из 1С вообще никак.
S>> Кстати про инлайн
S>>http://stackoverflow.com/questions/23374815/creating-inline-functions-and-macros
S>>http://aakinshin.net/ru/blog/dotnet/inlining-and-starg/

EP>Инлайнинг обычного вызова не особо интересно. Покажи инлайнинг например для замыкания внутри ФВП.


Если ты хочешь скорость, то зачем же тебе замыкания? Замыкания это класс который генерится при компиляции.
Если мне нужна скорость, то я сам создам класс и помечу функцию для инлайна. А то видители Dynamic не убожество, а класс это уже фи подавай им замыкания.
Я буду выбирать, то что считаю нужным. Но в большинстве случаев я выбеоу замыкания наплевав на производительнось. Инлайнинг это еще и раздувание кода.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.10.2015 20:58 Serginio1 . Предыдущая версия .
Re[27]: Java vs C# vs C++
От: alex_public  
Дата: 03.10.15 20:55
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

А какая связь между Linq и COM? ))) И в чём смысл вообще сравнивать языковую конструкцию и некую технологию, вообще не зависящую от языка? )
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 03.10.15 20:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Ну и ещё не забываем про то, что у главных компиляторов C++ в данным момент мощнейшие в мире оптимизаторы.

I>Только что сам сказал 'язык ни при чем,платформа при чем' и теперь оказывыется, что язык таки наше всё ?

Не язык, а оптимизаторы в конкретных компиляторах для него. ) Ну и как раз было указано, что это совсем не "наше всё", а где-то двукратное увеличение быстродействия (из суммарного десятикратного).

I>Определись. ПОчему не видно никаких чудес у С/С++ на платформе джава или дотнет ?


Потому что там этих оптимизаторов просто нет. )
Re[28]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.10.15 21:01
Оценка:
Здравствуйте, alex_public, Вы писали:

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


EP>>>Как раз таки проблема в языках, об этом и речь. Высокоуровневый C++ быстрый отнюдь не только потому что для него оптимизаторы лучше, а во многом потому что в самом языке есть бесплатные, или практически бесплатные абстракции и высокоуровневые инструменты.

S>> В C# еще больше. Посмотри на тот же Code First и Linq. Я без слез не могу смотреть на код С++ которые через COM вызывают 1С работая с Idispatch.

_>А какая связь между Linq и COM? ))) И в чём смысл вообще сравнивать языковую конструкцию и некую технологию, вообще не зависящую от языка? )

Он говорил про абстракции. А связь между линк и ком это создание прокси
и солнце б утром не вставало, когда бы не было меня
Re[29]: Java vs C# vs C++
От: alex_public  
Дата: 03.10.15 21:13
Оценка: +2
Здравствуйте, Serginio1, Вы писали:

_>>А причём тут TypeScript и .Net? )

S> Как это причем? TypeScript в ASP.NET MVC

То, что TypeScript можно применять вместо с .net (как впрочем и C++ и Python) совершенно не делает .net необходимым для использования TypeScript.

_>>Он там везде — на нём написаны: сервер (nginx), интерпретатор скриптов (Python), база данных (PostgreSQL/MySQL/SQlite).

S> То есть в итоге то ты пишешь на питоне, а не на С++. Мы уже про это говорили, что ниша С++ там где нужна скорость. А там где скорость разработки ты же сам используешь питон.

Просто питоновский код в такой задаче не занят никакими серьёзными вещами, а банально играет роль системного клея между блоками кода (кстати, написанными на C/C++), исполняющими основную работу.

Я вот могу ещё один очень известный пример привести на похожую тему. Питон сейчас очень популярен в научной среде. Причём не только для написания скриптов (что логично), но и для сложных и тяжёлых вычислений. Казалось бы нонсенс, но секрет раскрывается просто — для таких дел используются специальные библиотеки (типа numpy), которые написаны опять же на C/C++. В итоге получаем сочетания максимального быстрого написания кода с одновременной неплохой производительностью.

_>>Во многих местах нет возможности выбрать технологию, как раз потому что аналоги слишком жирные/медленные. )))

S> Ну и какова емкость этой ниши?

Так ниша то не одна, а таких много разных. ) В итоге язык C по разным рейтингам уже много лет держится на одном уровне популярности с Java. А если добавить к нему ещё C++, то является самым популярным с большим отрывом.

S> Я не против С++. Я про то, что он не универсален, как тут пытаются заявить. И что скорость в большинстве случаев не является главным критерием, даже во времена когда память в 64 КБ была естественным делом. Помню писал на паскале на ДВК 2 и время компиляции было полчаса. В то же время на Бейсике пусть и с огромными тормозами, но не было задержек с компиляцией. И большинство использовало бейсик


Скорость является главным критерием в ряде ниш. Но это действительно не единственный критерий, по которому выбирают C/C++. В других нишах его выбирают за другие преимущества. Ну а в некоторых нишах (типа тех же скриптов например) не выбирают вовсе. )))
Re[29]: Java vs C# vs C++
От: alex_public  
Дата: 03.10.15 21:15
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>А какая связь между Linq и COM? ))) И в чём смысл вообще сравнивать языковую конструкцию и некую технологию, вообще не зависящую от языка? )

S> Он говорил про абстракции. А связь между линк и ком это создание прокси

Ну вот Linq ещё тянет на языковую абстракцию. А причём тут COM вообще? ) И что ещё за прокси в linq? )
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 21:23
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Автор: greenpci
Дата: 05.06.15

EP>>Здесь в C++ варианте лямбда, ФВП и итераторы, а в C# варианте обычный рукопашный цикл
S> Угу при этом Complex свой вместо https://msdn.microsoft.com/ru-ru/library/system.numerics.complex(v=vs.110).aspx

И что? Уже вроде обсудили что это лишь для демонстрации. Вместо Complex там мог быть любой другой тип.

S>>>Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.


EP>>Хочешь отрицать реальность, не хочешь видеть примеры? Твоё право, но мне уже надоедает по несколько раз приводить одни и те же примеры.

S>Так не вижу тестов то.

Чем пример про замыкание
Автор: Evgeny.Panasyuk
Дата: 23.12.14
не устроил? Чем не устроил пример про замену структуры на класс?

EP>>>>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?

EP>>>>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.
S>>> Старшие поколения не используются для анализа. Используются только изменения если изменений не было, значит нет достижимых объектов, значит можно передвинуть указатель кучи на начало.
EP>>Указатель какой именно кучи на начало? Какого поколения?
S>Нулевого.

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

EP>>Причём тут конкуренция? Глобально задача у каждого программиста заработать денег (не считая for fun и т.п.), себе лично, а не конкурировать с кем-то. Ты же в это русло переводишь

S> Ну у тебя совсем плохо с головой, раз ты мешаешь программистов и водителей в одну кучу.

А у тебя нормально? Вклиниваешься в сугубо технический спор, и начинаешь петь пространные капитанские песни про целесообразность, общую стоимость, травить байки про всёвбазуупиреается, PHP'шников, при этом мешаешь в одну кучу программистов продуктовых компаний и 1С-ников

S>Напомню тебе, что в 90 х основными программистами были С и С++. К ним добавлялись фокспрошники дибейсники бейсики и паскалиты дельфисты.

S>Ни Java C# ну и конечно 1C не было и в помине. По мере доступности компьютеров нужны были специалисты коих не хватало как для бухгалтерских задач, так и с ростом интернета писателей сайтов итд. Стало понятно, что С++ сложен, а нужны были программисты сейчас в том числе студенты и тд. Стали появляться программы типа 1С, ПХП, ну и Java C#. Кстати многие С++ доказывавших на этом форуме с пеной у рта каков крутой С++ в итоге перешли на C#, Немерле итд.
S>Многие из них не ездят на машине.

Дальше что? Ты так и не сказал свой основной тезис. Тебе не нужен C++ — ну и замечательно

S>>> В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю

EP>>Конкретно где везде? Для каких задач?
S> Там где есть коллекции

Для коллекций в C++ есть например алгоритмы, итераторы, Boost.Range. Причём по-возможности Boost.Range сохраняет категорию, то есть transformed может вернуть random-access.

EP>>>>И что? Схема же есть где-то?

EP>>>>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
S>>> Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики.
S>>>Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные
EP>>Опиши в двух словах что конкретно имеешь в виду.
S> Я же тебе ссылочку давал http://infostart.ru/public/402433/ там куча ссылок. В двух словах тяжело объяснять.
S>Так же в Linq можно склеивать запросы, накладывая новые ограничения. Это связано с ленивостью запросов

Ленивость (в том числе и compile-time), Expression Templates, их склейка, и типизация всего этого есть и в C++. Я поэтому и уточняю.

S>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа

S>...
S>Генерируется следующий запрос

Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.
Re[30]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 21:24
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>А какая связь между Linq и COM? ))) И в чём смысл вообще сравнивать языковую конструкцию и некую технологию, вообще не зависящую от языка? )

S>> Он говорил про абстракции. А связь между линк и ком это создание прокси
_>Ну вот Linq ещё тянет на языковую абстракцию.

Причём разговор был не просто про абстракции, а про бесплатные
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 03.10.15 21:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Использовать C++ из Python/Java/C# тоже легко — смотри SWIG. Или например Boost.Python.

S> В С# только статические методы и то с шаманством.

Тоже не читатель? SWIG.

S>>> Кстати про инлайн

S>>>http://stackoverflow.com/questions/23374815/creating-inline-functions-and-macros
S>>>http://aakinshin.net/ru/blog/dotnet/inlining-and-starg/
EP>>Инлайнинг обычного вызова не особо интересно. Покажи инлайнинг например для замыкания внутри ФВП.
S> Если ты хочешь скорость, то зачем же тебе замыкания?

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

S>Замыкания это класс который генерится при компиляции.

S>Если мне нужна скорость, то я сам создам класс и помечу функцию для инлайна.

А на C++ можно просто использовать в "быстром" коде те же самые замыкания которые были и "медленном" коде, представляешь?

S>А то видители Dynamic не убожество, а класс это уже фи подавай им замыкания.


Там дело не только в классе — тебе и ФВП придётся переписывать

S>Я буду выбирать, то что считаю нужным.


Конечно, основываясь на знаниях о тормознутости замыканий.

S>Но в большинстве случаев я выбеоу замыкания наплевав на производительнось.


Действительно — замыкания удобны
Re[13]: Java vs C# vs C+
От: PM  
Дата: 03.10.15 21:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Где ты видишь, что я пишу "управляемые среды выиграют у нативных" ?

I>Написано прямо противоположное: "Джава и шарп рвут всё на ____своих____ платформах."

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

I>Так что да, буквы не читай.


Художественно режем цитаты, меняя контекст? Давайте я вам помогу восстановить его:



PM>> Только тролль или эльф может утверждать, что программы в управляемых средах будут выигрывать у native. Сказкам про победную поступь JIT исполнилось уже 20 лет
PM>> Ну а кто там в песочнице быстрее между собой Java или Scala, C# или Nemerle это как то выходит за пределы темы



Если что, тема называется "Java vs C# vs C++" а не "Java vs Some other JVM lang" или "C# vs Another CLR lang"

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

Кстати, вы так и не ответили, какой компилятор C++ для JVM вы имели ввиду и какова его область применения. Раз вы про это упомянули, то наверно можете рассказать больше подробностей. Хоть это и отход от основной темы, мне стало любопытно кому это могло понадобиться для практических целей.
Re[31]: Java vs C# vs C++
От: PM  
Дата: 03.10.15 23:24
Оценка: +2
Здравствуйте, Serginio1, Вы писали:

S>>> С голым Idispatch без библиотеки типов? В C# для этого есть dynamic.


PM>>Ну dynamic ведь тоже не по волшебству работает. Какие сложности получать у IDispatch нужную информацию и вызывать Invoke? В 2007 это не было проблемой: http://www.codeproject.com/Articles/19962/Driving-Microsoft-Word-using-VOLE


S> Но убожество даже в этом виде.


Таки вам шашечки или ехать? И библиотеки типов совсем-совсем нет?

S> Ничего по волшебству не работает. Однако в Бейсик,Delphi 1С и наконец в C# очень удобно работать с голым Idispatch. При этом удобно переводить с одного языка в другой http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=614821&amp;amp;threadtype=0&amp;amp;print=1&amp;amp;partt614821=1


S>Согласен, что сделать прокси не проблема. Сам их пишу, но почти все С++ работающих с 1С что я видел работают в рукопашную. Это кстати о квалификации.


Ну, судя по той теме человек явно новичок, и не только в C++

В принципе понятно, что динамические языки смотрятся выигрышнее в таких сценариях. Также ясно, что C# помогает среда исполнения. Как это работает в Delphi я уже не помню, помню только что компилятор там делал неявный AddRef/Release для COM-интерфейсов, видимо IDispatch как-то тоже поддерживается.

Думаю, что обрести желаемый уровень неубожества C++ кода поможет кодогерация — из заданого IDispatch можно добыть всю информацию о типе и на её основе сгенерировать класс на C++

Однако если разработчики 1С не отдают .tlb со своим продуктом, и прикладные C++ программисты предпочитают есть кактус IDispatch, то значит всех всё устраивает
Re[34]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 05:25
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Автор: greenpci
Дата: 05.06.15

EP>>>Здесь в C++ варианте лямбда, ФВП и итераторы, а в C# варианте обычный рукопашный цикл
S>> Угу при этом Complex свой вместо https://msdn.microsoft.com/ru-ru/library/system.numerics.complex(v=vs.110).aspx

EP>И что? Уже вроде обсудили что это лишь для демонстрации. Вместо Complex там мог быть любой другой тип.

А ну да взять, что то тормозное а потом говорить про тормоза. Возми из другого int.

S>>>>Зато сказать многократные это красиво. Я об этом тебе давным давно говорил и это было извесно лет 11 еще на видби.


EP>>>Хочешь отрицать реальность, не хочешь видеть примеры? Твоё право, но мне уже надоедает по несколько раз приводить одни и те же примеры.

S>>Так не вижу тестов то.

EP>Чем пример про замыкание
Автор: Evgeny.Panasyuk
Дата: 23.12.14
не устроил? Чем не устроил пример про замену структуры на класс?

Я не вижу результатов теста.

EP>>>>>В какой из стратегий сбор мусора это "просто сдвиг указателя конца кучи на начало"?

EP>>>>>Здесь сбор мусора это именно то что называют GC в C# и Java, то есть не надо сюда приплетать регионы.
S>>>> Старшие поколения не используются для анализа. Используются только изменения если изменений не было, значит нет достижимых объектов, значит можно передвинуть указатель кучи на начало.
EP>>>Указатель какой именно кучи на начало? Какого поколения?
S>>Нулевого.

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

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

EP>>>Причём тут конкуренция? Глобально задача у каждого программиста заработать денег (не считая for fun и т.п.), себе лично, а не конкурировать с кем-то. Ты же в это русло переводишь

S>> Ну у тебя совсем плохо с головой, раз ты мешаешь программистов и водителей в одну кучу.

EP>А у тебя нормально? Вклиниваешься в сугубо технический спор, и начинаешь петь пространные капитанские песни про целесообразность, общую стоимость, травить байки про всёвбазуупиреается, PHP'шников, при этом мешаешь в одну кучу программистов продуктовых компаний и 1С-ников


Ну ты же поешь, про то что на C++ можно делать все. Я тебе говорю, что у него есть своя ниша и эта ниша давно не так как было в 90х.

S>>Напомню тебе, что в 90 х основными программистами были С и С++. К ним добавлялись фокспрошники дибейсники бейсики и паскалиты дельфисты.

S>>Ни Java C# ну и конечно 1C не было и в помине. По мере доступности компьютеров нужны были специалисты коих не хватало как для бухгалтерских задач, так и с ростом интернета писателей сайтов итд. Стало понятно, что С++ сложен, а нужны были программисты сейчас в том числе студенты и тд. Стали появляться программы типа 1С, ПХП, ну и Java C#. Кстати многие С++ доказывавших на этом форуме с пеной у рта каков крутой С++ в итоге перешли на C#, Немерле итд.
S>>Многие из них не ездят на машине.

EP>Дальше что? Ты так и не сказал свой основной тезис. Тебе не нужен C++ — ну и замечательно

Наконец то!

S>>>> В Net он по сути используется везде и с огромным удовольствием. Сначала был скептицизм, который года через 2 пропалю

EP>>>Конкретно где везде? Для каких задач?
S>> Там где есть коллекции

EP>Для коллекций в C++ есть например алгоритмы, итераторы, Boost.Range. Причём по-возможности Boost.Range сохраняет категорию, то есть transformed может вернуть random-access.

На ваши итераторы без слез смотреть тяжело. Linq это функциональщина с ленивым выполнением при этом построена на расширениях. Приведи аналог того что я тебе показал. Ведь линк можно применять не только кколекциям но и БД или ODATA http://infostart.ru/public/403524/

EP>>>>>И что? Схема же есть где-то?

EP>>>>>Или хочешь сказать, что до запуска программы там неизвестно что, и программы реализуют ИИ чтобы понять что делать чтобы решить задачу?
S>>>> Есть, но её нужно реализовать вручную. А ведь лень. в C# есть динамики.
S>>>>Кстати Linq то ленивый и его можно склеивать итд и получать типизированные данные
EP>>>Опиши в двух словах что конкретно имеешь в виду.
S>> Я же тебе ссылочку давал http://infostart.ru/public/402433/ там куча ссылок. В двух словах тяжело объяснять.
S>>Так же в Linq можно склеивать запросы, накладывая новые ограничения. Это связано с ленивостью запросов

EP>Ленивость (в том числе и compile-time), Expression Templates, их склейка, и типизация всего этого есть и в C++. Я поэтому и уточняю.


S>>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа

S>>...
S>>Генерируется следующий запрос

EP>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.


Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.
Да и мне, что все 32 страницы просматривать? Я тебе на реальные страницы показываю со значениями тестов
и солнце б утром не вставало, когда бы не было меня
Re[30]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 05:36
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>А причём тут TypeScript и .Net? )

S>> Как это причем? TypeScript в ASP.NET MVC

_>То, что TypeScript можно применять вместо с .net (как впрочем и C++ и Python) совершенно не делает .net необходимым для использования TypeScript.

Но нужна среда для отладки и генерации TypeScript в JS. Я отлаживаю одновременно и серверный код и TypeScript.

А вы его уже начали применять в Питоне? Гугл смотрю тоже подсуетились. Мне TS очень нравится, кучу JQuery библиотек типизировали. Хейлсберг молодец.
Кстати общее у них то что их создал один человек!

_>>>Он там везде — на нём написаны: сервер (nginx), интерпретатор скриптов (Python), база данных (PostgreSQL/MySQL/SQlite).

S>> То есть в итоге то ты пишешь на питоне, а не на С++. Мы уже про это говорили, что ниша С++ там где нужна скорость. А там где скорость разработки ты же сам используешь питон.

_>Просто питоновский код в такой задаче не занят никакими серьёзными вещами, а банально играет роль системного клея между блоками кода (кстати, написанными на C/C++), исполняющими основную работу.

То есть питон для этих задач удобнее. Так же можно сказать и о любом языке.
_>Я вот могу ещё один очень известный пример привести на похожую тему. Питон сейчас очень популярен в научной среде. Причём не только для написания скриптов (что логично), но и для сложных и тяжёлых вычислений. Казалось бы нонсенс, но секрет раскрывается просто — для таких дел используются специальные библиотеки (типа numpy), которые написаны опять же на C/C++. В итоге получаем сочетания максимального быстрого написания кода с одновременной неплохой производительностью.

Но так было и раньше. Просто есть разница. Библиотеку написали 2 программиста С++ а используют тысячи Питонистов. Я никогда не заявлял, что C++ не нужен.
Я говорил, что у него своя ниша.

_>>>Во многих местах нет возможности выбрать технологию, как раз потому что аналоги слишком жирные/медленные. )))

S>> Ну и какова емкость этой ниши?

_>Так ниша то не одна, а таких много разных. ) В итоге язык C по разным рейтингам уже много лет держится на одном уровне популярности с Java. А если добавить к нему ещё C++, то является самым популярным с большим отрывом.

Ну при этом количество программистов на 1С, PHP и прочие не учитываются. Я уже приводил статистику по России, где твои выкладки далеки от реальности

S>> Я не против С++. Я про то, что он не универсален, как тут пытаются заявить. И что скорость в большинстве случаев не является главным критерием, даже во времена когда память в 64 КБ была естественным делом. Помню писал на паскале на ДВК 2 и время компиляции было полчаса. В то же время на Бейсике пусть и с огромными тормозами, но не было задержек с компиляцией. И большинство использовало бейсик


_>Скорость является главным критерием в ряде ниш. Но это действительно не единственный критерий, по которому выбирают C/C++. В других нишах его выбирают за другие преимущества. Ну а в некоторых нишах (типа тех же скриптов например) не выбирают вовсе. )))
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.10.2015 6:02 Serginio1 . Предыдущая версия .
Re[30]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 05:41
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>А какая связь между Linq и COM? ))) И в чём смысл вообще сравнивать языковую конструкцию и некую технологию, вообще не зависящую от языка? )

S>> Он говорил про абстракции. А связь между линк и ком это создание прокси

_>Ну вот Linq ещё тянет на языковую абстракцию. А причём тут COM вообще? ) И что ещё за прокси в linq? )

Ну ты в Code First описал класс со свойствами и типами полей. При выполнении компилятор строит Dynamic прокси поверх него, для того что бы добавить свойства для доступа к базе навигационных свойств итд.

https://msdn.microsoft.com/ru-ru/data/jj592886.aspx

Там такая ситуация если не было приведения к какому то типу, то ты работаешь с прокси например при работе с неопределенном типом. И для сравнения с типом нужно пользоваться GetType().BaseType()

При COM тоже строится прокси и работать с ними можно через dynamic. Это тоже абстракция
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.10.2015 5:55 Serginio1 . Предыдущая версия .
Re[34]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 06:39
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
Давай что бы закончить дискуссию сделаем выводы.
Где предпочтительнее использовать C++, а где C#,Java и другие языки.
1. С++ реально заточен под скорость. Кстати а как там со скоростью компиляции и отладки? А то до недавнего времени многие программировали в блокноте
2. Уровень сложности в С++ значительно превышает противопоставляемые ему языки
3. Во многих случаях рулят динамические языки.

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

То есть кроме скорости нужны еще и RAD радости. Например в .Net введены атрибуты, по которым в закулисье компилятор генерит прокси классы, сериализаторы итд.

Выявим те отрасли где применим C++, а где C# и почему.
Пока разговор свелся к тому, что у С# проблемы с инлайном и векторизацией.
Теперь зададимся вопросом, а какова доля в приложении таких недостатков?
и солнце б утром не вставало, когда бы не было меня
Re[12]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 06:54
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Определись. ПОчему не видно никаких чудес у С/С++ на платформе джава или дотнет ?


_>Потому что там этих оптимизаторов просто нет. )


Именно. Осталось объяснить, что же это за заговор такой — такой распрекрасный язык, раза в два даст прибавки к производительности а оптимизаторов — нет.
Re[14]: Java vs C# vs C+
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 06:57
Оценка:
Здравствуйте, PM, Вы писали:

PM>Если что, тема называется "Java vs C# vs C++" а не "Java vs Some other JVM lang" или "C# vs Another CLR lang"


Если про сравнение языков, надо сравнивать java c c++ в её JVM, иначе получится сравнение платформ.

PM>Придёт native машинный код и будет поплевывать на малышей в песочницах свысока.


Это неинтересно. Практика показывает, что натив никогда никуда не приходит, кроме тех областей, в которых он сидел еще в 80х. Более того, у этого самого натива подсократилась ниша.
Re[18]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 07:03
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Сравнивать нужно с С++ под JVM, что бы все были в равных условиях.


EP>А я что предлагаю? Не, ну действительно "буквы не читай, сообщения пиши"

EP>

EP>>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
EP>>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
EP>>Согласен?


Джаваскрипт что ли стал уже сиплюсплюсом или что ?
Re[30]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 07:19
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Так ниша то не одна, а таких много разных. ) В итоге язык C по разным рейтингам уже много лет держится на одном уровне популярности с Java. А если добавить к нему ещё C++, то является самым популярным с большим отрывом.


Не будет у него никакого отрыва. не ясно как ты считаешь популярность. Ты наверное смотришь рейтинги навроде тиобе или какой мусор.
Смотреть нужно по вакансиям. Если си и сиплюс занимают в сумме больше, чем джава или шарп, это ничего не значит. В общей массе это будет около 20%, всё остальн

Вот скажем, java, .net, python, ruby, php, javascript вместе взятые это около 500 тыс вакансий на glassdoor `united states`.

С++ выдает ажно 370 тыс, но это за счет того, что выборке оказывается практически весь дотнет и обжектив-си. С учетом того, что дотнета реально около 120 тыс, то у сиплюса выходит всего 250 тыс и то это грязные результат

И до кучи — самый популярный язык с большим отрывом, это, внимание, JavaScript — его знают и постоянно применяют примерно 90% разработчиков, даже если в вакансиях это не указано.

Вобщем суммарно выходит так, что доля unmanaged только растет. Собственно ничего неудивительного здесь нет.
Re[15]: Java vs C# vs C+
От: PM  
Дата: 04.10.15 08:08
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>Если что, тема называется "Java vs C# vs C++" а не "Java vs Some other JVM lang" или "C# vs Another CLR lang"


I>Если про сравнение языков, надо сравнивать java c c++ в её JVM, иначе получится сравнение платформ.


Я могу утверждать в том же ключе — надо сравнивать C++ с Java без JVM, иначе получится сравнение платформ.

Реальность же такова, что Java без JVM не существует. И когда JVM приносит больше проблем, чем преимуществ адекватные разработчики это понимают (см. новость про ScyllaDB) а любители единственно правильного инструмента героически преодолевают трудности (LMAX)

PM>>Придёт native машинный код и будет поплевывать на малышей в песочницах свысока.


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


Вам уже во втрой раз неинтересно. Зачем же вы меняете тему дискуссии голословными утверждениями, игнорируя неудобные вопросы?
Re[16]: Java vs C# vs C+
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 10:46
Оценка:
Здравствуйте, PM, Вы писали:

I>>Если про сравнение языков, надо сравнивать java c c++ в её JVM, иначе получится сравнение платформ.


PM>Я могу утверждать в том же ключе — надо сравнивать C++ с Java без JVM, иначе получится сравнение платформ.


Именно. Только джава и шарп тот же не содежат определенных вещей, которые обязательны для натива. Они полностью полагаются на джыт, интероп и прочие 'плюшки'.
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 13:46
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

EP>>Для коллекций в C++ есть например алгоритмы, итераторы, Boost.Range. Причём по-возможности Boost.Range сохраняет категорию, то есть transformed может вернуть random-access.

S> На ваши итераторы без слез смотреть тяжело. Linq это функциональщина с ленивым выполнением при этом построена на расширениях. Приведи аналог того что я тебе показал. Ведь линк можно применять не только кколекциям но и БД или ODATA http://infostart.ru/public/403524/

Да, и всё это является бледным подобием нормальных решений в C++ (или скажем в D). Причём не потому что Linq делали идиоты, а просто потому что C# не позволяет большего. Для настоящих умных решений требуется наличие элементов метапрограммирования в языке.

EP>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.

S> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.
S>Да и мне, что все 32 страницы просматривать? Я тебе на реальные страницы показываю со значениями тестов

Там речь шла про Linq2SQL (и аналоги из других языков), где как раз происходит генерация текстовых запросов.
Re[36]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 13:52
Оценка:
Здравствуйте, alex_public, Вы писали:

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


EP>>>Для коллекций в C++ есть например алгоритмы, итераторы, Boost.Range. Причём по-возможности Boost.Range сохраняет категорию, то есть transformed может вернуть random-access.

S>> На ваши итераторы без слез смотреть тяжело. Linq это функциональщина с ленивым выполнением при этом построена на расширениях. Приведи аналог того что я тебе показал. Ведь линк можно применять не только кколекциям но и БД или ODATA http://infostart.ru/public/403524/

_>Да, и всё это является бледным подобием нормальных решений в C++ (или скажем в D). Причём не потому что Linq делали идиоты, а просто потому что C# не позволяет большего. Для настоящих умных решений требуется наличие элементов метапрограммирования в языке.

Тогда вам нужен Немерле, а он как известно на Нет

EP>>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.

S>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.
S>>Да и мне, что все 32 страницы просматривать? Я тебе на реальные страницы показываю со значениями тестов

_>Там речь шла про Linq2SQL (и аналоги из других языков), где как раз происходит генерация текстовых запросов.


И я говорю, про Линк для ЕФ или ОДАТА или коллекций. Там абстрагируешься от того, во что в итоге преобразуется Линк. А еще блин метапрограммисты.
и солнце б утром не вставало, когда бы не было меня
Re[31]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 14:09
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>То, что TypeScript можно применять вместо с .net (как впрочем и C++ и Python) совершенно не делает .net необходимым для использования TypeScript.

S>Но нужна среда для отладки и генерации TypeScript в JS. Я отлаживаю одновременно и серверный код и TypeScript.

Для динамических языков IDE в любом случае весьма слабые и не имеют особых преимуществ перед обычными мощными редакторами.

S>А вы его уже начали применять в Питоне? Гугл смотрю тоже подсуетились. Мне TS очень нравится, кучу JQuery библиотек типизировали. Хейлсберг молодец.


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

S> Но так было и раньше. Просто есть разница. Библиотеку написали 2 программиста С++ а используют тысячи Питонистов. Я никогда не заявлял, что C++ не нужен.

S>Я говорил, что у него своя ниша.

А что, тут кто-то с этим спорил? )

_>>Так ниша то не одна, а таких много разных. ) В итоге язык C по разным рейтингам уже много лет держится на одном уровне популярности с Java. А если добавить к нему ещё C++, то является самым популярным с большим отрывом.

S> Ну при этом количество программистов на 1С, PHP и прочие не учитываются. Я уже приводил статистику по России, где твои выкладки далеки от реальности

PHP уступает и C/C++ и Java (про 1C я вообще молчу — это вообще исключительно наше локальное развлечение). Надо просто понимать масштабы деятельности соответствующих языков. К примеру за каждым современным бытовым устройством, автомобилем, промышленными устройствами автоматизации и т.п. стоит команда программистов на C. Уже только этого одного, даже без учёта классического мира ПК, хватило бы для топовых мест в рейтингах. )))
Re[31]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 14:16
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ну вот Linq ещё тянет на языковую абстракцию. А причём тут COM вообще? ) И что ещё за прокси в linq? )

S> Ну ты в Code First описал класс со свойствами и типами полей. При выполнении компилятор строит Dynamic прокси поверх него, для того что бы добавить свойства для доступа к базе навигационных свойств итд.
S>https://msdn.microsoft.com/ru-ru/data/jj592886.aspx
S> Там такая ситуация если не было приведения к какому то типу, то ты работаешь с прокси например при работе с неопределенном типом. И для сравнения с типом нужно пользоваться GetType().BaseType()

Насколько я понял, Code First — это всего лишь какая-то библиотечка ORM. Какое это имеет отношение к абстракциям языка? ) Подобное можно ввести в виде библиотеки в большинстве современных языков. Кстати, как раз вопрос различных ORM (а так же их эффективности) и обсуждался в темке, на которую кинул ссылку Евгений. И судя по ней, к Entity Framework с большим сомнением относятся даже любители C#. )))

S> При COM тоже строится прокси и работать с ними можно через dynamic. Это тоже абстракция


COM — это вообще внеязыковая технология. Если же обсуждать некие обёртки вокруг неё в конкретных языках, служащие для облегчения работы с ним, то таких библиотек опять же может быть множество. Кстати, какой конкретно аспект COM интересует? Создание своих объектов/интерфейсов. Или использование чужих?
Re[32]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 14:18
Оценка:
Здравствуйте, alex_public, Вы писали:

_>PHP уступает и C/C++ и Java (про 1C я вообще молчу — это вообще исключительно наше локальное развлечение).


Ужос, неужели только в России надо обновлять софт под изменение законодательства ?
Открой для себя ERP и прочие SAP и тд. Языки большей частью менеджед или экзотика навроде абапа.

>Надо просто понимать масштабы деятельности соответствующих языков. К примеру за каждым современным бытовым устройством, автомобилем, промышленными устройствами автоматизации и т.п. стоит команда программистов на C. Уже только этого одного, даже без учёта классического мира ПК, хватило бы для топовых мест в рейтингах. )))


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

С автомобилями ровно то же. Кроме того, по известным мене проектам там необязательно С++, а часто более низкоуровневый язык, чтото среднее между фортраном и ассемблером. Но есть, кстати говоря, и Джава.
Re[35]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 14:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>>Нашел http://rsdn.ru/forum/flame.comp/6069138.1
Автор: greenpci
Дата: 05.06.15

EP>>>>Здесь в C++ варианте лямбда, ФВП и итераторы, а в C# варианте обычный рукопашный цикл
S>>> Угу при этом Complex свой вместо https://msdn.microsoft.com/ru-ru/library/system.numerics.complex(v=vs.110).aspx
EP>>И что? Уже вроде обсудили что это лишь для демонстрации. Вместо Complex там мог быть любой другой тип.
S> А ну да взять, что то тормозное а потом говорить про тормоза.

А при чём тут тормозное? На C++ и C# были подобные реализации

S>Возми из другого int.


Что?

EP>>Чем пример про замыкание
Автор: Evgeny.Panasyuk
Дата: 23.12.14
не устроил? Чем не устроил пример про замену структуры на класс?

S> Я не вижу результатов теста.

1. Про замыкание результаты в первом сообщении темы — ввод замыкания на C# дал десятикратное замедление и гигабайты аллокаций. На C++ результат идентичен ручному коду. Или ты хочешь сказать что C# без замыканий мог обогнать C++? — не, несерьёзно.
2. По поводу замены структуры на класс — я уже ссылку приводил.

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

S> Она как раз самая, что вероятная, особенно в серверных вариантах.

Приведи статистику.

S>Мало того, за кучей может следить GC в отдельном потоке.


Точно — конкурентная гадость, которая скорей всего не lock-free.

S>>> Ну у тебя совсем плохо с головой, раз ты мешаешь программистов и водителей в одну кучу.

EP>>А у тебя нормально? Вклиниваешься в сугубо технический спор, и начинаешь петь пространные капитанские песни про целесообразность, общую стоимость, травить байки про всёвбазуупиреается, PHP'шников, при этом мешаешь в одну кучу программистов продуктовых компаний и 1С-ников
S> Ну ты же поешь, про то что на C++ можно делать все.

Где? Это враньё.
Ты не знаешь C++, и делаешь предположения что там нет какой-то фичи, хотя она есть, или что там нужно писать жутко уродливый код, хотя и это не так.
Я и отвечаю — мол то-то и то-то реализуется. Из этого не следует что на нём можно всё.
Есть реальные пробелы, но ты их не указываешь

S>Я тебе говорю, что у него есть своя ниша и эта ниша давно не так как было в 90х.


Очередное кантианство, с которым никто и не собирался спорить. Зачем это капитанство в технические теме — не ясно.

EP>>Дальше что? Ты так и не сказал свой основной тезис. Тебе не нужен C++ — ну и замечательно

S> Наконец то!

Ты ради этого развёл флуд? Чтобы намекнуть что лично тебе, для твоих задач C++ не нужен?
А — Адекватность

EP>>Для коллекций в C++ есть например алгоритмы, итераторы, Boost.Range. Причём по-возможности Boost.Range сохраняет категорию, то есть transformed может вернуть random-access.

S> На ваши итераторы без слез смотреть тяжело.

Ты просто не умеешь их готовить.

S>Linq это функциональщина с ленивым выполнением


Смотри Boost.Range, если не понятно — спрашивай. Там как раз декларативность с ленивостью

S>при этом построена на расширениях.


Для этого расширения не нужны.

S>Приведи аналог того что я тебе показал.


Ты показывал что-то про коллекции?
Вот пример Boost.Range для коллекций:
values | filtered(_1 > 5) | transformed(_1 * 111)
причём на выходе можно получить bidirectional range.
Покажи аналог LINQ — сравним выразительность.

S>>>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа

S>>>...
S>>>Генерируется следующий запрос
EP>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.

S> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.

В результате генерируется текст запроса, так понятнее?

S>Да и мне, что все 32 страницы просматривать?


Если интересна тема — смотри, там много разного. Конкретный пример на тему — sqlpp11.
Re[32]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 14:26
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>То, что TypeScript можно применять вместо с .net (как впрочем и C++ и Python) совершенно не делает .net необходимым для использования TypeScript.

S>>Но нужна среда для отладки и генерации TypeScript в JS. Я отлаживаю одновременно и серверный код и TypeScript.

_>Для динамических языков IDE в любом случае весьма слабые и не имеют особых преимуществ перед обычными мощными редакторами.

Значит ты VS не пробовал
S>>А вы его уже начали применять в Питоне? Гугл смотрю тоже подсуетились. Мне TS очень нравится, кучу JQuery библиотек типизировали. Хейлсберг молодец.

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


А вот я работая с 1С где интеллисенсе очень убогий это сразу чувствую. Смысл в подсказках плюс выявления синтаксических ошибок еще на этапе кодирования.
Кстати возможно у него будет применение не только в браузерах.
Кстати есть и транслятор из C# в JS http://habrahabr.ru/company/enterra/blog/252079/

К счастью для него, счастливое будущее уже практически наступило. Есть такой проект, который называется DuoCode. Он умеет транслировать C#-код в JavaScript. Пока он в состоянии beta, но у него уже весьма неплохо получается: поддерживаются нововведения C# 6.0, Generic-типы, Reflection, структуры и LINQ, а отлаживать итоговый JavaScript можно на исходном C#.


S>> Но так было и раньше. Просто есть разница. Библиотеку написали 2 программиста С++ а используют тысячи Питонистов. Я никогда не заявлял, что C++ не нужен.

S>>Я говорил, что у него своя ниша.

_>А что, тут кто-то с этим спорил? )


_>>>Так ниша то не одна, а таких много разных. ) В итоге язык C по разным рейтингам уже много лет держится на одном уровне популярности с Java. А если добавить к нему ещё C++, то является самым популярным с большим отрывом.

S>> Ну при этом количество программистов на 1С, PHP и прочие не учитываются. Я уже приводил статистику по России, где твои выкладки далеки от реальности

_>PHP уступает и C/C++ и Java (про 1C я вообще молчу — это вообще исключительно наше локальное развлечение). Надо просто понимать масштабы деятельности соответствующих языков. К примеру за каждым современным бытовым устройством, автомобилем, промышленными устройствами автоматизации и т.п. стоит команда программистов на C. Уже только этого одного, даже без учёта классического мира ПК, хватило бы для топовых мест в рейтингах. )))

А почти на каждом произвотстве, торговле есть программист 1С. Да и форумы 1С кие полны народу. RSDN сдулся.
и солнце б утром не вставало, когда бы не было меня
Re[32]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 14:32
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ну вот Linq ещё тянет на языковую абстракцию. А причём тут COM вообще? ) И что ещё за прокси в linq? )

S>> Ну ты в Code First описал класс со свойствами и типами полей. При выполнении компилятор строит Dynamic прокси поверх него, для того что бы добавить свойства для доступа к базе навигационных свойств итд.
S>>https://msdn.microsoft.com/ru-ru/data/jj592886.aspx
S>> Там такая ситуация если не было приведения к какому то типу, то ты работаешь с прокси например при работе с неопределенном типом. И для сравнения с типом нужно пользоваться GetType().BaseType()

_>Насколько я понял, Code First — это всего лишь какая-то библиотечка ORM. Какое это имеет отношение к абстракциям языка? ) Подобное можно ввести в виде библиотеки в большинстве современных языков. Кстати, как раз вопрос различных ORM (а так же их эффективности) и обсуждался в темке, на которую кинул ссылку Евгений. И судя по ней, к Entity Framework с большим сомнением относятся даже любители C#. )))

Это не библиотечка. Она входит в состав Entity Framework для отображения модели на БД. http://infostart.ru/public/393228/
А это ни что иное как абстракция. По ней генерятся прокси классы, миграция итд.


S>> При COM тоже строится прокси и работать с ними можно через dynamic. Это тоже абстракция


_>COM — это вообще внеязыковая технология. Если же обсуждать некие обёртки вокруг неё в конкретных языках, служащие для облегчения работы с ним, то таких библиотек опять же может быть множество. Кстати, какой конкретно аспект COM интересует? Создание своих объектов/интерфейсов. Или использование чужих?

COM в Net это совсем другое, так как идет скрещивание ужа с колючей проволокой.
Меня не интересует. Я знаю. А в 1С там голый IDispatch без tld и ITypeInfo. В С# разруливается через dynamic
и солнце б утром не вставало, когда бы не было меня
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 14:45
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>Где предпочтительнее использовать C++, а где C#,Java и другие языки.

S>1. С++ реально заточен под скорость.

Это всего лишь одна из областей, где C/C++ имеют огромное преимущество. Я бы скорее перечислил эти области так:

— тяжёлые вычисления (быстродействие здесь существенно, т.к. экономит время — деньги).
— реалтайм системы и близкие к ним (тут на самом деле много чего есть, от высоконагруженных серверов до тяжёлых 3D игр или CAD систем).
— системы с ограниченными ресурсами (я уже приводил примеры здесь). Это огромная область, причём постоянно растущая (а сейчас вообще в центре моды).
— системный код (работа с железом и т.п.). Никто же не пишет драйверы на Питоне, хотя там во многих случаях не требуется ни быстродействия ни ограниченности в ресурсах.
— реально кроссплатформенный код. К примеру единственная в данный момент полноценно кроссплатформенная GUI библиотека (Qt) написана на C++.
— метапрограммирование в мейнстрим языке.

Причём перечисленное — это не то где можно применять C++, а где его именно что выгоднее других применять. А можно практически везде, но в других областях могут быть удобнее другие решения.

S>Кстати а как там со скоростью компиляции и отладки? А то до недавнего времени многие программировали в блокноте


Ээээ что? ) Какой ещё блокнот? )))

S>2. Уровень сложности в С++ значительно превышает противопоставляемые ему языки


Это да.

S>3. Во многих случаях рулят динамические языки.


Да, есть области где динамика безусловно удобнее. Те же скрипты скажем.

S>C# достаточно простой язык сочетающий в себе как статическую типизацию, так и динамическую. Есть зачатки функциональщины.


Какая ещё динамическая типизация в C#? )))

S>Кроме самого языка огромную роль играет еще и VS в которую встроено для поддержки различных технологий, что приводит к удобству программирования и отладки


Для Java и C++ это всё тоже в наличие) Причём к тому же ещё и кроссплатформенное.

S>Выявим те отрасли где применим C++, а где C# и почему.

S> Пока разговор свелся к тому, что у С# проблемы с инлайном и векторизацией.
S>Теперь зададимся вопросом, а какова доля в приложении таких недостатков?

Это всё уже давно обсуждалось на этом форуме. Главные преимущества Java и C# хорошо известны — эти языки позволяют достаточно безопасно использовать не особо квалифицированных программистов, что является крайне удобным для большинства не IT компаний (так называемый enterprise, но только своими силами, а не через заказ у профильных компаний).
Re[36]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 14:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>1. Про замыкание результаты в первом сообщении темы — ввод замыкания на C# дал десятикратное замедление и гигабайты аллокаций. На C++ результат идентичен ручному коду. Или ты хочешь сказать что C# без замыканий мог обогнать C++? — не, несерьёзно.

Так дай конкретную ссылку. Я не ленюсь и даю людям информацию. А когда говорят об гигабайты аллокаций это вообще сумасшедший сценарий и неправильный выбор алгоритма.
EP>2. По поводу замены структуры на класс — я уже ссылку приводил.

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

S>> Она как раз самая, что вероятная, особенно в серверных вариантах.

EP>Приведи статистику.

Почитай статей огромное количетво.

S>>Мало того, за кучей может следить GC в отдельном потоке.


EP>Точно — конкурентная гадость, которая скорей всего не lock-free.

Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком.

S>>>> Ну у тебя совсем плохо с головой, раз ты мешаешь программистов и водителей в одну кучу.

EP>>>А у тебя нормально? Вклиниваешься в сугубо технический спор, и начинаешь петь пространные капитанские песни про целесообразность, общую стоимость, травить байки про всёвбазуупиреается, PHP'шников, при этом мешаешь в одну кучу программистов продуктовых компаний и 1С-ников
S>> Ну ты же поешь, про то что на C++ можно делать все.

EP>Где? Это враньё.

EP>Ты не знаешь C++, и делаешь предположения что там нет какой-то фичи, хотя она есть, или что там нужно писать жутко уродливый код, хотя и это не так.
EP>Я и отвечаю — мол то-то и то-то реализуется. Из этого не следует что на нём можно всё.
EP>Есть реальные пробелы, но ты их не указываешь
Ну так почему столько программистов 1С программирующих на чудовищно медленном интерпретаторе. Значит скорость бизнес слоя в итоге не важна.
Нужна скорость SQL


S>>Я тебе говорю, что у него есть своя ниша и эта ниша давно не так как было в 90х.


EP>Очередное кантианство, с которым никто и не собирался спорить. Зачем это капитанство в технические теме — не ясно.


EP>>>Дальше что? Ты так и не сказал свой основной тезис. Тебе не нужен C++ — ну и замечательно

S>> Наконец то!

EP>Ты ради этого развёл флуд? Чтобы намекнуть что лично тебе, для твоих задач C++ не нужен?

EP>А — Адекватность
Я тебе специально стишок привел. Мамы разные нужны, мамы разные важны. Понадобится мне C++ поверь применю и его. Блюя, но применю.
EP>>>Для коллекций в C++ есть например алгоритмы, итераторы, Boost.Range. Причём по-возможности Boost.Range сохраняет категорию, то есть transformed может вернуть random-access.
S>> На ваши итераторы без слез смотреть тяжело.

EP>Ты просто не умеешь их готовить.

Мне линк больше нравится или Хаскель

S>>Linq это функциональщина с ленивым выполнением


EP>Смотри Boost.Range, если не понятно — спрашивай. Там как раз декларативность с ленивостью


S>>при этом построена на расширениях.


EP>Для этого расширения не нужны.


S>>Приведи аналог того что я тебе показал.


EP>Ты показывал что-то про коллекции?

EP>Вот пример Boost.Range для коллекций:
EP>
EP>values | filtered(_1 > 5) | transformed(_1 * 111)
EP>
причём на выходе можно получить bidirectional range.

EP>Покажи аналог LINQ — сравним выразительность.
 from value in values
where value > 5
Select new {value* 111}

или
values.where(value =>value > 5).Select(value =>value* 111)



S>>>>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа

S>>>>...
S>>>>Генерируется следующий запрос
EP>>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.

S>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.

EP>В результате генерируется текст запроса, так понятнее

В итоге мне наплевать, вто что трансформирутся Linq запрос.

S>>Да и мне, что все 32 страницы просматривать?


EP>Если интересна тема — смотри, там много разного. Конкретный пример на тему — sqlpp11.
и солнце б утром не вставало, когда бы не было меня
Re[35]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 14:48
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Давай что бы закончить дискуссию сделаем выводы.

S>Где предпочтительнее использовать C++, а где C#,Java и другие языки.
S>1. С++ реально заточен под скорость.

Да, и не только.

S>Кстати а как там со скоростью компиляции


Скорость компиляции медленнее чем у других mainstream языков.

S>и отладки?


А что с отладкой? Тот же Edit and Continue был уже давно.

S>А то до недавнего времени многие программировали в блокноте


В каком блокноте?

S>2. Уровень сложности в С++ значительно превышает противопоставляемые ему языки


Сам язык сложнее безусловно. Но из этого не следует для старта нужно знать всю эту сложность.

S>3. Во многих случаях рулят динамические языки.


Это спорный тезис.

S>Выявим те отрасли где применим C++, а где C# и почему.


Не, у тебя это не получится — ты банально не знаешь C++, и судишь по нему на основе стародавней мифологии.

S> Пока разговор свелся к тому, что у С# проблемы с инлайном и векторизацией.


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

S>Теперь зададимся вопросом, а какова доля в приложении таких недостатков?


В каком приложении?
Re[13]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 14:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Потому что там этих оптимизаторов просто нет. )

I>Именно. Осталось объяснить, что же это за заговор такой — такой распрекрасный язык, раза в два даст прибавки к производительности а оптимизаторов — нет.

Не знаю про C++ для JVM (я про такое даже никогда не слышал), а скажем версия C++ для .net — это не C++, а какая-то хрень убогая. ))) Причём опять же не потому, что авторы идиоты, а потому что физически невозможно создать нормальный C++ под clr.
Re[14]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 14:53
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Причём опять же не потому, что авторы идиоты, а потому что физически невозможно создать нормальный C++ под clr.


Опаньки !
Re[31]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 14:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Так ниша то не одна, а таких много разных. ) В итоге язык C по разным рейтингам уже много лет держится на одном уровне популярности с Java. А если добавить к нему ещё C++, то является самым популярным с большим отрывом.

I>Не будет у него никакого отрыва. не ясно как ты считаешь популярность. Ты наверное смотришь рейтинги навроде тиобе или какой мусор.
I>Смотреть нужно по вакансиям. Если си и сиплюс занимают в сумме больше, чем джава или шарп, это ничего не значит. В общей массе это будет около 20%, всё остальн
I>Вот скажем, java, .net, python, ruby, php, javascript вместе взятые это около 500 тыс вакансий на glassdoor `united states`.
I>С++ выдает ажно 370 тыс, но это за счет того, что выборке оказывается практически весь дотнет и обжектив-си. С учетом того, что дотнета реально около 120 тыс, то у сиплюса выходит всего 250 тыс и то это грязные результат

Ну и? ) Ты по сути подтверждаешь мои слова. Да, и если что, можно быть лидером рынка и с 5% от него — всё зависит от расклада по остальным участникам. )))

I>И до кучи — самый популярный язык с большим отрывом, это, внимание, JavaScript — его знают и постоянно применяют примерно 90% разработчиков, даже если в вакансиях это не указано.


JS держится на неплохом уровне только из-за принуждения к его использованию в браузерах.

I>Вобщем суммарно выходит так, что доля unmanaged только растет. Собственно ничего неудивительного здесь нет.


Ты видимо хотел сказать "managed"? ) Ну и как бы с этим никто и не спорит. Тем более, что самое интенсивное развитие в последнее десятилетие было со стороны веб'а. Хотя сейчас ситуация понемногу начинает меняться... )
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 14:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Сравнивать нужно с С++ под JVM, что бы все были в равных условиях.

EP>>А я что предлагаю? Не, ну действительно "буквы не читай, сообщения пиши"
EP>>

EP>>>Можем сделать тест: пишем примерно одинаковый код с небольшими абстракциями на Java и на C++.
EP>>>C++ перегоняем в Java по следующей схеме: C++ -> JavaScript через Emscripten -> Java механически вручную, без принципиальных изменений.
EP>>>Согласен?

I>Джаваскрипт что ли стал уже сиплюсплюсом или что ?

Если не понял схему, сразу бы вопрос задал.
Поясняю. Нормального компилятора C++ -> JVM я не знаю, ты его тоже не привёл. Для сравнения я предлагаю перевести C++ в Java по следующей схеме:
1. Компилируем C++ в JavaScript, с помощью Emscripten.
2. Из получившегося JavaScript кода выдираем релевантные куски, механически переводим их в Java код без принципиальных изменений и делаем необходимый мини-обвяз (на замену тому которые был в JavaScript коде).
Схема ясна?
Re[36]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 14:59
Оценка:
_>Какая ещё динамическая типизация в C#? )))
ключевое слово dynamic
S>>Кроме самого языка огромную роль играет еще и VS в которую встроено для поддержки различных технологий, что приводит к удобству программирования и отладки

_>Для Java и C++ это всё тоже в наличие) Причём к тому же ещё и кроссплатформенное.


S>>Выявим те отрасли где применим C++, а где C# и почему.

S>> Пока разговор свелся к тому, что у С# проблемы с инлайном и векторизацией.
S>>Теперь зададимся вопросом, а какова доля в приложении таких недостатков?

_>Это всё уже давно обсуждалось на этом форуме. Главные преимущества Java и C# хорошо известны — эти языки позволяют достаточно безопасно использовать не особо квалифицированных программистов, что является крайне удобным для большинства не IT компаний (так называемый enterprise, но только своими силами, а не через заказ у профильных компаний).


То есть скорость разработки и инструментов не важны?
А вот представь, что я программирую на нескольких языках. Мне нужно найти примеры для решения огромного круга задач. Совместить их с 1С.
Для C# я нахожу все быстро и применяю.
Для большинства задач скорости выше крыши. Те недостатки которые есть не являются критическими, а в основных реалиях код на C# генерит тот же машинный код, что и C++.
А вот для многих и C# и Java тоже оочень сложны.

Кстати про Linq. То много расширений https://github.com/loresoft/EntityFramework.Extended/wiki/Batch-Update-and-Delete
и солнце б утром не вставало, когда бы не было меня
Re[36]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 15:02
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


S>>Выявим те отрасли где применим C++, а где C# и почему.


EP>Не, у тебя это не получится — ты банально не знаешь C++, и судишь по нему на основе стародавней мифологии.

Ну ты же знаешь все. Так что можешь и ответить на этот вопрос.
S>> Пока разговор свелся к тому, что у С# проблемы с инлайном и векторизацией.

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


S>>Теперь зададимся вопросом, а какова доля в приложении таких недостатков?


EP>В каком приложении?

Вооооо. Наконец то. А то сферический конь.
Еще раз задам вопрос

Выявим те отрасли где применим C++, а где C# и почему.

и солнце б утром не вставало, когда бы не было меня
Re[37]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Да, и всё это является бледным подобием нормальных решений в C++ (или скажем в D). Причём не потому что Linq делали идиоты, а просто потому что C# не позволяет большего. Для настоящих умных решений требуется наличие элементов метапрограммирования в языке.

S> Тогда вам нужен Немерле, а он как известно на Нет

Для таких целей достаточно того метапрограммирования, что есть в C++.

_>>Там речь шла про Linq2SQL (и аналоги из других языков), где как раз происходит генерация текстовых запросов.

S>И я говорю, про Линк для ЕФ или ОДАТА или коллекций. Там абстрагируешься от того, во что в итоге преобразуется Линк. А еще блин метапрограммисты.

Так EF же генерирует текстовые запросы, не так ли? ) И этот код кто-то должен был написать. Так же как и в C++ есть аналогичные библиотеки.
Re[32]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 15:06
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну и? ) Ты по сути подтверждаешь мои слова. Да, и если что, можно быть лидером рынка и с 5% от него — всё зависит от расклада по остальным участникам. )))


Ну да, чуть не 99% у Джаваскрипта, а лидер популярности — С++
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

>>Надо просто понимать масштабы деятельности соответствующих языков. К примеру за каждым современным бытовым устройством, автомобилем, промышленными устройствами автоматизации и т.п. стоит команда программистов на C. Уже только этого одного, даже без учёта классического мира ПК, хватило бы для топовых мест в рейтингах. )))

I>Это мягко говоря, заблуждение. На все бытовые устройства будет хорошо если десяток вендоров софта и там далеко не факт, что будет целиком С++.

Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.

I>С автомобилями ровно то же. Кроме того, по известным мене проектам там необязательно С++, а часто более низкоуровневый язык, чтото среднее между фортраном и ассемблером. Но есть, кстати говоря, и Джава.


В подавляющем числе случаев там C, иногда чуть модифицированный. )))
Re[20]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 15:09
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Джаваскрипт что ли стал уже сиплюсплюсом или что ?


EP>Поясняю. Нормального компилятора C++ -> JVM я не знаю


Лучше остановиться на этом и начать с того, почему же так вышло. До кучи, посмотреть в дотнет, там аналогичная ситуация. Мерять синтетику, как ты придложил, не интересно. Мерять нужно реальные задачи.
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Для динамических языков IDE в любом случае весьма слабые и не имеют особых преимуществ перед обычными мощными редакторами.

S> Значит ты VS не пробовал

Когда-то давно (во времена VS 6.0) это был основной инструмент, т.к. он на голову превосходил всех своих конкурентов. Но со временем он сдал свои позиции и мы перешли на более мощные IDE.

S> А вот я работая с 1С где интеллисенсе очень убогий это сразу чувствую. Смысл в подсказках плюс выявления синтаксических ошибок еще на этапе кодирования.


А ты что с чем сравниваешь то? ) В VS у тебя какой язык? ) Если C#, то это очевидно некорректное сравнение.
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:16
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Насколько я понял, Code First — это всего лишь какая-то библиотечка ORM. Какое это имеет отношение к абстракциям языка? ) Подобное можно ввести в виде библиотеки в большинстве современных языков. Кстати, как раз вопрос различных ORM (а так же их эффективности) и обсуждался в темке, на которую кинул ссылку Евгений. И судя по ней, к Entity Framework с большим сомнением относятся даже любители C#. )))

S> Это не библиотечка. Она входит в состав Entity Framework для отображения модели на БД. http://infostart.ru/public/393228/
S>А это ни что иное как абстракция. По ней генерятся прокси классы, миграция итд.

А Entity Framework — это не библиотечка? ))) А что тогда? )

_>>COM — это вообще внеязыковая технология. Если же обсуждать некие обёртки вокруг неё в конкретных языках, служащие для облегчения работы с ним, то таких библиотек опять же может быть множество. Кстати, какой конкретно аспект COM интересует? Создание своих объектов/интерфейсов. Или использование чужих?

S> COM в Net это совсем другое, так как идет скрещивание ужа с колючей проволокой.
S>Меня не интересует. Я знаю. А в 1С там голый IDispatch без tld и ITypeInfo. В С# разруливается через dynamic

IDispatch — это самый убогий подвид COM, предназначенный для поддержки таких языков как VB. Работа с этим интерфейсом из нормальных языков — это не понимание всех базовых принципов COM.
Re[34]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 15:16
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Это мягко говоря, заблуждение. На все бытовые устройства будет хорошо если десяток вендоров софта и там далеко не факт, что будет целиком С++.


_>Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.


"Рынка нет" Рынок это не стандарты, это спрос и предложение. Есть и то и другое. Стандарты — это регулирование рынка, а не его наличие.

И не надо искать там разное железо, там почти все одно и то же. Я ж сказал — около десятка вендоров. То есть, по большому счету, всего десяток команд пилит прошивки.

I>>С автомобилями ровно то же. Кроме того, по известным мене проектам там необязательно С++, а часто более низкоуровневый язык, чтото среднее между фортраном и ассемблером. Но есть, кстати говоря, и Джава.


_>В подавляющем числе случаев там C, иногда чуть модифицированный. )))


Не знаю где ты "подавляющее" увидел, но основные европейские концерны используют софт который к си имеет весьма далёкое отношение.
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 15:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Джаваскрипт что ли стал уже сиплюсплюсом или что ?

EP>>Поясняю. Нормального компилятора C++ -> JVM я не знаю
I>Лучше остановиться на этом и начать с того, почему же так вышло. До кучи, посмотреть в дотнет, там аналогичная ситуация. Мерять синтетику, как ты придложил, не интересно. Мерять нужно реальные задачи.

Подожди, это же ты сказал что у Java байткод нормальный, что я "мусолю булшит", что нужно сравнивать на одной платформе, и на ней скорость не будет сильно отличаться. Вот я и предлагаю тест на одной платформе
Re[34]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 15:29
Оценка:
Здравствуйте, alex_public, Вы писали:

S>> Это не библиотечка. Она входит в состав Entity Framework для отображения модели на БД. http://infostart.ru/public/393228/

S>>А это ни что иное как абстракция. По ней генерятся прокси классы, миграция итд.

_>А Entity Framework — это не библиотечка? ))) А что тогда? )


Это, внезапно фреймворк, для особо не умных там даже это в названии указано : Entity Framework

S>> COM в Net это совсем другое, так как идет скрещивание ужа с колючей проволокой.

S>>Меня не интересует. Я знаю. А в 1С там голый IDispatch без tld и ITypeInfo. В С# разруливается через dynamic

_>IDispatch — это самый убогий подвид COM, предназначенный для поддержки таких языков как VB. Работа с этим интерфейсом из нормальных языков — это не понимание всех базовых принципов COM.


IDispatch — это не com, а интерфейс. И предназначен он для поддержки сom'a языками без vtbl.
Re[37]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Какая ещё динамическая типизация в C#? )))

S> ключевое слово dynamic

Это не имеет никакого отношения к динамической типизации в языке. В таком смысле можно и какой-нибудь тип Variant обозвать динамической типизацией. Или вообще указатель на IUnknown. )))

_>>Это всё уже давно обсуждалось на этом форуме. Главные преимущества Java и C# хорошо известны — эти языки позволяют достаточно безопасно использовать не особо квалифицированных программистов, что является крайне удобным для большинства не IT компаний (так называемый enterprise, но только своими силами, а не через заказ у профильных компаний).

S> То есть скорость разработки и инструментов не важны?

Важны. Но для мейнстрим языков (а у нас тут сейчас в обсуждение только такие и участвуют) это всё находится на приблизительно равном уровне. Собственно производители инструментов одни и те же обычно. )))

S>А вот представь, что я программирую на нескольких языках. Мне нужно найти примеры для решения огромного круга задач. Совместить их с 1С.

S>Для C# я нахожу все быстро и применяю.
S> Для большинства задач скорости выше крыши. Те недостатки которые есть не являются критическими, а в основных реалиях код на C# генерит тот же машинный код, что и C++.
S> А вот для многих и C# и Java тоже оочень сложны.

А я разве где-то говорил, что тебе надо переходить на C++ или ещё куда-то? )
Re[36]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 15:32
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


S>>Мало того, за кучей может следить GC в отдельном потоке.


EP>Точно — конкурентная гадость, которая скорей всего не lock-free.


Специально не поленился и поисал для тебя
http://www.oszone.net/18549/

.NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.

Фоновый GC для сервера В .NET 4 мы включили фоновый GC для рабочих станций. С того времени мы все чаще наблюдаем использование куч с размерами в диапазоне от нескольких до десятков гигабайт. Даже такому оптимизированному параллельному сборщику, как у нас, могут потребоваться секунды на сбор столь больших куч, а значит, потоки приложения будут блокированы примерно на то же время. Введение фонового GC для сервера обеспечивает поддержку нашим серверным сборщиком параллельных процедур сбора. Это сводит к минимуму длительные блокирующие операции сбора мусора, почти не влияя на высокую пропускную способность приложения.

Если вы используете серверный GC, вам не нужно ничего делать для того, чтобы задействовать преимущества этой новой функциональности; фоновый GC для сервера выполняется автоматически. Высокоуровневые характеристики фонового GC одинаковы как для клиента, так и для сервера:
•в фоне может выполняться только полный GC (объектов поколения 2);
•при фоновом GC сжатие не осуществляется;
•активный (не в фоне) GC (объектов поколений 0 и 1) возможен в процессе фонового GC. Серверный GC выполняется выделенными серверными GC-потоками;
•полностью блокирующий GC также осуществляется выделенными серверными GC-потоками.

и солнце б утром не вставало, когда бы не было меня
Re[22]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.15 15:38
Оценка: :))
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


Тест на одной платформе — это оба компилера писаные именно под эту платформу.
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.

I>"Рынка нет" Рынок это не стандарты, это спрос и предложение. Есть и то и другое. Стандарты — это регулирование рынка, а не его наличие.
I>И не надо искать там разное железо, там почти все одно и то же. Я ж сказал — около десятка вендоров. То есть, по большому счету, всего десяток команд пилит прошивки.

Нуу раз всего десяток, то тогда явно не проблема их перечислить? ) Да даже зачем их всех перечислять. Давай одну хотя бы. Например вот что у нас за команда делает прошивки для всех микроволновок в мире? )))

_>>В подавляющем числе случаев там C, иногда чуть модифицированный. )))

I>Не знаю где ты "подавляющее" увидел, но основные европейские концерны используют софт который к си имеет весьма далёкое отношение.

Эээ, что? ) Какие ещё концерны? ) Ты думаешь они могут выбирать? ))) Они же не являются производителями микроэлектроники (кстати, а вот таких производителей действительно уже можно по пальцам руки перечислять), а только пользуются их продукцией. Существует набор из нескольких архитектур, и для них соответственно пишут компиляторы с разных языков. Обычно это делает только сам производитель этих процессоров и обычно ограничивается языком C (или его модификацией). Причём там это всё достаточно убого и закрыто. Хорошо что в последнее время сильно развились ARM микроконтроллеры, для которых есть мощный gcc (с полноценным C++ и не только).
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 15:45
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

_>>А Entity Framework — это не библиотечка? ))) А что тогда? )

K>Это, внезапно фреймворк, для особо не умных там даже это в названии указано : Entity Framework

И в чём отличие от библиотеки? )))

_>>IDispatch — это самый убогий подвид COM, предназначенный для поддержки таких языков как VB. Работа с этим интерфейсом из нормальных языков — это не понимание всех базовых принципов COM.

K>IDispatch — это не com, а интерфейс. И предназначен он для поддержки сom'a языками без vtbl.

Я именно это и сказал. Использовать IDispatch из C++ — это от очень кривой архитектуры.
Re[38]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 15:46
Оценка:
Здравствуйте, alex_public, Вы писали:



_>Так EF же генерирует текстовые запросы, не так ли? ) И этот код кто-то должен был написать. Так же как и в C++ есть аналогичные библиотеки.

Еще раз Linq это абстракция. Не важно, во что это транслируется
На самом деле нужно понять где область применения Net
В каких приложениях процент проседания на определенных задачах будет минимален.
1. Декстопные приложения где общее время выполнения кода минимально
2. Серверные ASP.Net HTTP сервисы WCF
3. Сейчас есть возможность создавать кроссплатформенные приложения для мобильных приложений и ASP net
и солнце б утром не вставало, когда бы не было меня
Re[34]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 15:46
Оценка:
Здравствуйте, alex_public, Вы писали:

инструмент, т.к. он на голову превосходил всех своих конкурентов. Но со временем он сдал свои позиции и мы перешли на более мощные IDE.

S>> А вот я работая с 1С где интеллисенсе очень убогий это сразу чувствую. Смысл в подсказках плюс выявления синтаксических ошибок еще на этапе кодирования.


_>А ты что с чем сравниваешь то? ) В VS у тебя какой язык? ) Если C#, то это очевидно некорректное сравнение.

TypeScript
и солнце б утром не вставало, когда бы не было меня
Re[38]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 15:49
Оценка:
Здравствуйте, alex_public, Вы писали:
S>> То есть скорость разработки и инструментов не важны?

_>Важны. Но для мейнстрим языков (а у нас тут сейчас в обсуждение только такие и участвуют) это всё находится на приблизительно равном уровне. Собственно производители инструментов одни и те же обычно. )))


S>>А вот представь, что я программирую на нескольких языках. Мне нужно найти примеры для решения огромного круга задач. Совместить их с 1С.

S>>Для C# я нахожу все быстро и применяю.
S>> Для большинства задач скорости выше крыши. Те недостатки которые есть не являются критическими, а в основных реалиях код на C# генерит тот же машинный код, что и C++.
S>> А вот для многих и C# и Java тоже оочень сложны.

_>А я разве где-то говорил, что тебе надо переходить на C++ или ещё куда-то? )

Раз все находится на одном уровне, то какой язык нужно выбрать?
Или все таки есть отличия? И вы применяете питон вместо C++.
и солнце б утром не вставало, когда бы не было меня
Re[36]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 15:50
Оценка:
Здравствуйте, alex_public, Вы писали:

_>И в чём отличие от библиотеки? )))


http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library
Re[37]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 15:58
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Дальше что? Ты так и не сказал свой основной тезис. Тебе не нужен C++ — ну и замечательно

S>>> Наконец то!
EP>>Ты ради этого развёл флуд? Чтобы намекнуть что лично тебе, для твоих задач C++ не нужен?
EP>>А — Адекватность
S> Я тебе специально стишок привел. Мамы разные нужны, мамы разные важны. Понадобится мне C++ поверь применю и его. Блюя, но применю.

А теперь прочитай мой первый же ответ тебе:

EP>>>По факту же в большинстве кода не нужны никакие владеющие указатели.
S>> Так в итоге C#, Java, JS в топку? Все на С++?

EP>Не, не в топку. Я сам частенько использую Python. И по секрету скажу, недавно даже на C# написал несколько сотен строк — правда это был пример использования C++ библиотеки, но тем не менее.
EP>А вообще непонятно как ты сделал вывод про "в топку"

То есть ты сам придумал что "C#/etc в топку", и сам же пытаешься это опровергнуть. Это вообще какая-то жесть
Re[37]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 16:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>1. Про замыкание результаты в первом сообщении темы — ввод замыкания на C# дал десятикратное замедление и гигабайты аллокаций. На C++ результат идентичен ручному коду. Или ты хочешь сказать что C# без замыканий мог обогнать C++? — не, несерьёзно.

S> Так дай конкретную ссылку. Я не ленюсь и даю людям информацию.

Ты издеваешься? Ссылка была буквально чуть выше, в том что ты только что удалил отвечая на сообщение:

EP>>>Чем пример про замыкание

не устроил?


S>А когда говорят об гигабайты аллокаций это вообще сумасшедший сценарий и неправильный выбор алгоритма.


Алгоритм тот же самый Разница только в наличии/отсутствии замыканий.

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

S>>> Она как раз самая, что вероятная, особенно в серверных вариантах.
EP>>Приведи статистику.
S> Почитай статей огромное количетво.

Я вижу огромное количество статей и советов как не обжечься на GC.

S>>>Мало того, за кучей может следить GC в отдельном потоке.

EP>>Точно — конкурентная гадость, которая скорей всего не lock-free.
S> Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком.

Я тебя поздравляю, действительно есть задачи где от него нет проблем. Я в первом же сообщении этой ветки тебе сказал что сам частенько использую Python.

S>>> Ну ты же поешь, про то что на C++ можно делать все.

EP>>Где? Это враньё.
EP>>Ты не знаешь C++, и делаешь предположения что там нет какой-то фичи, хотя она есть, или что там нужно писать жутко уродливый код, хотя и это не так.
EP>>Я и отвечаю — мол то-то и то-то реализуется. Из этого не следует что на нём можно всё.
EP>>Есть реальные пробелы, но ты их не указываешь
S> Ну так почему столько программистов 1С программирующих на чудовищно медленном интерпретаторе. Значит скорость бизнес слоя в итоге не важна.

И что из этого?
Тема вообще не про то что скорость нужна абсолютно везде, зачем ты пытаешься опровергнуть это?

S>>> На ваши итераторы без слез смотреть тяжело.

S>>>...
EP>>Ты показывал что-то про коллекции?
EP>>Вот пример Boost.Range для коллекций:
EP>>
EP>>values | filtered(_1 > 5) | transformed(_1 * 111)
EP>>
причём на выходе можно получить bidirectional range.

EP>>Покажи аналог LINQ — сравним выразительность.
S>
S> from value in values
S>where value > 5
S>Select new {value* 111}
S>

S>или
S>
S>values.where(value =>value > 5).Select(value =>value* 111)
S>


Сравниваем. Вариант Boost.Range:
1. Лаконичнее, красивее.
2. Быстрее. Там под копотом кстати те самые итераторы.
3. Выдаёт bidirectional последовательность вместо forward/single pass.

S>>>>>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа

S>>>>>...
S>>>>>Генерируется следующий запрос
EP>>>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.

S>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.
EP>>В результате генерируется текст запроса, так понятнее
S> В итоге мне наплевать, вто что трансформирутся Linq запрос.

Да тут в принципе тоже, я про текст запрос сказал, для того чтобы подчеркнуть что трансформация происходит на этапе компиляции.
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 16:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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

I>Тест на одной платформе — это оба компилера писаные именно под эту платформу.

Всё, занавес, сова треснула по швам.
Re[38]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 16:13
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Сравниваем. Вариант Boost.Range:

EP>1. Лаконичнее, красивее.
EP>2. Быстрее. Там под копотом кстати те самые итераторы.
EP>3. Выдаёт bidirectional последовательность вместо forward/single pass.

1. Нет, полное убожество. Enumerable.Range.Select куда как человечнее.
2. Где замеры скорости?
3. Ок.
4. linq вариант ленивый, а плюсовое убожество?
Re[37]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 16:13
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Мало того, за кучей может следить GC в отдельном потоке.

EP>>Точно — конкурентная гадость, которая скорей всего не lock-free.
S>Специально не поленился и поисал для тебя
S>http://www.oszone.net/18549/
S>

S> .NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.


Я на эту тему даже тест проводил
Автор: Evgeny.Panasyuk
Дата: 17.10.13


S>

S>Фоновый GC для сервера В .NET 4 мы включили фоновый GC для рабочих станций. С того времени мы все чаще наблюдаем использование куч с размерами в диапазоне от нескольких до десятков гигабайт. Даже такому оптимизированному параллельному сборщику, как у нас, могут потребоваться секунды на сбор столь больших куч, а значит, потоки приложения будут блокированы примерно на то же время. Введение фонового GC для сервера обеспечивает поддержку нашим серверным сборщиком параллельных процедур сбора. Это сводит к минимуму длительные блокирующие операции сбора мусора, почти не влияя на высокую пропускную способность приложения.

S>Если вы используете серверный GC, вам не нужно ничего делать для того, чтобы задействовать преимущества этой новой функциональности; фоновый GC для сервера выполняется автоматически. Высокоуровневые характеристики фонового GC одинаковы как для клиента, так и для сервера:
S>•в фоне может выполняться только полный GC (объектов поколения 2);
S>•при фоновом GC сжатие не осуществляется;
S>•активный (не в фоне) GC (объектов поколений 0 и 1) возможен в процессе фонового GC. Серверный GC выполняется выделенными серверными GC-потоками;
S>•полностью блокирующий GC также осуществляется выделенными серверными GC-потоками.


А зачем ты привёл это? Оно как-то опровергает мои тезисы?
Re[39]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 16:16
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Так EF же генерирует текстовые запросы, не так ли? ) И этот код кто-то должен был написать. Так же как и в C++ есть аналогичные библиотеки.

S>Еще раз Linq это абстракция. Не важно, во что это транслируется

Да, сам Linq (а точнее IEnumerable) — это абстракция (кстати, на мой взгляд весьма сомнительная, но это уже дело вкуса). Только вот сама по себе эта абстракция ничего не может. Чтобы она могла работать с контейнерами, базами данных и т.п. требуется подключение соответствующих библиотек. Так вот в C++ (и не только) есть аналогичные библиотеки с аналогичной функциональностью.

S>На самом деле нужно понять где область применения Net

S>В каких приложениях процент проседания на определенных задачах будет минимален.
S>1. Декстопные приложения где общее время выполнения кода минимально

У меня на десктопе установлено очень много разного софта из разных областей. Так вот написанных на .net там кажется вообще нет. )))

S>2. Серверные ASP.Net HTTP сервисы WCF


Да, это актуальная область для современного .net, особенно с появлением серверного подмножества .net'a с официальной кроссплатформенностью.

S>3. Сейчас есть возможность создавать кроссплатформенные приложения для мобильных приложений и ASP net


В Xamarin весьма специфическая кроссплатформенность. К примеру GUI надо писать заново под каждую платформу.
Re[39]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 16:22
Оценка: :)
Здравствуйте, Klikujiskaaan, Вы писали:

EP>>Сравниваем. Вариант Boost.Range:

EP>>1. Лаконичнее, красивее.
EP>>2. Быстрее. Там под копотом кстати те самые итераторы.
EP>>3. Выдаёт bidirectional последовательность вместо forward/single pass.
K>1. Нет, полное убожество. Enumerable.Range.Select куда как человечнее.

Полное убожество это вот это:
from value in values
where value > 5
Select new {value* 111}

А вот это: values | filtered(_1 > 5) | transformed(_1 * 111) — лаконичные пайпы известные всем по работе с консолью

K>2. Где замеры скорости?


Можем замерять — не вопрос. Конкретно в этом пример это моё предположение основанное на том, что я видел результирующий ASM в случае C++.
Помимо этого точно быстрее в случае когда нужно обойти задом наперёд — за счёт двунаправленности.

K>4. linq вариант ленивый, а плюсовое убожество?


Так, давай без эмоций — не серьёзно. Вариант Boost.Range — ленивый и двунаправленный. Если же не делать фильтрацию, то вообще Random Access.
Re[39]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 16:25
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

_>>А я разве где-то говорил, что тебе надо переходить на C++ или ещё куда-то? )

S> Раз все находится на одном уровне, то какой язык нужно выбрать?
S>Или все таки есть отличия? И вы применяете питон вместо C++.

В начале составляем список языков, которые вообще позволяют решить данную задачу (к примеру для микроконтроллеров там будет всего 1-2 варианта), а потом выбираем из них самое дешёвое (с точки зрения бизнеса) решение.
Re[40]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 16:26
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Полное убожество это вот это:

EP>
EP>from value in values
EP>where value > 5
EP>Select new {value* 111}
EP>

EP>А вот это: values | filtered(_1 > 5) | transformed(_1 * 111) — лаконичные пайпы известные всем по работе с консолью


Кто такие все? Ты про Шеридана и его клуб анонимных любителей линукса?
Re[37]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 16:28
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

_>>И в чём отличие от библиотеки? )))

K>http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library

Даже если фреймворк является жирной библиотекой, навязывающей архитектуру приложению, то он всё равно остаётся всего лишь библиотекой. )))
Re[38]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 16:29
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>И в чём отличие от библиотеки? )))

K>>http://stackoverflow.com/questions/3057526/framework-vs-toolkit-vs-library

_>Даже если фреймворк является жирной библиотекой, навязывающей архитектуру приложению, то он всё равно остаётся всего лишь библиотекой. )))


Чукча не читатель, ясно.
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 16:34
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

EP>>А вот это: values | filtered(_1 > 5) | transformed(_1 * 111) — лаконичные пайпы известные всем по работе с консолью

K>Кто такие все? Ты про Шеридана и его клуб анонимных любителей линукса?

ВНЕЗАПНО:
C:\Windows\system32>dir | sort

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true

Using the pipe operator (|)

The pipe operator (|) takes the output (by default, STDOUT) of one command and directs it into the input (by default, STDIN) of another command. For example, the following command sorts a directory:

dir | sort

In this example, both commands start simultaneously, but then the sort command pauses until it receives the dir command's output. The sort command uses the dir command's output as its input, and then sends its output to handle 1 (that is, STDOUT).

Отредактировано 04.10.2015 16:34 Evgeny.Panasyuk . Предыдущая версия .
Re[42]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 16:35
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>ВНЕЗАПНО:

EP>
EP>C:\Windows\system32>dir | sort
EP>

EP>http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true

Ну так ты ВНЕЗАПНО проведи опрос на SO, что людям более знакомо и приятно sql-like синтаксис или пайпы.
Re[43]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 16:43
Оценка: :)
Здравствуйте, Klikujiskaaan, Вы писали:

EP>>ВНЕЗАПНО:

EP>>
EP>>C:\Windows\system32>dir | sort
EP>>

EP>>http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true
K>Ну так ты ВНЕЗАПНО проведи опрос на SO,

SO не предназначен для опросов.

K>что людям более знакомо и приятно sql-like синтаксис


Это кстати даже далеко от SQL. Там структурно аналог монадической DO-нотации, а не SQL. От SQL там только подобие ключевых слов.
Re[40]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 16:53
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Так EF же генерирует текстовые запросы, не так ли? ) И этот код кто-то должен был написать. Так же как и в C++ есть аналогичные библиотеки.

S>>Еще раз Linq это абстракция. Не важно, во что это транслируется

_>Да, сам Linq (а точнее IEnumerable) — это абстракция (кстати, на мой взгляд весьма сомнительная, но это уже дело вкуса). Только вот сама по себе эта абстракция ничего не может. Чтобы она могла работать с контейнерами, базами данных и т.п. требуется подключение соответствующих библиотек. Так вот в C++ (и не только) есть аналогичные библиотеки с аналогичной функциональностью.

EF. Дай ссылочки посмотреть. А внутри Linq деревья выражений.
https://msdn.microsoft.com/ru-ru/library/bb397951.aspx
Я уже приводил ссылки на расширители.

S>>На самом деле нужно понять где область применения Net

S>>В каких приложениях процент проседания на определенных задачах будет минимален.
S>>1. Декстопные приложения где общее время выполнения кода минимально

_>У меня на десктопе установлено очень много разного софта из разных областей. Так вот написанных на .net там кажется вообще нет. )))


S>>2. Серверные ASP.Net HTTP сервисы WCF


_>Да, это актуальная область для современного .net, особенно с появлением серверного подмножества .net'a с официальной кроссплатформенностью.


S>>3. Сейчас есть возможность создавать кроссплатформенные приложения для мобильных приложений и ASP net


_>В Xamarin весьма специфическая кроссплатформенность. К примеру GUI надо писать заново под каждую платформу.

Ну вроде как тут уже договорились, что для каждого GUI свой интерфейс либо HTML 5
и солнце б утром не вставало, когда бы не было меня
Re[38]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 17:01
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:



EP>Я вижу огромное количество статей и советов как не обжечься на GC.

Д
S>>>>Мало того, за кучей может следить GC в отдельном потоке.
EP>>>Точно — конкурентная гадость, которая скорей всего не lock-free.
S>> Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком.

EP>Я тебя поздравляю, действительно есть задачи где от него нет проблем. Я в первом же сообщении этой ветки тебе сказал что сам частенько использую Python.

Ну и? Тогда о чем разговор?
S>> Ну так почему столько программистов 1С программирующих на чудовищно медленном интерпретаторе. Значит скорость бизнес слоя в итоге не важна.

EP>И что из этого?

EP>Тема вообще не про то что скорость нужна абсолютно везде, зачем ты пытаешься опровергнуть это?


S>>>> На ваши итераторы без слез смотреть тяжело.

S>>>>...
EP>>>Ты показывал что-то про коллекции?
EP>>>Вот пример Boost.Range для коллекций:
EP>>>
EP>>>values | filtered(_1 > 5) | transformed(_1 * 111)
EP>>>
причём на выходе можно получить bidirectional range.

EP>>>Покажи аналог LINQ — сравним выразительность.
S>>
S>> from value in values
S>>where value > 5
S>>Select new {value* 111}
S>>

S>>или
S>>
S>>values.where(value =>value > 5).Select(value =>value* 111)
S>>


EP>Сравниваем. Вариант Boost.Range:

EP>1. Лаконичнее, красивее.
EP>2. Быстрее. Там под копотом кстати те самые итераторы.
EP>3. Выдаёт bidirectional последовательность вместо forward/single pass.

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

S>>>>>>// Этот запрос получает значения периодического реквизита с ID 9697 в порядке убывания даты, времени, и строки документа

S>>>>>>...
S>>>>>>Генерируется следующий запрос
EP>>>>>Это реализуется и в C++, причём с генерацией текста запроса во время компиляции. Подробнейшим образом обсуждалось вот в этой теме
Автор: gandjustas
Дата: 13.04.15
.

S>>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.
EP>>>В результате генерируется текст запроса, так понятнее
В результате генерируется машинный код на сервере. Есть абстракции. Контекс можно подменить и тогда итогом будет совсем другое.
S>> В итоге мне наплевать, вто что трансформирутся Linq запрос.

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

Так я от тебя ссылки и не дождался.
и солнце б утром не вставало, когда бы не было меня
Re[41]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 17:04
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Да, сам Linq (а точнее IEnumerable) — это абстракция (кстати, на мой взгляд весьма сомнительная, но это уже дело вкуса). Только вот сама по себе эта абстракция ничего не может. Чтобы она могла работать с контейнерами, базами данных и т.п. требуется подключение соответствующих библиотек. Так вот в C++ (и не только) есть аналогичные библиотеки с аналогичной функциональностью.

S> EF. Дай ссылочки посмотреть. А внутри Linq деревья выражений.
S>https://msdn.microsoft.com/ru-ru/library/bb397951.aspx
S>Я уже приводил ссылки на расширители.

https://github.com/rbock/sqlpp11 — один из вариантов. )

_>>В Xamarin весьма специфическая кроссплатформенность. К примеру GUI надо писать заново под каждую платформу.

S>Ну вроде как тут уже договорились, что для каждого GUI свой интерфейс либо HTML 5

Где это "тут" договорились? ) На Qt я создают один и тот же интерфейс (код) и он работает на всех платформах сразу. Причём на каждой из них выглядит родным.
Re[38]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 17:09
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>Мало того, за кучей может следить GC в отдельном потоке.

EP>>>Точно — конкурентная гадость, которая скорей всего не lock-free.
S>>Специально не поленился и поисал для тебя
S>>http://www.oszone.net/18549/
S>>

S>> .NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.


EP>Я на эту тему даже тест проводил
Автор: Evgeny.Panasyuk
Дата: 17.10.13


Я давно тесты проводил http://rsdn.ru/forum/design/701354.1
Автор: Serginio1
Дата: 30.06.04

Сейчас говоря дефрагментирует и LOH

S>>

S>>Фоновый GC для сервера В .NET 4 мы включили фоновый GC для рабочих станций. С того времени мы все чаще наблюдаем использование куч с размерами в диапазоне от нескольких до десятков гигабайт. Даже такому оптимизированному параллельному сборщику, как у нас, могут потребоваться секунды на сбор столь больших куч, а значит, потоки приложения будут блокированы примерно на то же время. Введение фонового GC для сервера обеспечивает поддержку нашим серверным сборщиком параллельных процедур сбора. Это сводит к минимуму длительные блокирующие операции сбора мусора, почти не влияя на высокую пропускную способность приложения.

S>>Если вы используете серверный GC, вам не нужно ничего делать для того, чтобы задействовать преимущества этой новой функциональности; фоновый GC для сервера выполняется автоматически. Высокоуровневые характеристики фонового GC одинаковы как для клиента, так и для сервера:
S>>•в фоне может выполняться только полный GC (объектов поколения 2);
S>>•при фоновом GC сжатие не осуществляется;
S>>•активный (не в фоне) GC (объектов поколений 0 и 1) возможен в процессе фонового GC. Серверный GC выполняется выделенными серверными GC-потоками;
S>>•полностью блокирующий GC также осуществляется выделенными серверными GC-потоками.


EP>А зачем ты привёл это? Оно как-то опровергает мои тезисы?

Про блокировки
и солнце б утром не вставало, когда бы не было меня
Re[42]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 17:13
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Да, сам Linq (а точнее IEnumerable) — это абстракция (кстати, на мой взгляд весьма сомнительная, но это уже дело вкуса). Только вот сама по себе эта абстракция ничего не может. Чтобы она могла работать с контейнерами, базами данных и т.п. требуется подключение соответствующих библиотек. Так вот в C++ (и не только) есть аналогичные библиотеки с аналогичной функциональностью.

S>> EF. Дай ссылочки посмотреть. А внутри Linq деревья выражений.
S>>https://msdn.microsoft.com/ru-ru/library/bb397951.aspx
S>>Я уже приводил ссылки на расширители.

_>https://github.com/rbock/sqlpp11 — один из вариантов. )


Спасибо посмотрю.
_>>>В Xamarin весьма специфическая кроссплатформенность. К примеру GUI надо писать заново под каждую платформу.
S>>Ну вроде как тут уже договорились, что для каждого GUI свой интерфейс либо HTML 5

_>Где это "тут" договорились? ) На Qt я создают один и тот же интерфейс (код) и он работает на всех платформах сразу. Причём на каждой из них выглядит родным.

Там нехило по твоему QT прошлись. Сказав, что это убожество по сравнению с родными инструментами.
Мало того, у меня совсем хреновые формы получаются. Пусть формы проектируют другие. Если, что мне и HTML хватит
и солнце б утром не вставало, когда бы не было меня
Re[42]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 17:16
Оценка:
Здравствуйте, alex_public, Вы писали:

S>> EF. Дай ссылочки посмотреть. А внутри Linq деревья выражений.

S>>https://msdn.microsoft.com/ru-ru/library/bb397951.aspx
S>>Я уже приводил ссылки на расширители.

_>https://github.com/rbock/sqlpp11 — один из вариантов. )


А соединения, Group By итд
Что то мало примеров
и солнце б утром не вставало, когда бы не было меня
Re[39]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 17:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком.

EP>>Я тебя поздравляю, действительно есть задачи где от него нет проблем. Я в первом же сообщении этой ветки тебе сказал что сам частенько использую Python.
S> Ну и? Тогда о чем разговор?

Так я тебе этот вопрос практически в каждом сообщении задаю — к чему ты подводишь? Если к тому что на практике применимы разные языки, с разными технологиями (GC/etc), даже тормозные — так я об этом тебе в первом же ответе сказал.

EP>>Сравниваем. Вариант Boost.Range:

EP>>1. Лаконичнее, красивее.
EP>>2. Быстрее. Там под копотом кстати те самые итераторы.
EP>>3. Выдаёт bidirectional последовательность вместо forward/single pass.
S> Мне все равно.

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

S>А многие подумают, чего это чувак побитовые операции за операции с массивами применяет.


Только первый раз, с непривычки.
LINQ кстати говоря тоже структурно далёк от SQL — от SQL там только ключевые слова. А по сути это монадическая DO-нотация.

S>А насчет быстроты то все зависит от компилятора которые могут в теже итераторы и преобразовываться.


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

S>>>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.

EP>>>>В результате генерируется текст запроса, так понятнее
S> В результате генерируется машинный код на сервере. Есть абстракции. Контекс можно подменить и тогда итогом будет совсем другое.

Так в описываемой мной схеме тоже можно заменить контекст, и тоже итог может быть совсем другими

S>>> В итоге мне наплевать, вто что трансформирутся Linq запрос.

EP>>Да тут в принципе тоже, я про текст запрос сказал, для того чтобы подчеркнуть что трансформация происходит на этапе компиляции.
S> Так я от тебя ссылки и не дождался.

Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем.
Re[39]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 17:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>

S>>> .NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.

EP>>Я на эту тему даже тест проводил
Автор: Evgeny.Panasyuk
Дата: 17.10.13

S>Я давно тесты проводил http://rsdn.ru/forum/design/701354.1
Автор: Serginio1
Дата: 30.06.04


Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.
Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии.

S>Сейчас говоря дефрагментирует и LOH


Видимо не по-умолчанию, это к вопросу о настройках

https://msdn.microsoft.com/en-us/library/system.runtime.gcsettings.largeobjectheapcompactionmode%28v=vs.110%29.aspx
The default value of the LargeObjectHeapCompactionMode property is GCLargeObjectHeapCompactionMode.Default, which indicates that the LOH is not compacted during garbage collections.
If you assign the property a value of GCLargeObjectHeapCompactionMode.CompactOnce, the LOH is compacted during the next full blocking garbage collection, and the property value is reset to GCLargeObjectHeapCompactionMode.Default.

И походу нужно каждый раз взводить.

EP>>А зачем ты привёл это? Оно как-то опровергает мои тезисы?

S> Про блокировки

Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free."
Там сказано что она lock/wait-free?
Re[43]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 17:48
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Где это "тут" договорились? ) На Qt я создают один и тот же интерфейс (код) и он работает на всех платформах сразу. Причём на каждой из них выглядит родным.

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

Где это "там"? ) Ну и сказать можно что угодно. Какое-то значение это будет иметь только в том случае, если это подтверждено аргументами. )
Re[43]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 17:51
Оценка: 4 (1)
Здравствуйте, Serginio1, Вы писали:

_>>https://github.com/rbock/sqlpp11 — один из вариантов. )

S>А соединения, Group By итд
S>Что то мало примеров

Примеров достаточно, целая папка examples в наличие. Вот один файл оттуда, в котором сразу всё видно: https://github.com/rbock/sqlpp11/blob/master/examples/sample.cpp.
Re[40]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 17:52
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>> Я давно не интересовался. Меня GC давно не беспокоит. Только вызываю его при работе с ком.

EP>>>Я тебя поздравляю, действительно есть задачи где от него нет проблем. Я в первом же сообщении этой ветки тебе сказал что сам частенько использую Python.
S>> Ну и? Тогда о чем разговор?

EP>Так я тебе этот вопрос практически в каждом сообщении задаю — к чему ты подводишь? Если к тому что на практике применимы разные языки, с разными технологиями (GC/etc), даже тормозные — так я об этом тебе в первом же ответе сказал.


Что такое тормозные. Я тебе задал вопрос каковы тормоза в реальных приложениях, а не выдранных тормозные тесты. Какова их доля в реальных приложениях?

EP>Конечно тебе всё равно. Всё что не восхваляет твой блаб язык и всё что показывает что в других языках есть аналоги на запрошенные тобой фичи, причём местами более мощные — тебе не интересно.


S>>А многие подумают, чего это чувак побитовые операции за операции с массивами применяет.

EP>Только первый раз, с непривычки.

EP>LINQ кстати говоря тоже структурно далёк от SQL — от SQL там только ключевые слова. А по сути это монадическая DO-нотация.
Потому, что SQL далек от совершенства для интеллисенсе

S>>А насчет быстроты то все зависит от компилятора которые могут в теже итераторы и преобразовываться.


EP>Теоретически может, а на практике это намного тяжелее.

EP>Теоретически, да, сферически компилятор может взять программу на любом языке и выдать супер оптимальный код.
В чем тяжелее? Вся информация есть. Просто не нужно.

S>>>>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.

EP>>>>>В результате генерируется текст запроса, так понятнее
S>> В результате генерируется машинный код на сервере. Есть абстракции. Контекс можно подменить и тогда итогом будет совсем другое.

EP>Так в описываемой мной схеме тоже можно заменить контекст, и тоже итог может быть совсем другими


Где я её не видел Если ты про это https://github.com/rbock/sqlpp11 то там нет твоих | и соединений не увидел, ленивости итд.


S>>>> В итоге мне наплевать, вто что трансформирутся Linq запрос.

EP>>>Да тут в принципе тоже, я про текст запрос сказал, для того чтобы подчеркнуть что трансформация происходит на этапе компиляции.
S>> Так я от тебя ссылки и не дождался.

EP>Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем.

Что то совсем совсем мало гугл выдает. Задай про Linq и тебе куча статей и примеров.
и солнце б утром не вставало, когда бы не было меня
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 17:57
Оценка: 4 (1)
Здравствуйте, Serginio1, Вы писали:

S>А внутри Linq деревья выражений.

S>https://msdn.microsoft.com/ru-ru/library/bb397951.aspx

На C++ для подобных целей уже более двадцати лет используются Expression Templates. Причём порождаемые деревья выражений можно обрабатывать на этапе компиляции.
Используется в разных областях — и в математических/инженерных задачах (например Eigen), и при парсинге(легендарный Spirit), и при генерации запросов(упомянутый sqlpp11), и т.д. и т.п.
А начиная с C++11 — теперь во время компиляции можно обрабатывать и обычные строки, то есть теперь EDSL могут быть и строковыми, при этом проверяемыми/типизируемыми на этапе компиляции.
Re[40]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:00
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>

S>>>> .NET 4.5 мы внесли некоторые изменения для более эффективного использования фрагментов памяти в LOH, особенно в плане того, как мы управляем списком свободной памяти. Изменения относятся к сбору мусора (garbage collection, GC) как на рабочей станции, так и сервере. Но обратите внимание на то, что это не отменяет лимит в 85 000 байтов на размер объекта в LOH.

EP>>>Я на эту тему даже тест проводил
Автор: Evgeny.Panasyuk
Дата: 17.10.13

S>>Я давно тесты проводил http://rsdn.ru/forum/design/701354.1
Автор: Serginio1
Дата: 30.06.04


EP>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

Если потокобезопасная то
http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php

Ну есть и непотокобезопасные

EP>Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии.


S>>Сейчас говоря дефрагментирует и LOH


EP>Видимо не по-умолчанию, это к вопросу о настройках

EP>

EP>https://msdn.microsoft.com/en-us/library/system.runtime.gcsettings.largeobjectheapcompactionmode%28v=vs.110%29.aspx
EP>The default value of the LargeObjectHeapCompactionMode property is GCLargeObjectHeapCompactionMode.Default, which indicates that the LOH is not compacted during garbage collections.
EP>If you assign the property a value of GCLargeObjectHeapCompactionMode.CompactOnce, the LOH is compacted during the next full blocking garbage collection, and the property value is reset to GCLargeObjectHeapCompactionMode.Default.

EP>И походу нужно каждый раз взводить.
Такие ситуации возникают ооочень редко. Зная о них можно и взводить. У меня никогда таких проблем не было. Но я пишу то в основном на 1С.

EP>>>А зачем ты привёл это? Оно как-то опровергает мои тезисы?

S>> Про блокировки

EP>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free."

EP>Там сказано что она lock/wait-free?
В фоновом режиме для прохода по графу нет никаких блокировок.
и солнце б утром не вставало, когда бы не было меня
Re[44]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:01
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Где это "тут" договорились? ) На Qt я создают один и тот же интерфейс (код) и он работает на всех платформах сразу. Причём на каждой из них выглядит родным.

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

_>Где это "там"? ) Ну и сказать можно что угодно. Какое-то значение это будет иметь только в том случае, если это подтверждено аргументами. )

Ветка была про кроссплатформенность. Я не специалист. Поэтому говорю, то что видел. Ты в той вктке вроде тоже был
и солнце б утром не вставало, когда бы не было меня
Re[44]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:03
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>https://github.com/rbock/sqlpp11 — один из вариантов. )

S>>А соединения, Group By итд
S>>Что то мало примеров

_>Примеров достаточно, целая папка examples в наличие. Вот один файл оттуда, в котором сразу всё видно: https://github.com/rbock/sqlpp11/blob/master/examples/sample.cpp.

Во спасибо интересно. А такие как здесь http://infostart.ru/public/402433/
и солнце б утром не вставало, когда бы не было меня
Re[44]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:05
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Примеров достаточно, целая папка examples в наличие. Вот один файл оттуда, в котором сразу всё видно: https://github.com/rbock/sqlpp11/blob/master/examples/sample.cpp.


А это то зачем?
.where(true))
и солнце б утром не вставало, когда бы не было меня
Re[40]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 18:09
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

EP>Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии.

https://www.nuget.org/packages/Nito.Deque
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 18:25
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Ну и? Тогда о чем разговор?

EP>>Так я тебе этот вопрос практически в каждом сообщении задаю — к чему ты подводишь? Если к тому что на практике применимы разные языки, с разными технологиями (GC/etc), даже тормозные — так я об этом тебе в первом же ответе сказал.
S> Что такое тормозные.

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

S>Я тебе задал вопрос каковы тормоза в реальных приложениях


Зачем ты его задал? Я же не утверждал что эти тормоза в каждом приложении критичны. Очевидно что разницу между одной наносекундой, и одной микросекундой никто не заметит.

S>>>А многие подумают, чего это чувак побитовые операции за операции с массивами применяет.

EP>>Только первый раз, с непривычки.
EP>>LINQ кстати говоря тоже структурно далёк от SQL — от SQL там только ключевые слова. А по сути это монадическая DO-нотация.
S> Потому, что SQL далек от совершенства для интеллисенсе

Так зачем говорить что он понятен тем кто знаком с SQL? Там структура совершенно другая.

S>>>А насчет быстроты то все зависит от компилятора которые могут в теже итераторы и преобразовываться.

EP>>Теоретически может, а на практике это намного тяжелее.
EP>>Теоретически, да, сферически компилятор может взять программу на любом языке и выдать супер оптимальный код.
S> В чем тяжелее? Вся информация есть. Просто не нужно.

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

В данном случае C++ легко оптимизировать потому что легко всё заинлайнить, а легко заинлайнить потому что нет ни одного виртуального/косвенного вызова, и нет ни одной аллокации.
При этом да, инлайнить виртуальные/косвенные вызовы тоже возможно на этапе компиляции, но это очевидно труднее — так как требуется более серьёзный анализ.

S>>>>>>> Генерация текста это далеко от того что называется Linq. В Linq вообще отсутствует понятие текста.

EP>>>>>>В результате генерируется текст запроса, так понятнее
S>>> В результате генерируется машинный код на сервере. Есть абстракции. Контекс можно подменить и тогда итогом будет совсем другое.
EP>>Так в описываемой мной схеме тоже можно заменить контекст, и тоже итог может быть совсем другими
S> Где я её не видел Если ты про это https://github.com/rbock/sqlpp11 то там нет твоих |

Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11.

S>и соединений не увидел,


Выше уже привели ссылку.

S>ленивости итд.


Ленивость важна в контексте контейнеров, приведённый пример Boost.Range — ленивый. Если не веришь — могу доказать тестом.
Касательно sqlp11 — там есть пример использования с контейнерами — он может быть реализован как лениво, так и энергично, как именно — мне лень смотреть, так как я использую более удобный для этой цели Boost.Range.
Или ты о какой ленивости?

EP>>Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем.

S> Что то совсем совсем мало гугл выдает.

Ну не знаю, может у тебя google другой — http://lmgtfy.com/?q=sqlpp11 . У меня в выдаче первая ссылка на этот проект.

S>Задай про Linq и тебе куча статей и примеров.


И что?
Re[42]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:30
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>А внутри Linq деревья выражений.

S>>https://msdn.microsoft.com/ru-ru/library/bb397951.aspx

EP>На C++ для подобных целей уже более двадцати лет используются Expression Templates. Причём порождаемые деревья выражений можно обрабатывать на этапе компиляции.

EP>Используется в разных областях — и в математических/инженерных задачах (например Eigen), и при парсинге(легендарный Spirit), и при генерации запросов(упомянутый sqlpp11), и т.д. и т.п.
EP>А начиная с C++11 — теперь во время компиляции можно обрабатывать и обычные строки, то есть теперь EDSL могут быть и строковыми, при этом проверяемыми/типизируемыми на этапе компиляции.
Вот интересная статья http://habrahabr.ru/post/256821/
и солнце б утром не вставало, когда бы не было меня
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 18:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

S>Если потокобезопасная то
S>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php

Какая из них конкретно?

S>Ну есть и непотокобезопасные


В той теме так и не привели.

EP>>>>А зачем ты привёл это? Оно как-то опровергает мои тезисы?

S>>> Про блокировки
EP>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free."
EP>>Там сказано что она lock/wait-free?
S> В фоновом режиме для прохода по графу нет никаких блокировок.

А что ты понимаешь под блокировкой? Stop-the-world?
Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных.
Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано.
Re[45]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 18:38
Оценка:
Здравствуйте, Serginio1, Вы писали:

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

_>>Где это "там"? ) Ну и сказать можно что угодно. Какое-то значение это будет иметь только в том случае, если это подтверждено аргументами. )
S> Ветка была про кроссплатформенность. Я не специалист. Поэтому говорю, то что видел. Ты в той вктке вроде тоже был

Тут часто обсуждают такие вещи, но я что-то не помню чтобы кто-то говорил про убогость Qt — всё же это один из лидирующих в мире инструментов. ))) У него конечно же есть куча своих недостатков (типа надстройки над C++ и т.п.), про которые я сам всегда упоминаю. Но на фоне остальных (где проблемы не во внутренней архитектуре, а в вообще отсутствие необходимой функциональности) всё очень даже не плохо.
Re[42]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:41
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


S>> Потому, что SQL далек от совершенства для интеллисенсе


EP>Так зачем говорить что он понятен тем кто знаком с SQL? Там структура совершенно другая.

Я этого не говорил. Я говорил только про битовые операции


S>> В чем тяжелее? Вся информация есть. Просто не нужно.


EP>Ещё раз "вся информация" может быть сильно разной. Вся информация есть и в динамически типизированных языках, и теоретически компилятор может применить максимально возможную оптимизацию.

Где то и проводит.

EP>В данном случае C++ легко оптимизировать потому что легко всё заинлайнить, а легко заинлайнить потому что нет ни одного виртуального/косвенного вызова, и нет ни одной аллокации.

EP>При этом да, инлайнить виртуальные/косвенные вызовы тоже возможно на этапе компиляции, но это очевидно труднее — так как требуется более серьёзный анализ.

В большинстве это и не нужно. А виртуальные помогают конструировать иерархию и доступ к неопределенным типам через интерфейсы
http://infostart.ru/public/402038/




EP>Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11.


А в Net это встроено в платформу.
S>>и соединений не увидел,

EP>Выше уже привели ссылку.


EP>Или ты о какой ленивости?

Я ссылку уже видел. Давно от вас ждал. Но все равно мало примеров. Хотя верю, что можно.

EP>>>Я приводил — sqlpp11, первая ссылка в Google, или например на YouTube. Там очень близко к тому что я описал, в том числе есть возможность работать по контейнерам, правда это особо не зачем.

S>> Что то совсем совсем мало гугл выдает.

EP>Ну не знаю, может у тебя google другой — http://lmgtfy.com/?q=sqlpp11 . У меня в выдаче первая ссылка на этот проект.


S>>Задай про Linq и тебе куча статей и примеров.


EP>И что?

Казалось бы
и солнце б утром не вставало, когда бы не было меня
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 18:42
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

EP>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

EP>>Это по сути random-access последовательность состоящая из chunk'ов фиксированного размера — это позволило бы обходить проблемы с фрагментацией даже на старой LOH стратегии.
K>https://www.nuget.org/packages/Nito.Deque

Судя по "amortized O(1) access to both front and back" — там реализация не на chunk'ах, а на одном массиве. Для того чтобы обходить проблемы с фрагментацией требуется именно на chunk'ах.
Re[42]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 18:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

S>>Если потокобезопасная то
S>>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php

EP>Какая из них конкретно?

Бери какой хочешь. Для этого нужно знать, что ты под std::deque
S>>Ну есть и непотокобезопасные

EP>В той теме так и не привели.

Ты на год посмотри 30.06.04
Тогда мало чего было. Еще Net 1.1 был без дженериков итд.

EP>>>>>А зачем ты привёл это? Оно как-то опровергает мои тезисы?

S>>>> Про блокировки
EP>>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free."
EP>>>Там сказано что она lock/wait-free?
S>> В фоновом режиме для прохода по графу нет никаких блокировок.

EP>А что ты понимаешь под блокировкой? Stop-the-world?

EP>Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных.
EP>Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано.
Там может быть куча стратегий. Суть в том, что с каждой новой версией GC работает все быстрее. Если раньше были видны тормоза, то сейчас об этом все забыли
и солнце б утром не вставало, когда бы не было меня
Re[45]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 18:47
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Примеров достаточно, целая папка examples в наличие. Вот один файл оттуда, в котором сразу всё видно: https://github.com/rbock/sqlpp11/blob/master/examples/sample.cpp.

S> Во спасибо интересно. А такие как здесь http://infostart.ru/public/402433/

Ну так все необходимые элементы же имеются. Так что никаких проблем в создание точной копии данных примеров не вижу. Разве что есть только один вариант записи (только через точку), а не два, как в C#.

Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...
Re[46]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 04.10.15 19:00
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Примеров достаточно, целая папка examples в наличие. Вот один файл оттуда, в котором сразу всё видно: https://github.com/rbock/sqlpp11/blob/master/examples/sample.cpp.

S>> Во спасибо интересно. А такие как здесь http://infostart.ru/public/402433/

_>Ну так все необходимые элементы же имеются. Так что никаких проблем в создание точной копии данных примеров не вижу. Разве что есть только один вариант записи (только через точку), а не два, как в C#.


_>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...



Ну ка расскажи, как ты динамические запросы формируешь на этапе компиляции?
Re[46]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 19:07
Оценка:
Здравствуйте, alex_public, Вы писали:

_

_>Ну так все необходимые элементы же имеются. Так что никаких проблем в создание точной копии данных примеров не вижу. Разве что есть только один вариант записи (только через точку), а не два, как в C#.


_>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...

Ну часто используемы запросы можно компилировать да и затраты на трансляцию мизерные
http://www.codeproject.com/Articles/38174/How-to-improve-your-LINQ-query-performance-by-X дольше сам запрос выполняется
вот поновее
http://blogs.msdn.com/b/ricom/archive/2008/01/14/performance-quiz-13-linq-to-sql-compiled-query-cost-solution.aspx
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.10.2015 19:10 Serginio1 . Предыдущая версия .
Re[43]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 19:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Потому, что SQL далек от совершенства для интеллисенсе

EP>>Так зачем говорить что он понятен тем кто знаком с SQL? Там структура совершенно другая.
S> Я этого не говорил. Я говорил только про битовые операции

ОК, видимо перепутал.
Тем не менее, с битовой операцией всё просто: "Что это? Битовая операция? А, пайп — всё понятно".
А с LINQ'ом же получается: "Что это? SQL запрос? А, монадическая нотация" — это при том что с монадами мало кто знаком, либо считают их чем-то трудно понимаемым. В любом случае разница кардинальная, как бы её не ретушировали ключевыми словами.

EP>>При этом да, инлайнить виртуальные/косвенные вызовы тоже возможно на этапе компиляции, но это очевидно труднее — так как требуется более серьёзный анализ.

S> В большинстве это и не нужно.

В любом случае, это намного тяжелее, несмотря на то что "вся информация есть".

S>А виртуальные помогают конструировать иерархию и доступ к неопределенным типам через интерфейсы


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

EP>>Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11.

S>А в Net это встроено в платформу.

Так это известная тема — вместо предоставления какой-то универсальной возможности, на C# решают какой-то сиюминутный use-case. Это приводит например к зоопарку с вариантами замыканий, которые даже ещё планируют расширять локальными методами. Также это приводит к меньшей гибкости самого языка — шаг влево/вправо — и упираешься в забор: 1
Автор: _NN_
Дата: 02.11.13
, 2
Автор: Evgeny.Panasyuk
Дата: 07.06.15
, 3
Автор: Qbit86
Дата: 01.07.15
, 4
Автор: Tesh
Дата: 21.04.15
.
Re[43]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 19:17
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

S>>>Если потокобезопасная то
S>>>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php
EP>>Какая из них конкретно?
S> Бери какой хочешь. Для этого нужно знать, что ты под std::deque

Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией.

S>>>Ну есть и непотокобезопасные

EP>>В той теме так и не привели.
S> Ты на год посмотри 30.06.04
S>Тогда мало чего было. Еще Net 1.1 был без дженериков итд.

Я про тему на которую сам дал ссылку.

EP>>>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free."

EP>>>>Там сказано что она lock/wait-free?
S>>> В фоновом режиме для прохода по графу нет никаких блокировок.
EP>>А что ты понимаешь под блокировкой? Stop-the-world?
EP>>Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных.
EP>>Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано.
S> Там может быть куча стратегий. Суть в том, что с каждой новой версией GC работает все быстрее. Если раньше были видны тормоза, то сейчас об этом все забыли

Понятное дело, это видно в том числе и в моём тесте. Но я-то говорил про конкретный аспект.
Re[44]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 19:21
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:



EP>>>Так | это другая библиотека, ты за контекстом следишь? | это Boost.Range, а тут sqlpp11.

S>>А в Net это встроено в платформу.

EP>Так это известная тема — вместо предоставления какой-то универсальной возможности, на C# решают какой-то сиюминутный use-case. Это приводит например к зоопарку с вариантами замыканий, которые даже ещё планируют расширять локальными методами. Также это приводит к меньшей гибкости самого языка — шаг влево/вправо — и упираешься в забор: 1
Автор: _NN_
Дата: 02.11.13
, 2
Автор: Evgeny.Panasyuk
Дата: 07.06.15
, 3
Автор: Qbit86
Дата: 01.07.15
, 4
Автор: Tesh
Дата: 21.04.15
.

Для многих вещей существуют T4 или Nemerle в руки. Было бы желание. Либо функциональщину с карированием итд которая тоже в Net есть, а их использовать уже в C#. На самом деле важные фичи добавляются. И язык развивается. А для среднестатистического программиста как я возможностей выше крыши. Просто такие извращения появляются у С++ которые хотят перенести технику шаблонов перенести на язык которых их не поддерживает. И Слава КПСС
и солнце б утром не вставало, когда бы не было меня
Re[47]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 19:23
Оценка: -1
Здравствуйте, Klikujiskaaan, Вы писали:

K>Ну ка расскажи, как ты динамические запросы формируешь на этапе компиляции?


При желании можно и динамические Схему я показывал здесь
Автор: Evgeny.Panasyuk
Дата: 14.04.15
.
Re[44]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 19:27
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>Кстати, может ты знаешь, есть ли какая-нибудь нормальная/популярная реализация аналога std::deque для C#/.NET? В той теме так ничего и не привели.

S>>>>Если потокобезопасная то
S>>>>http://professorweb.ru/my/csharp/charp_theory/level12/12_15.php
EP>>>Какая из них конкретно?
S>> Бери какой хочешь. Для этого нужно знать, что ты под std::deque

EP>Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией.


Ну например можно такой http://rsdn.ru/forum/src/450320.1
Автор: Serginio1
Дата: 20.11.03


S>>>>Ну есть и непотокобезопасные

EP>>>В той теме так и не привели.
S>> Ты на год посмотри 30.06.04
S>>Тогда мало чего было. Еще Net 1.1 был без дженериков итд.

EP>Я про тему на которую сам дал ссылку.


EP>>>>>Что именно? Вот это? "Точно — конкурентная гадость, которая скорей всего не lock-free."

EP>>>>>Там сказано что она lock/wait-free?
S>>>> В фоновом режиме для прохода по графу нет никаких блокировок.
EP>>>А что ты понимаешь под блокировкой? Stop-the-world?
EP>>>Так речь же не об этом, а о гонках возникающих при обходе графа из одного потока, и изменениях этого же графа из других, и им подобных.
EP>>>Есть статьи описывающие lock-free реализации, но как я понял нигде в mainstream это не реализовано.
S>> Там может быть куча стратегий. Суть в том, что с каждой новой версией GC работает все быстрее. Если раньше были видны тормоза, то сейчас об этом все забыли

EP>Понятное дело, это видно в том числе и в моём тесте. Но я-то говорил про конкретный аспект.

Ты не забывай, что с 1С ником разговариваешь. C# для меня хобби. Тем более я не знаю какой сейчас алгоритм сборки мусораэ
и солнце б утром не вставало, когда бы не было меня
Re[45]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 19:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Так это известная тема — вместо предоставления какой-то универсальной возможности, на C# решают какой-то сиюминутный use-case. Это приводит например к зоопарку с вариантами замыканий, которые даже ещё планируют расширять локальными методами. Также это приводит к меньшей гибкости самого языка — шаг влево/вправо — и упираешься в забор: 1
Автор: _NN_
Дата: 02.11.13
, 2
Автор: Evgeny.Panasyuk
Дата: 07.06.15
, 3
Автор: Qbit86
Дата: 01.07.15
, 4
Автор: Tesh
Дата: 21.04.15
.

S> Для многих вещей существуют T4

О, пошла кодогенерация в ход Да она расширяет возможности, и доступна в том числе и для C++, причём без зацикленности на T4.
Тем не менее, доступность возможности из самого языка, а не системы сборки — это на порядки проще и удобнее.
Например тот же not_null
Автор: Tesh
Дата: 21.04.15
или option
Автор: Qbit86
Дата: 01.07.15
— попробуй их заменить через T4.

S>Было бы желание. Либо функциональщину с карированием итд которая тоже в Net есть, а их использовать уже в C#. На самом деле важные фичи добавляются. И язык развивается. А для среднестатистического программиста как я возможностей выше крыши. Просто такие извращения появляются у С++ которые хотят перенести технику шаблонов перенести на язык которых их не поддерживает. И Слава КПСС


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

Non-nullability checks have to be manually encoded hundreds of times in any large real-world project, and they are not compile-time-enforced.

Отредактировано 04.10.2015 19:38 Evgeny.Panasyuk . Предыдущая версия .
Re[45]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 19:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией.

S>Ну например можно такой http://rsdn.ru/forum/src/450320.1
Автор: Serginio1
Дата: 20.11.03


Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать.
Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь.

S> Ты не забывай, что с 1С ником разговариваешь. C# для меня хобби. Тем более я не знаю какой сейчас алгоритм сборки мусораэ


Так 1С-ники ведь разные бывают
Re[47]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 19:57
Оценка: +1
Здравствуйте, Klikujiskaaan, Вы писали:

_>>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...

K>Ну ка расскажи, как ты динамические запросы формируешь на этапе компиляции?

Что ты подразумеваешь под динамическими запросами? )
Re[47]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 20:17
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...

S>Ну часто используемы запросы можно компилировать да и затраты на трансляцию мизерные
S>http://www.codeproject.com/Articles/38174/How-to-improve-your-LINQ-query-performance-by-X дольше сам запрос выполняется
S>вот поновее
S>http://blogs.msdn.com/b/ricom/archive/2008/01/14/performance-quiz-13-linq-to-sql-compiled-query-cost-solution.aspx

Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1
Автор: gandjustas
Дата: 13.04.15
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.

Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.
Re[46]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 20:28
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Нужна O(1) random access последовательность, реализованная на chunk'ах, для использования в качестве альтернативы .NET List, для того чтобы избежать проблем с фрагментацией.

S>>Ну например можно такой http://rsdn.ru/forum/src/450320.1
Автор: Serginio1
Дата: 20.11.03


EP>Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать.

EP>Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь.
На самом деле в Net много чего нет. Тех же Б+ деревьев
S>> Ты не забывай, что с 1С ником разговариваешь. C# для меня хобби. Тем более я не знаю какой сейчас алгоритм сборки мусораэ

EP>Так 1С-ники ведь разные бывают

и солнце б утром не вставало, когда бы не было меня
Re[48]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 20:37
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ну и кстати, это ещё и работает намного быстрее, чем EF. В данном случае не за счёт крутых оптимизаторов C++ или чего-то подобного, а за счёт метапрограммирования — запросы формируются во время компиляции, а не во время исполнения. Да, для какого-нибудь решения из области 1C подобное ускорение конечно же не принципиально. А вот в случае высоконагруженных веб-серверов это становится уже очень принципиально...

S>>Ну часто используемы запросы можно компилировать да и затраты на трансляцию мизерные
S>>http://www.codeproject.com/Articles/38174/How-to-improve-your-LINQ-query-performance-by-X дольше сам запрос выполняется
S>>вот поновее
S>>http://blogs.msdn.com/b/ricom/archive/2008/01/14/performance-quiz-13-linq-to-sql-compiled-query-cost-solution.aspx

_>Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1
Автор: gandjustas
Дата: 13.04.15
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.

По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.

_>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.


Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx
и солнце б утром не вставало, когда бы не было меня
Re[47]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 20:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать.

EP>>Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь.
S> На самом деле в Net много чего нет. Тех же Б+ деревьев

Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней.
Re[48]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.10.15 21:01
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Да, я об этом и говорю. Только меня интересуют распространённая/популярная версия. Так-то понятно что можно самому сделать.

EP>>>Дело в том что в той теме сетовали на фрагментацию, мол она там очень страшная, такая страшная что List нормально нельзя использовать — раз это так, то по-идее должна была быть какая-то распространённая реализация массива на chunk'ах, поэтому я и интересуюсь.
S>> На самом деле в Net много чего нет. Тех же Б+ деревьев

EP>Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней.

Не совсем http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

Внизу результаты
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.10.2015 21:02 Serginio1 . Предыдущая версия .
Re[49]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 04.10.15 21:10
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней.

S>Не совсем http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

S>Внизу результаты

Преимущества B+ я понимаю. Но тут же речь не о лучше/хуже, а о том что можно нарваться на Out of Memory на ровном месте.
Re[49]: Java vs C# vs C++
От: alex_public  
Дата: 04.10.15 23:35
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

_>>Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1
Автор: gandjustas
Дата: 13.04.15
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.

S> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.

Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )

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

_>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.

S>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx

Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.
Re[48]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.10.15 07:30
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1
Автор: gandjustas
Дата: 13.04.15
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.


_>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.

Ну не такие они и страшные и неудобные. Если хочешь скорости то написать 2 лишние строчки не проблема.
Зато боддержка нотификаций, слежение за изменениями. Ты не забывай, что это может вставляться в разные гриды итд
и солнце б утром не вставало, когда бы не было меня
Re[50]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.10.15 07:36
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Да, но их в какой-то мере можно заменить чем-то типа SortedSet. Но тут-то получается была реальная необходимость, поэтому я и удивляюсь почему нет популярной реализации, пусть даже и сторонней.

S>>Не совсем http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

S>>Внизу результаты

EP>Преимущества B+ я понимаю. Но тут же речь не о лучше/хуже, а о том что можно нарваться на Out of Memory на ровном месте.

На самом деле вариантов работы с такими объемами очень редки.
Читаем здесь
http://habrahabr.ru/post/149584/

Что же насчет Large Object Heap? Она никогда не дефрагментируется (почти никогда). Это потребовало бы большое количество времени, что может сказаться плохо на работе приложения. Однако это не значит, что CLR начинает потреблять все больше и больше памяти просто так. Во время Full-GC (Gen0, Gen1, Gen2) система все же возвращает ОС память, освобождаясь от уже мертвых объектами из LOH (или дефрагментацией SOH).


Также CLR располагает новые объекты в LOH не только один за другим, как в SOH, например, но и на местах уже свободной памяти, не дожидаясь Full-GC.
Запуск GC не детерминирован, за исключением вызова метода GC.Collect().

Однако все же существуют приблизительные критерии, по которым можно это предсказать (следует помнить, что нижеперечисленные условия приблизительны и CLR сама приспосабливается к поведению приложения, многое еще зависит и от вида сборщика мусора):
•При достижении поколения Gen0 размера в 256 KB
•При достижении поколения Gen1 размера в 2 MB
•При достижении поколения Gen2 размера в 10 MB

Также сборка мусора запускается при нехватке системой памяти. CLR для этого использует Win32-функции CreateMemoryResourceNotification и QueryMemoryResourceNotification.

и солнце б утром не вставало, когда бы не было меня
Re[50]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.10.15 07:41
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1
Автор: gandjustas
Дата: 13.04.15
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.

S>> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.

_>Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )


_>В общем делать высоконагруженный сервис с помощью такой хреновины мягко говоря не разумно. )))

разумно предварительно скомпилировав часто используемые запросы. Не вижу проблем.
А запрос обычно выполняется значительно дольше. Даже просто перекачка данных по сети.

_>>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.

S>>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx



_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.


Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя.
Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.
и солнце б утром не вставало, когда бы не было меня
Re[50]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.10.15 08:41
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Не такие уж и мизерные затраты: http://rsdn.ru/forum/flame.comp/6013262.1
Автор: gandjustas
Дата: 13.04.15
. Причём это там ещё речь шла о linq2db, который намного эффективнее EF.

S>> По ссылкам это миллисекунды. Linq To EF от версии к версии совершенствуется.

_>Ну так миллисекунды — это как раз совсем печально. Скажем если запрос к БД у нас будет исполняться тоже несколько миллисекунд (абсолютно реальный сценарий с современными СУБД), то это означает 50% потери производительности. Ведь в этом случае код на C# будет заниматься никчемной деятельностью (подготовкой к запросу) столько же, сколько и сам запрос. В аналогичном же коде на C++ у нас будет 0 секунд на подготовку запроса (т.е. как при рукопашном коде с зашитой sql строкой). )


_>В общем делать высоконагруженный сервис с помощью такой хреновины мягко говоря не разумно. )))


_>>>Что касается предварительной компиляции, то это уже как раз ведёт к страшному и неудобному коду. В то время как sqlpp11 действует так же всегда и при удобном коде.

S>>Все течет все меняется https://msdn.microsoft.com/en-us/data/hh949853.aspx

_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.


Если не нравится то голый SQL в руки или предварительная компиляция. Каждый выбирает для себя.
Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.
https://msdn.microsoft.com/ru-ru/library/bb896297(v=vs.110).aspx

Начиная с версии 4.5 платформы .NET Framework, запросы LINQ кэшируются автоматически. Тем не менее можно использовать скомпилированные запросы LINQ для снижения затрат при последующем выполнении, и скомпилированные запросы могут быть более эффективными, чем запросы LINQ, которые автоматически сохраняются в кэше. Обратите внимание, что запросы LINQ to Entities, которые применяют оператор Enumerable.Contains к коллекции в памяти, автоматически не кэшируются. Также в скомпилированных запросах LINQ не допускаются коллекции в памяти с параметрами.

и солнце б утром не вставало, когда бы не было меня
Re[38]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 10:12
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Сравниваем. Вариант Boost.Range:

EP>1. Лаконичнее, красивее.

А всякие _1 это полагаю эталон красоты ? А если надо сравнивать не с константой ?

EP>2. Быстрее. Там под копотом кстати те самые итераторы.


Для ленивого кода — даже не смешно.

EP>3. Выдаёт bidirectional последовательность вместо forward/single pass.


Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007.
Бидирекшинал это очень жосткое органичение само по себе.
Re[50]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.10.15 11:51
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.


Кстати а как заранее компилировать такие запросы

 public  IQueryable<TEntity> НайтиПоВхождениюВНаименование<TEntity>(paramsstring[] keywords) where TEntity : СправочникПредок

        {

            var predicate = PredicateBuilder.False<TEntity>();

 

            foreach (string keyword in keywords)

            {

                string temp = keyword;

                predicate = predicate.Or(p => p.Наименование.Contains(temp));

            }

            return this.Set<TEntity>().AsExpandable().Where(predicate);

        }





И использовать



var бд = Константы1С.ГлобальныйКонтекст.БД;

 

            var запрос = бд.НайтиПоВхождениюВНаименование<Справочник.Номенклатура>("Linq", "Наше", "Все").Select(товар => товар.Наименование);

 

            foreach (var товар in запрос)

            {

 

                Console.WriteLine("{0} ", товар);

 

            }



Генерируется следующий запрос



SELECT

    [Extent1].[DESCR] AS [DESCR]

    FROM [dbo].[SC84] AS [Extent1]

 

    WHERE ([Extent1].[DESCR] LIKE @p__linq__0 ESCAPE N'~') 

          OR([Extent1].[DESCR] LIKE @p__linq__1 ESCAPE N'~') 

          OR([Extent1].[DESCR] LIKE @p__linq__2 ESCAPE N'~')



Поясню. Есть обобщенная функция с ограничением на СправочникПредок в котором есть свойство Номенклатура в которую подается список строк.
Запрос возвращает все элементы которые содержат в наименовании любую строку из списка
и солнце б утром не вставало, когда бы не было меня
Отредактировано 05.10.2015 12:03 Serginio1 . Предыдущая версия .
Re[51]: Java vs C# vs C++
От: alex_public  
Дата: 05.10.15 12:05
Оценка: +1 :)
Здравствуйте, Serginio1, Вы писали:

S> Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя.

S>Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.

Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.
Re[52]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.10.15 12:12
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>> Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя.

S>>Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.

_>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.


Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.
Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.

http://www.codehint.ru/articles/2013-02-13_linq_entity_framework_5

В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.


Мало того, можно кэшировать результаты запросов
https://weblogs.asp.net/dotnetstories/using-second-level-cache-in-entity-framework-6-1-applications
https://github.com/loresoft/EntityFramework.Extended/wiki/Query-Result-Cache
и солнце б утром не вставало, когда бы не было меня
Отредактировано 05.10.2015 13:49 Serginio1 . Предыдущая версия . Еще …
Отредактировано 05.10.2015 13:41 Serginio1 . Предыдущая версия .
Отредактировано 05.10.2015 12:16 Serginio1 . Предыдущая версия .
Re[39]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 13:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>Сравниваем. Вариант Boost.Range:

EP>>1. Лаконичнее, красивее.
I>А всякие _1 это полагаю эталон красоты ?

Да, это самый короткий и лаконичный вариант.

I>А если надо сравнивать не с константой ?


Без проблем.

EP>>2. Быстрее. Там под копотом кстати те самые итераторы.

I>Для ленивого кода — даже не смешно.

Расшифруй.

EP>>3. Выдаёт bidirectional последовательность вместо forward/single pass.

I>Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007.

В этом случае Bidirectional, в других Random. В то время как на LINQ приходится делать копии убивающие ленивость.

I>Бидирекшинал это очень жосткое органичение само по себе.


Так Forward/Single Pass ещё жёстче.
Re[40]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 13:31
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>А всякие _1 это полагаю эталон красоты ?


EP>Да, это самый короткий и лаконичный вариант.


Это просто зипование-обфускация кода.

I>>А если надо сравнивать не с константой ?


EP>Без проблем.


Не верю

EP>>>2. Быстрее. Там под копотом кстати те самые итераторы.

I>>Для ленивого кода — даже не смешно.

EP>Расшифруй.


Очень просто — для ленивого кода производительность это сильно второстепенный показатель.

EP>>>3. Выдаёт bidirectional последовательность вместо forward/single pass.

I>>Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007.
EP>В этом случае Bidirectional, в других Random. В то время как на LINQ приходится делать копии убивающие ленивость.

Ты бы поменьше врал, что ли ? Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.
Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для
while (true){ yield return Guid.New(); }

Код в студию. Оправдания и всякие "но... а вот я... а давай по другому..." не принимаются.
Не нравится этот вариант — покажи, скажем, получение данных от DB и тд

I>>Бидирекшинал это очень жосткое органичение само по себе.


EP>Так Forward/Single Pass ещё жёстче.


Ога. См пример выше.
Отредактировано 05.10.2015 13:38 Pauel . Предыдущая версия .
Re[52]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 13:36
Оценка: :)
Здравствуйте, alex_public, Вы писали:

_>В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.


Ну да, сначала 3-5 лет нарабатывать квалификацию и вырабатывать условные рефлексы, одевая штаны через голову, а потом всё просто — норма.

Самое интересное, что среди плюсовиков крайне мало людей, которые умеют писать и быстрый и удобный и стабильный код. Я бы сказал случаи единичные.

Сейчас найм внятных плюсовиков это сумасшедший головняк для HR, хуже наверное только найм всякой экзотики или какого лиспа.
Re[50]: Java vs C# vs C++
От: Klikujiskaaan КНДР  
Дата: 05.10.15 14:20
Оценка: -1
Здравствуйте, alex_public, Вы писали:


_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.


Ты бы про ту ссылку забыл и не вспоминал, тебя там тыкали головой в твое невежество и незнание БД весь топик.
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 14:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>А если надо сравнивать не с константой ?

EP>>Без проблем.
I>Не верю

Мне всё равно, в корутины ты тоже не верил

EP>>>>2. Быстрее. Там под копотом кстати те самые итераторы.

I>>>Для ленивого кода — даже не смешно.
EP>>Расшифруй.
I>Очень просто — для ленивого кода производительность это сильно второстепенный показатель.

Аргументы?

EP>>>>3. Выдаёт bidirectional последовательность вместо forward/single pass.

I>>>Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007.
EP>>В этом случае Bidirectional, в других Random. В то время как на LINQ приходится делать копии убивающие ленивость.
I>Ты бы поменьше врал, что ли ?

Проходили уже, сначала ты десятки страниц кричишь вывсёврёте, этовсёнеправда, а потом "ой".

I>Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.


Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional

I>Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для


Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.
Re[42]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 14:49
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Без проблем.

I>>Не верю

EP>Мне всё равно, в корутины ты тоже не верил


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

EP>>>Расшифруй.

I>>Очень просто — для ленивого кода производительность это сильно второстепенный показатель.

EP>Аргументы?


Ленивость, если отбросить твои любимые массивы, есть это отказ от "тянем всё целиком и долго-долго считаем" в пользу "грузими кусочками", "считаем кусочками".
Т.е. сознательно вводим задержки по времени.

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

I>>Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.


EP>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional


Это синтетика.

I>>Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для

EP>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.

Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где

1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд
2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику
Re[43]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 15:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>>>Без проблем.

I>>>Не верю
EP>>Мне всё равно, в корутины ты тоже не верил
I>Если точнее, ты отрицал и продолжаешь отрицать наличие проблем из за внедрения короутин.

Ты отрицал что пример заработает, даже смотря на рабочий код, а потом что-то щёлкнуло и "ой".

EP>>>>Расшифруй.

I>>>Очень просто — для ленивого кода производительность это сильно второстепенный показатель.
EP>>Аргументы?
I>Ленивость, если отбросить твои любимые массивы, есть это отказ от "тянем всё целиком и долго-долго считаем" в пользу "грузими кусочками", "считаем кусочками".
I>Т.е. сознательно вводим задержки по времени.
I>Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки !
I>По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки !
I>То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки.

Ты думаешь о каком-то частном случае, и пытаешься распространить его свойства на другие.
Про время выполнения например это не верно например в случае бесконечных списков

I>>>Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.


EP>>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional

I> Это синтетика.

Random Access это синтетика?

I>>>Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для

EP>>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.
I>Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где
I>1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд
I>2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику

В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг.
Re[53]: Java vs C# vs C++
От: alex_public  
Дата: 05.10.15 15:51
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

_>>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.

S> Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.

А что не так с Питоном? ) Он у нас позволяет очень удобно писать очень медленный код. Соответственно в тех случаях, когда подобное быстродействие приемлемо (например для скриптов), абсолютно логично использовать именно его. Так же как ты скажем используешь медленный 1C для всяких там бухгалтерий и т.п.

S> Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.


Это всё не то. Нужна предкомпиляция, а не кэширование.

S>http://www.codehint.ru/articles/2013-02-13_linq_entity_framework_5

S>

S>В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.


Фоновый поток для таких целей? ) Ужасы какие... Наверное ещё и с блокировками какими-нибудь? )))

S>Мало того, можно кэшировать результаты запросов

S>https://weblogs.asp.net/dotnetstories/using-second-level-cache-in-entity-framework-6-1-applications
S>https://github.com/loresoft/EntityFramework.Extended/wiki/Query-Result-Cache

А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение.
Re[53]: Java vs C# vs C++
От: alex_public  
Дата: 05.10.15 15:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.

I>Ну да, сначала 3-5 лет нарабатывать квалификацию и вырабатывать условные рефлексы, одевая штаны через голову, а потом всё просто — норма.
I>Самое интересное, что среди плюсовиков крайне мало людей, которые умеют писать и быстрый и удобный и стабильный код. Я бы сказал случаи единичные.
I>Сейчас найм внятных плюсовиков это сумасшедший головняк для HR, хуже наверное только найм всякой экзотики или какого лиспа.

Ну да, чудес не бывает и за всё надо платить. По счастью в России (ну или во всяком случае в Москве ) это пока не особо тяжёлая проблема.
Re[44]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 16:02
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>Ты отрицал что пример заработает, даже смотря на рабочий код, а потом что-то щёлкнуло и "ой".


Ты ври да не завирайся. Разговор был про две основных вещи
1 нереэнтерабельный код
2 эвентлуп

В _частном_ случае может работать и это всё что ты показал. То есть,
1 ты прибил логику гвоздями к эвентлупу, тот самый ресайз и тд и тд
2 в твоем коде не было нереэнтерабельного кода
Потому и работает

В общем случае ты вводишь в софтину ничем не ограниченую реэнтерабельность из за кооперативной многозадачности.
Объясняю в очередной раз
void нереэнтерабельнаяФункция() {
    var xOld = x;
    x = newX();
    ...
    stream.read(); // здесь будет переключение из за короутины 
                       // и где нибудь еще возможен повторый вызов нереэнтерабельнаяФункция()
    ...
    x = xOld();
}


Ну и про эвентлуп всё в силе — должен быть или явный вызов или возврат, в противном случае короутина может спокойно перекидывать управление туда-сюда минуя эвентлуп. Это же элементарно — вариант вида "бесконечный ping-pong" ровно ничем не отличается от "while(true){}". Всегда должен быть явный вызов продолжения основной нитки. Если бы ты не прибил гвоздями код к эвентлупу, увидел бы это самостоятельно.

I>>Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки !

I>>По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки !
I>>То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки.

EP>Ты думаешь о каком-то частном случае, и пытаешься распространить его свойства на другие.


Это и есть общий случай.

EP>Про время выполнения например это не верно например в случае бесконечных списков


Ровно наоборот, обрабатывать бесконечный список ленивым кодом элементарно.

EP>>>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional

I>> Это синтетика.
EP>Random Access это синтетика?

Ленивая работа с массивами это синтетика.

EP>>>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.

I>>Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где
I>>1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд
I>>2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику

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


Алё — производительность вычисления одного кусочка не меняется. Производительность вычисления всей цепочки — дерградирует на порядки. Ради того и оптимизуется. Издержки ленивого кода в пересчете на одну порцию ничтожны. Пару виртуальных вызовов что бы получить следующую порцию данных.

А вот на синтетике вида "посчитаем сумму элементов массива ленивым способом" будет разница может и в 100 раз. Это ни о чем.
Re[45]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 16:32
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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

EP>>Ты отрицал что пример заработает, даже смотря на рабочий код, а потом что-то щёлкнуло и "ой".
I>Ты ври да не завирайся. Разговор был про две основных вещи
I>1 нереэнтерабельный код
I>2 эвентлуп
I>В _частном_ случае может работать и это всё что ты показал.

Врёшь. Ты сам предложил конкретную тему примера и верищал про подвигший UI, и не надо приплетать сюда реэнтрабельность. Вот одна из веток
Автор: Evgeny.Panasyuk
Дата: 08.07.13
, по ней вниз/вверх.

I>>>Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки !

I>>>По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки !
I>>>То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки.
EP>>Ты думаешь о каком-то частном случае, и пытаешься распространить его свойства на другие.
I>Это и есть общий случай.
EP>>Про время выполнения например это не верно например в случае бесконечных списков
I>Ровно наоборот, обрабатывать бесконечный список ленивым кодом элементарно.

А я не говорил что трудно, это опять твои фантазии. Ты сказал что в каких-то случаях может появится задержка, и мол поэтому нам на время выполнения всё равно. Бесконечные списки — это контрпример, тут нет никаких задержек по сравнению с энергичным кодом, так как он вообще загнётся на бесконечном списке.

EP>>>>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional

I>>> Это синтетика.
EP>>Random Access это синтетика?
I>Ленивая работа с массивами это синтетика.

С чего это вдруг?
Например выше по теме как раз об этом и говорили.

EP>>>>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.

I>>>Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где
I>>>1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд
I>>>2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику
EP>>В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг.
I>Алё — производительность вычисления одного кусочка не меняется.

В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста.
Re[54]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 16:38
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>Ну да, чудес не бывает и за всё надо платить. По счастью в России (ну или во всяком случае в Москве ) это пока не особо тяжёлая проблема.


В москве все немного необычно, мерить по ней остальные регионы как минимум странно.
Re[46]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 16:50
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Ты ври да не завирайся. Разговор был про две основных вещи

I>>1 нереэнтерабельный код
I>>2 эвентлуп
I>>В _частном_ случае может работать и это всё что ты показал.

EP>Врёшь. Ты сам предложил конкретную тему примера и верищал про подвигший UI, и не надо приплетать сюда реэнтрабельность. Вот одна из веток
Автор: Evgeny.Panasyuk
Дата: 08.07.13
, по ней вниз/вверх.


Вот-вот, смотри сам — ты явно прибил короутины к эвентлупу. Про реэнтерабельность — там же.
Раз уж ты яростно не согласен про эвентлуп и тд, покажи на _моём_ примере, как сделать так, что бы код не морозил эвентлуп
Еще раз и внятно:
var coPing = coroutine(ping);
var coPong = coroutine(pong);

function ping () { while(true) { coPong(); }  }
function pong () { while(true) { coPing(); }  }

coPing();

setInterval(function(){ console.log('UI is alive'); }, 1000); // пока работает таймер, эвентлуп жив. Но сюда мы никогда не попадём

Ты хорошо понимаешь, что здесь происходит ? Вычислительная модель 1 к 1 с вин32 однопоточным UI приложением

EP>А я не говорил что трудно, это опять твои фантазии. Ты сказал что в каких-то случаях может появится задержка, и мол поэтому нам на время выполнения всё равно. Бесконечные списки — это контрпример, тут нет никаких задержек по сравнению с энергичным кодом, так как он вообще загнётся на бесконечном списке.


Задержки — есть. Каждый элемент бесконечного списка ты обрабатываешь за чуть большее вермя, чем с энергичным списком. В итоге, скажем, если крутить оба варианта в течение недели-месяца-года, то энергичный вариант `уедет` гораздо дальше ленивого.
Т.е. та самая разница, которой можно пренебречь в единичном случае, может сыграть роль в случае большого количества итераций.
Если ты конечно выполняешь свой любимый тест навроде i++, то можно и не увидеть разницы.

EP>>>Random Access это синтетика?

I>>Ленивая работа с массивами это синтетика.

EP>С чего это вдруг?


Я уже объяснил. Частота встречаемости задач вот такая, не в твою пользу. Теоретически есть, а практически в миллион раз чаще встречается работа с конскими данными(файловая система) или по своей сути адски медленными(бд, сеть и тд).

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

I>>Алё — производительность вычисления одного кусочка не меняется.

EP>В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста.


Из за ленивости — не теряется. Т.е. этим можно пренебречь
Отредактировано 05.10.2015 17:07 Pauel . Предыдущая версия .
Re[47]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 17:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>Врёшь. Ты сам предложил конкретную тему примера и верищал про подвигший UI, и не надо приплетать сюда реэнтрабельность. Вот одна из веток
Автор: Evgeny.Panasyuk
Дата: 08.07.13
, по ней вниз/вверх.

I>Вот-вот, смотри сам -

Ты говорил про говорил про повисший UI — его нет.

I>ты явно прибил короутины к эвентлупу.


Где? В event-loop дёргается обычный handler, который дёргался бы при любой реализации, даже без корутин

EP>>А я не говорил что трудно, это опять твои фантазии. Ты сказал что в каких-то случаях может появится задержка, и мол поэтому нам на время выполнения всё равно. Бесконечные списки — это контрпример, тут нет никаких задержек по сравнению с энергичным кодом, так как он вообще загнётся на бесконечном списке.

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

1. Ещё раз, энергичного бесконечного списка нет.
2. Даже если представить что был бы — откуда задержки в ленивом варианте?

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

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

Естественно, теряется из-за тормозов в языках, а не из-за самой ленивости, с этого всё и началось.
Re[48]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 17:26
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

Вот одна из веток
Автор: Evgeny.Panasyuk
Дата: 08.07.13
, по ней вниз/вверх.
I>>Вот-вот, смотри сам -
EP>Ты говорил про говорил про повисший UI — его нет.

В частном случае будет работать.

I>>ты явно прибил короутины к эвентлупу.

EP>Где? В event-loop дёргается обычный handler, который дёргался бы при любой реализации, даже без корутин

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

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


EP>1. Ещё раз, энергичного бесконечного списка нет.


Точнее, дождаться окончания генерации или обработки невозможно. Прервать и/или проверить, склько сгенерировали/проверили можно очень даже легко.

EP>2. Даже если представить что был бы — откуда задержки в ленивом варианте?


Из-за самой ленивости, способ итерирования другой, с управлением извне.

EP>>>В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста.

I>>Из за ленивости — не теряется.

EP>Естественно, теряется из-за тормозов в языках, а не из-за самой ленивости, с этого всё и началось.

Из за ленивости. Это всегда дополнительные приседания. самый быстрый цыкл это while(true) {}
Если хочешь дозировать и управлять, то дозирование и управление требуют ресурсов процессора-памяти-времени.
Re[47]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 17:26
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Раз уж ты яростно не согласен про эвентлуп и тд, покажи на _моём_ примере, как сделать так, что бы код не морозил эвентлуп

I>Еще раз и внятно:
I>
I>

I>Ты хорошо понимаешь, что здесь происходит ? Вычислительная модель 1 к 1 с вин32 однопоточным UI приложением

Опять демагогия, и попытка уйти от ответственности. Там пример был совершенно другой, ты говорил что код вида:
void foo(wistream &client_stream)
{
    wstring msg;
    do
    {
        std::getline(client_stream, msg);
        SendMessage(main_hwnd, WM_SETTEXT, 0, reinterpret_cast<LPARAM>(msg.c_str()));
    } while(msg != L"exit");
}
Подвесит UI пока будет получать все символы. Тот пример полностью опровергает это утверждение.
Попытки съехать на другой пример конечно забавны, но это уже всё начинает надоедать.

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

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

Так при меньшем вычислении на один элемент разница ещё заметнее, если она конечно бы была
Re[48]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 17:33
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Опять демагогия, и попытка уйти от ответственности. Там пример был совершенно другой,


Это тебе удобнее было накидать _другой_ пример, в свою пользу.

EP>
EP>void foo(wistream &client_stream)
EP>{
EP>}
EP>
Подвесит UI пока будет получать все символы. Тот пример полностью опровергает это утверждение.

EP>Попытки съехать на другой пример конечно забавны, но это уже всё начинает надоедать.

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

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

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

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

Она и заметна и даже измерима.
Re[49]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 17:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Собтсвенно раз ты скипнул мой вариант кода, пудозреваю такой вопрос для тебя слишком сложен


Ты уже опустился ниже плинтуса, докопался до того что я не ответил на твои правки задним числом

EP>>2. Даже если представить что был бы — откуда задержки в ленивом варианте?

I>Из-за самой ленивости, способ итерирования другой, с управлением извне.

Например в случае transformed (а-ля map) способ итерирования один и тот же
Re[49]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 18:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>
EP>>void foo(wistream &client_stream)
EP>>{
EP>>}
EP>>
Подвесит UI пока будет получать все символы. Тот пример полностью опровергает это утверждение.

EP>>Попытки съехать на другой пример конечно забавны, но это уже всё начинает надоедать.
I>Правильно. У тебя _почти_ так и происходит, только раскрутка происходит при _непосредтсвенном_ участии эвентлупа. Т.е. в одном месте ты с помощью эвентлупа накапливаешь данные, а потом возвращаешь управление снова тому же эвентлупу. И там и там — явно.

Покажи те места в самом эвентлупе, которые появились от того что используются корутины.

I>Хочешь внятно выступить — смотри мой пример с пинг-понгом. В ём всё что надо видно


Твой новый пример это примитивная демагогия.

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

I>>>Если ты конечно выполняешь свой любимый тест навроде i++, то можно и не увидеть разницы.
EP>>Так при меньшем вычислении на один элемент разница ещё заметнее, если она конечно бы была
I>Она и заметна и даже измерима.

void normal(int (&xs)[1111])
{
    for(auto x : xs)
        print(calc(x));
}

void lazy(int (&xs)[1111])
{
    for(auto tx : xs | transformed(calc))
        print(tx);
}

Результирующий ASM идентичен:
clang++ -std=c++1z -O3 -Wall -pedantic -pthread main.cpp -S && cat main.s
    .text
    .file    "main.cpp"
    .globl    _Z6normalRA1111_i
    .align    16, 0x90
    .type    _Z6normalRA1111_i,@function
_Z6normalRA1111_i:                      # @_Z6normalRA1111_i
    .cfi_startproc
# BB#0:
    pushq    %r14
.Ltmp0:
    .cfi_def_cfa_offset 16
    pushq    %rbx
.Ltmp1:
    .cfi_def_cfa_offset 24
    pushq    %rax
.Ltmp2:
    .cfi_def_cfa_offset 32
.Ltmp3:
    .cfi_offset %rbx, -24
.Ltmp4:
    .cfi_offset %r14, -16
    movq    %rdi, %r14
    xorl    %ebx, %ebx
    .align    16, 0x90
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
    movl    (%r14,%rbx), %edi
    callq    _Z4calci
    movl    %eax, %edi
    callq    _Z5printi
    addq    $4, %rbx
    cmpq    $4444, %rbx             # imm = 0x115C
    jne    .LBB0_1
# BB#2:
    addq    $8, %rsp
    popq    %rbx
    popq    %r14
    retq
.Lfunc_end0:
    .size    _Z6normalRA1111_i, .Lfunc_end0-_Z6normalRA1111_i
    .cfi_endproc

.globl    _Z4lazyRA1111_i
    .align    16, 0x90
    .type    _Z4lazyRA1111_i,@function
_Z4lazyRA1111_i:                        # @_Z4lazyRA1111_i
    .cfi_startproc
# BB#0:
    pushq    %r14
.Ltmp5:
    .cfi_def_cfa_offset 16
    pushq    %rbx
.Ltmp6:
    .cfi_def_cfa_offset 24
    pushq    %rax
.Ltmp7:
    .cfi_def_cfa_offset 32
.Ltmp8:
    .cfi_offset %rbx, -24
.Ltmp9:
    .cfi_offset %r14, -16
    movq    %rdi, %r14
    xorl    %ebx, %ebx
    .align    16, 0x90
.LBB1_1:                                # =>This Inner Loop Header: Depth=1
    movl    (%r14,%rbx), %edi
    callq    _Z4calci
    movl    %eax, %edi
    callq    _Z5printi
    addq    $4, %rbx
    cmpq    $4444, %rbx             # imm = 0x115C
    jne    .LBB1_1
# BB#2:
    addq    $8, %rsp
    popq    %rbx
    popq    %r14
    retq
.Lfunc_end1:
    .size    _Z4lazyRA1111_i, .Lfunc_end1-_Z4lazyRA1111_i
    .cfi_endproc

    .ident    "clang version 3.7.0 (tags/RELEASE_370/final 246979)"
    .section    ".note.GNU-stack","",@progbits
Re[50]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 18:18
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Собтсвенно раз ты скипнул мой вариант кода, пудозреваю такой вопрос для тебя слишком сложен


EP>Ты уже опустился ниже плинтуса, докопался до того что я не ответил на твои правки задним числом


Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде. Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.

EP>>>2. Даже если представить что был бы — откуда задержки в ленивом варианте?

I>>Из-за самой ленивости, способ итерирования другой, с управлением извне.

EP>Например в случае transformed (а-ля map) способ итерирования один и тот же


transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.
Re[51]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 18:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде.


Всё участие event-loop'а это дёрганье заданного handler'а, которые было бы и без корутин

I>Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.


Придумал какой-то левый отстранённый пример — PROFIT!

EP>>>>2. Даже если представить что был бы — откуда задержки в ленивом варианте?

I>>>Из-за самой ленивости, способ итерирования другой, с управлением извне.
EP>>Например в случае transformed (а-ля map) способ итерирования один и тот же
I>transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.

Попробуй найди издержки transformed в ASM, приведённом выше.
Re[52]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.15 19:34
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде.


EP>Всё участие event-loop'а это дёрганье заданного handler'а, которые было бы и без корутин


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


I>>Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.


EP>Придумал какой-то левый отстранённый пример — PROFIT!


Этот отстранённый пример идёт красной линией через все туториалы и статьи про корутины

I>>transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.


EP>Попробуй найди издержки transformed в ASM, приведённом выше.


Если в твоей ленивости никакого смысла нет, то умный компилер может об этом догадаться. Это говорит не о том, что издержек ленивости нет, а о том что ленивость не нужна и потому не используется.
Re[53]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 05.10.15 20:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде.

EP>>Всё участие event-loop'а это дёрганье заданного handler'а, которые было бы и без корутин
I>Твой пример слишком громоздкий, что бы на пальцах показать весь флоу. Ты сам себя запутал

Так ты сам просил
Автор: Ikemefula
Дата: 08.07.13
пример с message pump'ом, а теперь переобуваешься — "пример слишком громоздкий"

I>Представь — стрим заснул на пол-часа, нет данных. Что будет с UI ?
I>Покажи код — мой message pump и твой getline.


I>>>Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.

EP>>Придумал какой-то левый отстранённый пример — PROFIT!
I>Этот отстранённый пример идёт красной линией через все туториалы и статьи про корутины

Не важно где он там идёт, это пример на другую тему. Ты делал утверждение что с message-pump'ом, и getline'ом внутри корутины будет повисшее UI — пример показывает что это неверно, и ты вроде даже согласился тогда. Зачем ты сейчас включаешь демагога неясно

I>>>transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.

EP>>Попробуй найди издержки transformed в ASM, приведённом выше.
I>Если в твоей ленивости никакого смысла нет,

Смысл в том числе в абстракции и удобстве.

I>то умный компилер может об этом догадаться.


Ты видимо не понимаешь как оно внутри устроенно — там те же самые сравнения/инкременты указателей, разница только в том что разыменование внешнего итератора выдаёт трансформированный результат. Задача компилятора — только сделать инлайн, без навороченных loop/branch graph оптимизаций.

I>Это говорит не о том, что издержек ленивости нет, а о том что ленивость не нужна и потому не используется.


Акт 2. Занавес. Вторая сова треснула по швам.
Re[54]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.10.15 07:57
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.

S>> Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.

_>А что не так с Питоном? ) Он у нас позволяет очень удобно писать очень медленный код. Соответственно в тех случаях, когда подобное быстродействие приемлемо (например для скриптов), абсолютно логично использовать именно его. Так же как ты скажем используешь медленный 1C для всяких там бухгалтерий и т.п.

ERP

S>> Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.


_>Это всё не то. Нужна предкомпиляция, а не кэширование.

Я тебе уже кучу примеров давал, что есть динамические запросы и никакая предкомпиляция не спасет, на который ты кстати не соизволил ответить.
Кроме того я могу Linq позволяет использовать и прямые запросы.
http://metanit.com/sharp/entityframework/5.1.php

Часто бывает, что Linq не берет всех возможностей T-SQL, можно либо подправлять запросы, либо писать их с нуля.

S>>http://www.codehint.ru/articles/2013-02-13_linq_entity_framework_5

S>>

S>>В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.


_>Фоновый поток для таких целей? ) Ужасы какие... Наверное ещё и с блокировками какими-нибудь? )))


Еще раз напомню тебе про динамические запросы.

S>>Мало того, можно кэшировать результаты запросов

S>>https://weblogs.asp.net/dotnetstories/using-second-level-cache-in-entity-framework-6-1-applications
S>>https://github.com/loresoft/EntityFramework.Extended/wiki/Query-Result-Cache

_>А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение.

Ну да EF это недоразумение, а sqlpp11. При поиске на который 1-2 ссылки. Read Me меньше чем моя статья для 1С ников про линк.
Вот такие они "специализированные эффективные инструменты"

Почитай на досуге https://msdn.microsoft.com/Ru-ru/data/hh949853.aspx
и солнце б утром не вставало, когда бы не было меня
Re[50]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.10.15 08:07
Оценка: -1 :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Хочешь внятно выступить — смотри мой пример с пинг-понгом. В ём всё что надо видно

EP>Твой новый пример это примитивная демагогия.

Я и говорю, что ты хочешь только удобные для себя аргументы смотреть. С твоим кодом уже наигрались, хватит.

I>>Она и заметна и даже измерима.


EP>
EP>void normal(int (&xs)[1111])
EP>{
EP>    for(auto x : xs)
EP>        print(calc(x));
EP>}

EP>void lazy(int (&xs)[1111])
EP>{
EP>    for(auto tx : xs | transformed(calc))
EP>        print(tx);
EP>}
EP>


И где здесь ленивый обход ?
Re[55]: Java vs C# vs C++
От: alex_public  
Дата: 06.10.15 09:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Это всё не то. Нужна предкомпиляция, а не кэширование.

S> Я тебе уже кучу примеров давал, что есть динамические запросы и никакая предкомпиляция не спасет, на который ты кстати не соизволил ответить.

А что конкретно ты подразумеваешь под динамическими запросами?

S>Кроме того я могу Linq позволяет использовать и прямые запросы.

S>http://metanit.com/sharp/entityframework/5.1.php
S>Часто бывает, что Linq не берет всех возможностей T-SQL, можно либо подправлять запросы, либо писать их с нуля.

Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно.

_>>А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение.

S>Ну да EF это недоразумение, а sqlpp11. При поиске на который 1-2 ссылки. Read Me меньше чем моя статья для 1С ников про линк.
S>Вот такие они "специализированные эффективные инструменты"

Не, sqlpp11 не умеет (да и не должно уметь, т.к. это вообще другая область) кэшировать результаты запросов. Под специализированными эффективными инструментами подразумевались такие вещи как memcached. А ещё лучше просто включение соответствующей возможности прямо в СУБД, т.к. тогда не надо беспокоиться о валидности кэша.
Re[56]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.10.15 10:02
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Это всё не то. Нужна предкомпиляция, а не кэширование.

S>> Я тебе уже кучу примеров давал, что есть динамические запросы и никакая предкомпиляция не спасет, на который ты кстати не соизволил ответить.

_>А что конкретно ты подразумеваешь под динамическими запросами?

http://rsdn.ru/forum/philosophy/6203039.1
Автор: Serginio1
Дата: 05.10.15


S>>Кроме того я могу Linq позволяет использовать и прямые запросы.

S>>http://metanit.com/sharp/entityframework/5.1.php
S>>Часто бывает, что Linq не берет всех возможностей T-SQL, можно либо подправлять запросы, либо писать их с нуля.

_>Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно.


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

_>>>А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение.

S>>Ну да EF это недоразумение, а sqlpp11. При поиске на который 1-2 ссылки. Read Me меньше чем моя статья для 1С ников про линк.
S>>Вот такие они "специализированные эффективные инструменты"

_>Не, sqlpp11 не умеет (да и не должно уметь, т.к. это вообще другая область) кэшировать результаты запросов. Под специализированными эффективными инструментами подразумевались такие вещи как memcached. А ещё лучше просто включение соответствующей возможности прямо в СУБД, т.к. тогда не надо беспокоиться о валидности кэша.


А в EF все в одном. Поэтому для 99% задач подходят не эффективные по скорости, но удобные для программирования компоненты.
и солнце б утром не вставало, когда бы не было меня
Re[57]: Java vs C# vs C++
От: alex_public  
Дата: 06.10.15 14:48
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

_>>А что конкретно ты подразумеваешь под динамическими запросами?

S>http://rsdn.ru/forum/philosophy/6203039.1
Автор: Serginio1
Дата: 05.10.15


Если количество элементов в массиве определено на момент компиляции (как в твоём сообщение), то никаких динамических запросов не требуется (во всяком случае в C++ или любом другом языке с элементами метапрограммированием). Если же число элементов в массиве произвольно и известно только в момент исполнения, то действительно требуется динамическое формирование запросов. И sqlpp11 это тоже без проблем умеет (см. в конце этого https://github.com/rbock/sqlpp11/blob/master/examples/select.cpp примера). )))

_>>Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно.

S> Если нужно выжимать все до остатка, то да приходится оптимизировать. Если производительности хватает, то выбирай, что хочешь.
S>Просто в Net есть огромный выбор как технологий так и инструментов.

Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))
Re[58]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.10.15 15:00
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>А что конкретно ты подразумеваешь под динамическими запросами?

S>>http://rsdn.ru/forum/philosophy/6203039.1
Автор: Serginio1
Дата: 05.10.15


_>Если количество элементов в массиве определено на момент компиляции (как в твоём сообщение), то никаких динамических запросов не требуется (во всяком случае в C++ или любом другом языке с элементами метапрограммированием). Если же число элементов в массиве произвольно и известно только в момент исполнения, то действительно требуется динамическое формирование запросов. И sqlpp11 это тоже без проблем умеет (см. в конце этого https://github.com/rbock/sqlpp11/blob/master/examples/select.cpp примера). )))


А оно может быть различным, как например запрос на вхождение в массив.
Кстати а где навигационные свойства? Где запросы через несколько точек? Неговоря об отложенных загрузках навигационных свойств.

_>>>Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно.

S>> Если нужно выжимать все до остатка, то да приходится оптимизировать. Если производительности хватает, то выбирай, что хочешь.
S>>Просто в Net есть огромный выбор как технологий так и инструментов.

_>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))

Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру
и солнце б утром не вставало, когда бы не было меня
Re[59]: Java vs C# vs C++
От: alex_public  
Дата: 06.10.15 15:40
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>А оно может быть различным, как например запрос на вхождение в массив.

S>Кстати а где навигационные свойства? Где запросы через несколько точек? Неговоря об отложенных загрузках навигационных свойств.

Ничего не понял из этой фразы. Кстати, ты сам то смотрел описание библиотеки, прежде чем задавать эти вопросы? ) Посмотри тут https://github.com/rbock/sqlpp11/wiki/Select что ты хотел. Если не найдёшь, то тогда уже спрашивай (только с более внятной формулировкой).

_>>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))

S>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру

Аргументированно. )))
Re[60]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.10.15 17:28
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>А оно может быть различным, как например запрос на вхождение в массив.

S>>Кстати а где навигационные свойства? Где запросы через несколько точек? Неговоря об отложенных загрузках навигационных свойств.

_>Ничего не понял из этой фразы. Кстати, ты сам то смотрел описание библиотеки, прежде чем задавать эти вопросы? ) Посмотри тут https://github.com/rbock/sqlpp11/wiki/Select что ты хотел. Если не найдёшь, то тогда уже спрашивай (только с более внятной формулировкой).


Это и есть понятие.Из за него в общем то и городится весь огород.
Кстати это говорит о том, что ты не читаешь моих ссылок.
Там куча примеров к доступу к объектам через навигационные свойства.
А может ты, О ужас не понимаешь примитивного C# ного кода?
Там кстати почти всё на родном русском
 var qr = from Номенклатура in бд.Спр_Номенклатура

 

                     select new

                     {

                         Номенклатура.Наименование,

                         Номенклатура.ПолнНаименование,

                         Единицы = (Номенклатура.ПодчиненныеЕдиницы.Where(единица => единица.ШтрихКод.CompareTo("4") > 0)

                         .Select(единица =>

 

                         new

                         {

                             единица.ШтрихКод,

                             ОКЕИ = единица.ОКЕИ.Наименование

                         }

            )

                         )

                     };



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

_>>>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))

S>>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру

_>Аргументированно. )))

Так а где твои аргументы, сравнивая наколеночную разработку по которой нет ни статей, с минимумом упоминаний в интернете с EF огромным количеством материалов, обсуждений итд.
Еще раз в моей статье больше примеров чем в разработке по твоей ссылке.
Кроме того удобство в биндинге и редактировании
http://metanit.com/sharp/entityframework/3.3.php
и солнце б утром не вставало, когда бы не было меня
Отредактировано 06.10.2015 18:27 Serginio1 . Предыдущая версия . Еще …
Отредактировано 06.10.2015 18:01 Serginio1 . Предыдущая версия .
Отредактировано 06.10.2015 17:30 Serginio1 . Предыдущая версия .
Re[58]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.10.15 18:40
Оценка: +1 -1
Здравствуйте, alex_public, Вы писали:

_>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))


Это заблуждение. Практически все тормозные софтины на с++ тормозят и лагают именно потому, что их разработчики считали: "Мы на с++, значит всё само быстро !!!!111расрас"
Re[52]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.10.15 18:55
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код.


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

>В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.


Вот эта цена и есть дилемма, которой нет. Эта цена становится препятствием для многих проектов и даже целых контор.
Re[54]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.10.15 19:05
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Так ты сам просил
Автор: Ikemefula
Дата: 08.07.13
пример с message pump'ом, а теперь переобуваешься — "пример слишком громоздкий"

EP>

I>>Представь — стрим заснул на пол-часа, нет данных. Что будет с UI ?
I>>Покажи код — мой message pump и твой getline.


Ты сам видишь, что ты процитировал ? Вот мой message pump совершенно не в курсе, что надо вызвать какую то функцию для заполнения данных. Откуда твой стрим будет брать данные ? Откуда будет управление получать ?
Re[61]: Java vs C# vs C++
От: alex_public  
Дата: 06.10.15 22:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Это и есть понятие.Из за него в общем то и городится весь огород.

S>Кстати это говорит о том, что ты не читаешь моих ссылок.
S> Там куча примеров к доступу к объектам через навигационные свойства.

А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.

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

S> Я могу сразу сказать, что конечно можно самому добавить левые соединения, но это будет значительно больше кода чем как ты тут выразился про ужасные предваритеные компиляции запроса


Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.

S>>>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру

_>>Аргументированно. )))
S> Так а где твои аргументы, сравнивая наколеночную разработку по которой нет ни статей, с минимумом упоминаний в интернете с EF огромным количеством материалов, обсуждений итд.
S> Еще раз в моей статье больше примеров чем в разработке по твоей ссылке.

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

S>Кроме того удобство в биндинге и редактировании

S>http://metanit.com/sharp/entityframework/3.3.php

Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.
Re[59]: Java vs C# vs C++
От: alex_public  
Дата: 06.10.15 22:36
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

_>>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))

I>Это заблуждение. Практически все тормозные софтины на с++ тормозят и лагают именно потому, что их разработчики считали: "Мы на с++, значит всё само быстро !!!!111расрас"

Ну да, помимо наличие компилятора языка, требуется ещё наличие соответствующей квалификации. Нюанс в том, что даже самый крутой эксперт по C# не сможет написать одновременно красивый и быстрый код — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.
Re[10]: Java vs C# vs C++
От: · Великобритания  
Дата: 06.10.15 23:49
Оценка:
Здравствуйте, PM, Вы писали:

PM> Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR


PM> Почитайте на досуге как авторы LMAX героически боролись (и вроде бы продолжают бороться) с JVM — пытаясь выровнять данные по границе кэш-линии; как затюнинговать сборку мусора, чтобы система не замерзала в неподходящий момент (и перезапускать всё разв в сутки в конечном итоге)


PM> Короче, сплошной <троллейбус из буханки хлеба.jpeg>

Собственно сейчас в моде Zing JVM, там задержки не более 10ms, в основном ~100us.
Писать такое на C++... неее... проще застрелиться.
А перезапуск нужен не для gc, а чтобы на диск состояние скинуть, ибо использовать классические СУБД — теоретически невозможно.
avalon/1.0.432
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 00:00
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB> Расскажите мне про тормоза умных указателей. Я не понимаю.

TB> Может быть потому, что я не фигачу шареды направо и налево, потому что обычно я знаю, кто у ресурса хозяин, и мне хватает уника, у которого тормозить вообще нечему.
Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.
Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.
avalon/1.0.432
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[15]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 01:53
Оценка:
Здравствуйте, ·, Вы писали:

TB>> Расскажите мне про тормоза умных указателей. Я не понимаю.

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

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

·>который использует lock (mutex?) -


Обычно в реализациях атомарные inc/dec.
Re[62]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 06:18
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>> Это и есть понятие.Из за него в общем то и городится весь огород.

S>>Кстати это говорит о том, что ты не читаешь моих ссылок.
S>> Там куча примеров к доступу к объектам через навигационные свойства.

_>А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.

Для того, что бы что то хаять нужно ознакомиться с темой?

_>Ладно, так и быть, я не поленился и глянул в гугле что это хрень такая. Оказывается (судя по тому, что я прочитал) это автоматические запросы данных в соседних таблицах в случае нахождения в таблице внешних ключей. Крайне сомнительная возможность, особенно в контексте быстродействия.

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

S>> Я могу сразу сказать, что конечно можно самому добавить левые соединения, но это будет значительно больше кода чем как ты тут выразился про ужасные предваритеные компиляции запроса


_>Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.

Я тебя уверяю, что нет. В 8 ке есть аналогичные запросы .

Опять же выдержка из статьи http://infostart.ru/public/402433/

Кроме того в Linq to EF можно использовать Entity SQL

Например





varstr = @"Select VALUE  p From [Спр_Номенклатура] asp";

           varЗапрос = qr.CreateQuery<Справочник.Номенклатура>(str );

           var res = Запрос.Execute(MergeOption.NoTracking);

 

           foreach (varэлемin res)

            {

                Console.WriteLine("{0}.{1} - {2}", элем.Наименование.TrimEnd(), элем.Артикул, элем.ПолнНаименование.TrimEnd());

            }

Но по большому счету выхлоп от него небольшой



https://msdn.microsoft.com/ru-ru/library/bb738573(v=vs.110).aspx
Отличия Entity SQL и Transact-SQL



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

S>>>>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру

_>>>Аргументированно. )))
S>> Так а где твои аргументы, сравнивая наколеночную разработку по которой нет ни статей, с минимумом упоминаний в интернете с EF огромным количеством материалов, обсуждений итд.
S>> Еще раз в моей статье больше примеров чем в разработке по твоей ссылке.

_>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).

Да ну. Не говори чушь. Синтаксис убогий, нет поддержки навигационных свойств. Нет поддержки биндинга итд.
Тот же Code First миграция итд.
Еще раз глядя на 1С, то там интерперетатор и плевать хотели на скорость, но при этом количество 1С ников в нашей стране с лихвой перекрывают С++ ников.
Наверное не все так гладко в вашем королевстве.
C#, Java это компромисс между удобством и небольшим замедлением, которое легко восполняется покупкой более производительного оборудования.

Это поделка 10 летней давности уровня типа объект ObjectSpaces http://rsdn.ru/article/dotnet/objectspaces.xml
Автор(ы): Тимофей Казаков (TK)
Дата: 14.08.2004
В .NET Framework 1.2 для отображения БД на объекты есть специальный набор классов из пространства имен System.ObjectSpaces.*. Статья рассказывает об этих классах и работе с ними.


S>>Кроме того удобство в биндинге и редактировании

S>>http://metanit.com/sharp/entityframework/3.3.php


_>Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.

Это относится и к WPF. И здесь продумано все в одном без лишних телодвижений с поддержкой Студии.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 07.10.2015 7:08 Serginio1 . Предыдущая версия .
Re[15]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 06:44
Оценка:
Здравствуйте, ·, Вы писали:

·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.


shared pointer нужен в случае параллельного доступа к данным из разных потоков с неизвестным заранее временем жизни. Это совсем не частный случай даже в системах с подобным параллельным доступом. А если использовать более продуманные архитектуры (типа той же модели акторов), то подобные вопросы не встают в принципе. Тем более, что при использование семантики перемещения модель акторов становится такой же эффективной, как и просто общая память (в варианте без блокировок).
Re[60]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 07:15
Оценка: +1 -1
Здравствуйте, alex_public, Вы писали:

_>Ну да, помимо наличие компилятора языка, требуется ещё наличие соответствующей квалификации. Нюанс в том, что даже самый крутой эксперт по C# не сможет написать одновременно красивый и быстрый код


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

> — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.


1. Быстрый код всегда и везде это результат работы головой, а у тебя красной нитью через все собщения "быстрый код это только С++ хы хы"

2. ручной sql код как раз встречается именно в С++. Нормальных OR/M там нет и наверное никогда не будет. Тамошние люди зачастую пишут классный код по конкатенации запросов, что бы выполнить какой нибудь мусор, который будет выполняться чуть не минутами.

3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн == утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда ясно, что неюзабельные уродцы для тебя эталон красоты
Отредактировано 07.10.2015 8:53 Pauel . Предыдущая версия . Еще …
Отредактировано 07.10.2015 8:48 Pauel . Предыдущая версия .
Re[63]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 07:25
Оценка: +1 :)
Здравствуйте, Serginio1, Вы писали:

_>>А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.

S> Для того, что бы что то хаять нужно ознакомиться с темой?

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

_>>Ладно, так и быть, я не поленился и глянул в гугле что это хрень такая. Оказывается (судя по тому, что я прочитал) это автоматические запросы данных в соседних таблицах в случае нахождения в таблице внешних ключей. Крайне сомнительная возможность, особенно в контексте быстродействия.

S> Я же тебе давал ссылки, показывал какие генерятся запросы. Ничего сомнительногог, сильно уменьшант количество лишнего кода.

Подобная функциональность очевидно тривиально (в несколько строк) добавляется практически в любую ORM. Только вот я что-то не помню такого ни в одной, из тех, что я видел (причём речь далекое не только про C++). Интересно почему... )))

_>>Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.

S> Я тебя уверяю, что нет. В 8 ке есть аналогичные запросы .
S>...
S> Есть очень интересный проект 1С++ там можно строить запросы, но доступ к навигационным свойствам нет. Приходится городить кучу левых соединений.
S>Это значительно менее читабельно, и большая возможность ошибки. А вообще основной смысл Линк для СкуЛ как раз и есть навигационные свойства.

Я же сказал, отдельные запросы, а не ручные join'ы. Т.е. допустим мы получаем полный список объектов (как раз в виде внешних ключей) из одной таблице, а потом получаем уже сами объекты из другой таблице. По одной штуке за раз и только в тот момент, когда пользователь их запросил (допустим выделил в списке).

_>>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).

S> Да ну. Не говори чушь. Синтаксис убогий, нет поддержки навигационных свойств. Нет поддержки биндинга итд.

Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

_>>Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.

S> Это относится и к ВПФ. И здесь продумано все в одном без лишних телодвижений с поддержкой Студии.

Вопрос создания GUI мы конечно же тоже можем пообсуждать (я перепробовал много разных библиотек с разными визуальными редакторами и т.п., так что я тут могу много чего сказать...), но это уже совсем не относится к обсуждаемой теме.
Re[61]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 07:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Ну да, помимо наличие компилятора языка, требуется ещё наличие соответствующей квалификации. Нюанс в том, что даже самый крутой эксперт по C# не сможет написать одновременно красивый и быстрый код

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

Я вообще то именно это и говорю всё время. Что ограничения платформы не позволяют развернуться даже профи. )

>> — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.

I>1. Быстрый код всегда и везде это результат работы головой, а у тебя красной нитью через все собщения "быстрый код это только С++ хы хы"

Нет, главный тезис не в этом. А в том, что даже хорошо работая головой, у тебя не получится нужный результат на C#. ))) Т.е. это не C++ такой хороший, а JVM/CLR такие плохие.

Что же касается C/C++, то это банально единственный нативный мейнстрим язык, вот и всё. Скажем если бы тот же Rust или D были бы мейнстримом (имели бы компиляторы (причём с мощными оптимизаторами) под все возможные платформы и архитектуры, имели бы полноценную поддержку во всех главные IDE, имели бы тысячи готовых библиотек и т.д. и т.п.), то очевидно что разговоров про "только C++" не было бы. )))

I>2. ручной sql код как раз встречается именно в С++. Нормальных OR/M там нет и наверное никогда не будет. Тамошние люди зачастую пишут классный код по конкатенации запросов, что бы выполнить какой нибудь мусор, который будет выполняться чуть не минутами.


Помнится мы разок уже обсуждали что-то подобное и ты тогда слился из дискуссии, когда не смог привести аналог на C# простейшего C++ кода работы с ORM. Причём тогда это была не sqlpp11, а другая, более простая ORM. )))

I>3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн — утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда не ясно, что неюзабельные уродцы для тебя эталон красоты


Мне в этом смысле нравится точка зрения Туполева: http://www.aphorisme.ru/by-authors/tupolev/?q=5451
Re[64]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 08:25
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

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


Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

По поводу биндинга
 dataGridView1.DataSource = db.Players.Local.ToBindingList();


https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx

DbSet<TEntity>.Local — свойство

Возвращает объект ObservableCollection<T>, содержащий локальное представление всех добавленных, неизменившихся и измененных сущностей в наборе. Это локальное представление остается синхронизированным по мере добавления или удаления сущностей из контекста. Аналогичным образом добавляемые или удаляемые из этого локального представления сущности автоматически добавляются в контекст или удаляются из контекста.


Это свойство может использоваться для привязки данных путем заполнения набора данными, например путем вызова метода расширения Load и последующей привязки к локальным данным через это свойство. Для WPF выполняйте привязку к этому свойству напрямую. При использовании Windows Forms осуществляйте привязку к результату вызова метода ToBindingList для этого свойства.

http://professorweb.ru/my/entity-framework/6/level3/3_3.php

У линка 2 синтаксиса. Мне больше нравится Sql подобный. Он более читабельный. Часто совмещаю их где какой удобнее.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 07.10.2015 8:34 Serginio1 . Предыдущая версия .
Re[62]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 08:57
Оценка: +1
Здравствуйте, alex_public, Вы писали:

I>>Не надо приплетать сюда крутость, язык, квалификацию и тд и тд.


_>Я вообще то именно это и говорю всё время. Что ограничения платформы не позволяют развернуться даже профи. )


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

>>> — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.

I>>1. Быстрый код всегда и везде это результат работы головой, а у тебя красной нитью через все собщения "быстрый код это только С++ хы хы"

_>Нет, главный тезис не в этом. А в том, что даже хорошо работая головой, у тебя не получится нужный результат на C#. ))) Т.е. это не C++ такой хороший, а JVM/CLR такие плохие.


А холодильник — говно, потому что в него машину нельзя поставить.

I>>2. ручной sql код как раз встречается именно в С++. Нормальных OR/M там нет и наверное никогда не будет. Тамошние люди зачастую пишут классный код по конкатенации запросов, что бы выполнить какой нибудь мусор, который будет выполняться чуть не минутами.


_>Помнится мы разок уже обсуждали что-то подобное и ты тогда слился из дискуссии, когда не смог привести аналог на C# простейшего C++ кода работы с ORM. Причём тогда это была не sqlpp11, а другая, более простая ORM. )))


Ты наверное попутал, в дотнете есть вагон и маленькая тележка самых разных средств для работы с базой. Скорее на С++ ты вспотеешь повторять аналог, потому как полу-ОРМ не сумеет внятно оптимизировать запросы, например по причине отсутствия внятных Expression Tree. А это значит, вместо работы над оптимизитором люди будут изобретать эти самые Expression Tree и решать проблемы унификации, долго и мучительно рожать АПИ и тд и тд и тд.

I>>3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн — утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда не ясно, что неюзабельные уродцы для тебя эталон красоты


_>Мне в этом смысле нравится точка зрения Туполева: http://www.aphorisme.ru/by-authors/tupolev/?q=5451


Это слишком древняя фраза, что бы пользоваться её без оглядки.
Re[62]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 09:02
Оценка: :)
Здравствуйте, alex_public, Вы писали:

_>Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).


Ага, Жыгули быстре чем БелАз !!!!111расрас
Re[15]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 07.10.15 09:09
Оценка:
Здравствуйте, ·, Вы писали:

·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.

·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.

А может передавать сырой указатель? А хозяином будет главный поток, независимый от тех, которым нужны данные, и который ждёт сигнала от всех потоков?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[16]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 09:25
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.

Кстати, в java unique практически сам выводится — в тех тривиальных случаях когда ты бы стал использовать unique, java обыно делает escape analysis, да и Young Generation собирается очень быстро.

EP>·>Если нужна передача данных между тредами — нужен shared pointer,

EP>Он нужен только в случаях когда потоки владеют какими-то общими данными и точный момент удаления заранее не определён.
EP>Если просто нужно передать данные и владение в другой поток, то достаточно и unique, и то не факт — может быть хватит обычного перемещения.
Не владеют, а шарят... Будешь передавать weak_ptr, а значит опять локи.
Для перемещения — YG опять же.

Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.

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

Короче, может и можно писать low latency на C++, но сложнее на порядок.

EP>·>который использует lock (mutex?) -

EP>Обычно в реализациях атомарные inc/dec.
Это где? Вот тут вроде mutex.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 09:31
Оценка:
Здравствуйте, ·, Вы писали:

·>Короче, может и можно писать low latency на C++, но сложнее на порядок.


Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.

В джаве писать легче, но нет гарантии, что GC отработает точно в срок. Отсюда ясно, что рантайм надо сециально готовить — использовать специальный GC, всякие off-heap техники, что бы GC не лез когда не надо.
Re[65]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 09:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

S> Есть. Сразу видно, что мало используешь SQL. Заметь твою библиотечку мало кто использует.

Эту библиотеку мало используют, потому что она только недавно появилась на свет. Если тебя интересуют популярные и проверенные временем ORM решения на C++ то смотри:
1. ODB — довольно жирный фреймворк на эту тему.
2. SOCI — лёгкая библиотечка (мой выбор до появления sqlpp11, т.к. я не люблю жирные фреймворки).

S> Проще использовать конструкторы запросов, а вот с использованием навигационных свойств сразу и запросы и линки становятся намного привлекательнее.

S> Не хай, то о чем имеешь очень поверхностное понятие.

Это похоже как раз ты имел дело исключительно с EF и меряешь по нему весь остальной мир. ))) Я же имел дело с ORM в разных языках, в том числе и в динамических (где с этим всё гораздо проще и сильнее). И там популярны совсем другие практики (хотя очевидно, что сделать аналогичное решение тривиально).

S>По поводу биндинга

S>
S> dataGridView1.DataSource = db.Players.Local.ToBindingList();
S>

S>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>

S>DbSet<TEntity>.Local — свойство
S>Возвращает объект ObservableCollection<T>, содержащий локальное представление всех добавленных, неизменившихся и измененных сущностей в наборе. Это локальное представление остается синхронизированным по мере добавления или удаления сущностей из контекста. Аналогичным образом добавляемые или удаляемые из этого локального представления сущности автоматически добавляются в контекст или удаляются из контекста.


Ну так всё в точности как я и говорил. ObservableCollection, реализующая биндинг, не имеет никакого отношения к EF. Или может тебе показалось, что я говорил что биндинга нет во всём .net? )))
Re[63]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 09:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Помнится мы разок уже обсуждали что-то подобное и ты тогда слился из дискуссии, когда не смог привести аналог на C# простейшего C++ кода работы с ORM. Причём тогда это была не sqlpp11, а другая, более простая ORM. )))

I>Ты наверное попутал, в дотнете есть вагон и маленькая тележка самых разных средств для работы с базой. Скорее на С++ ты вспотеешь повторять аналог, потому как полу-ОРМ не сумеет внятно оптимизировать запросы, например по причине отсутствия внятных Expression Tree. А это значит, вместо работы над оптимизитором люди будут изобретать эти самые Expression Tree и решать проблемы унификации, долго и мучительно рожать АПИ и тд и тд и тд.

http://rsdn.ru/forum/philosophy/5372076?tree=tree
Автор: Ikemefula
Дата: 23.11.13
ну конечно попутал... )))

I>>>3. Вообще, красота и дизайн вещи сильно противоположные. Красота == эстетическое. Дизайн — утилитарное. Пудозреваю, для тебя это одно и то же. Отсюда не ясно, что неюзабельные уродцы для тебя эталон красоты

_>>Мне в этом смысле нравится точка зрения Туполева: http://www.aphorisme.ru/by-authors/tupolev/?q=5451
I>Это слишком древняя фраза, что бы пользоваться её без оглядки.

Я думаю она справедлива для всего инженерного дела, одним из подвидов которого и является программирование.
Re[64]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 09:51
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Ты наверное попутал, в дотнете есть вагон и маленькая тележка самых разных средств для работы с базой. Скорее на С++ ты вспотеешь повторять аналог, потому как полу-ОРМ не сумеет внятно оптимизировать запросы, например по причине отсутствия внятных Expression Tree. А это значит, вместо работы над оптимизитором люди будут изобретать эти самые Expression Tree и решать проблемы унификации, долго и мучительно рожать АПИ и тд и тд и тд.


_>http://rsdn.ru/forum/philosophy/5372076?tree=tree
Автор: Ikemefula
Дата: 23.11.13
ну конечно попутал... )))


Ага, понял, ты нашел доказательство, что дотнетных OR/M нет вещей, которые должны быть в OR/M искаропки ?

Есть целый форум на данном сайте, посвящен таким вот вопросам. Сходи туда, если ты хотел выяснить вопрос.

I>>Это слишком древняя фраза, что бы пользоваться её без оглядки.

_>Я думаю она справедлива для всего инженерного дела, одним из подвидов которого и является программирование.

И это чушь. Красота, как эстетическое, сильно субъективна, фактически — мода. Сегодня самолёты красивы, а завтра скажут, что это тупорылые огурцы. Из этого не следует, что самолеты должны задним числом перестать летать.

Так и в программировании, когда ты сидел носом в С++, естетсвенно, тебе ничего кроме с++ не покажется красивым.
Re[16]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 09:53
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.


_>shared pointer нужен в случае параллельного доступа к данным из разных потоков с неизвестным заранее временем жизни. Это совсем не частный случай даже в системах с подобным параллельным доступом. А если использовать более продуманные архитектуры (типа той же модели акторов), то подобные вопросы не встают в принципе. Тем более, что при использование семантики перемещения модель акторов становится такой же эффективной, как и просто общая память (в варианте без блокировок).

Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.
Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[16]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 09:58
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.

TB>·>Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.
TB>А может передавать сырой указатель? А хозяином будет главный поток, независимый от тех, которым нужны данные, и который ждёт сигнала от всех потоков?
Сырой указатель — опасно. И опять же — какие сигналы? Опять локи?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 07.10.15 10:20
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Сырой указатель — опасно.


Если ты знаешь, что хозяин дохнет позже пользователей, то нет.

·> И опять же — какие сигналы? Опять локи?


На передачу указателей локов не надо. А вот при одновременном обращении к содержимому указателя — возможно, локи нужны, как и в жабе и в шарпе.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[18]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 10:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>·>Короче, может и можно писать low latency на C++, но сложнее на порядок.

I>Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.
Испоконнее — pure C или даже ассемблер. Но традиция — не аргумент.

I>В джаве писать легче, но нет гарантии, что GC отработает точно в срок. Отсюда ясно, что рантайм надо сециально готовить — использовать специальный GC, всякие off-heap техники, что бы GC не лез когда не надо.

Нет гарантии и в случае с умными указателями, что освобождение заковыристого графа не нарвётся на lock или тупо будет работать долго, например, удаление одного объекта вызвало разрушение целой толпы других, gc же может съесть слона по кусочкам. А вообще есть Zing JVM и прочие RT GC. Задежка GC более 10ms — репортим баг.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[66]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 10:35
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Синтаксис в точности как у Linq. ) "Навигационные свойства" на мой взгляд не нужны. Но если вдруг кому-то очень понадобятся, то очевидно элементарно (т.к. уже есть полноценно работающие join"ы) добавляются в библиотеку. Биндингов нет и в EF. )))

S>> Есть. Сразу видно, что мало используешь SQL. Заметь твою библиотечку мало кто использует.

_>Эту библиотеку мало используют, потому что она только недавно появилась на свет. Если тебя интересуют популярные и проверенные временем ORM решения на C++ то смотри:

_>1. ODB — довольно жирный фреймворк на эту тему.
_>2. SOCI — лёгкая библиотечка (мой выбор до появления sqlpp11, т.к. я не люблю жирные фреймворки).
Так и приводи примеры из них. Я тебе кучу ссылок и примеров привожу. Просто понятно, что ты ими не пользуешься.

S>> Проще использовать конструкторы запросов, а вот с использованием навигационных свойств сразу и запросы и линки становятся намного привлекательнее.

S>> Не хай, то о чем имеешь очень поверхностное понятие.

_>Это похоже как раз ты имел дело исключительно с EF и меряешь по нему весь остальной мир. ))) Я же имел дело с ORM в разных языках, в том числе и в динамических (где с этим всё гораздо проще и сильнее). И там популярны совсем другие практики (хотя очевидно, что сделать аналогичное решение тривиально).

Я исключительно имею дело с 1С. EF это хобби. И я вижу огромные плюсы.

S>>По поводу биндинга

S>>
S>> dataGridView1.DataSource = db.Players.Local.ToBindingList();
S>>

S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>

S>>DbSet<TEntity>.Local — свойство
S>>Возвращает объект ObservableCollection<T>, содержащий локальное представление всех добавленных, неизменившихся и измененных сущностей в наборе. Это локальное представление остается синхронизированным по мере добавления или удаления сущностей из контекста. Аналогичным образом добавляемые или удаляемые из этого локального представления сущности автоматически добавляются в контекст или удаляются из контекста.


_>Ну так всё в точности как я и говорил. ObservableCollection, реализующая биндинг, не имеет никакого отношения к EF. Или может тебе показалось, что я говорил что биндинга нет во всём .net? )))

Ну вообще то это есть реализация классов и прокси которая реализуется компилятором и которые являются сущностями EF.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 10:52
Оценка: -1 :)
Здравствуйте, T4r4sB, Вы писали:

TB>·>Сырой указатель — опасно.

TB>Если ты знаешь, что хозяин дохнет позже пользователей, то нет.
А как узнать-то? Особенно в случае сложной системы, код которой постоянно меняется толпой программистов?

TB>·> И опять же — какие сигналы? Опять локи?

TB>На передачу указателей локов не надо.
Я имею в виду, что "сигнал" это тоже нечто передаваемое между тредами — и тоже не даётся бесплатно и обычно содержит локи внутри.

TB>А вот при одновременном обращении к содержимому указателя — возможно, локи нужны, как и в жабе и в шарпе.

Зачем же локи-то... Есть же volatile, happens-before, atomic и прочие вкусности.
Да и, скажем, в жабе-шарпе есть иммутабельные классы, которые безопасно использовать всегда без всяких оговорок. В C++ они принципиально невозможны из-за наличия деструктора, не говоря уж о const_cast и почри памяти.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[19]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 11:05
Оценка:
Здравствуйте, ·, Вы писали:

I>>·>Короче, может и можно писать low latency на C++, но сложнее на порядок.

I>>Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.
·>Испоконнее — pure C или даже ассемблер. Но традиция — не аргумент.

Ассемблер — очень смешно.

·>Нет гарантии и в случае с умными указателями, что освобождение заковыристого графа не нарвётся на lock или тупо будет работать долго, например, удаление одного объекта вызвало разрушение целой толпы других, gc же может съесть слона по кусочкам. А вообще есть Zing JVM и прочие RT GC. Задежка GC более 10ms — репортим баг.


Умный указатель это решается легко и руками.

lock — в low latency никто такое не имплементит изначально

"удаление одного объекта вызвало разрушение целой толпы других" —
а 1 в 1 как в джаве, только проблемы переносятся на GC
б 1 в 1 как в джаве, если разрушение это не просто занулени, а еще небольшая логика
в если убрать сматрпоинтеры, что часто даже лучше чем в джаве
Итого — на плюсах как минимум не хуже

GC ты вообще не контролируешь, никак и гарантии у тебя сильно хилые.
Re[65]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 11:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>http://rsdn.ru/forum/philosophy/5372076?tree=tree
Автор: Ikemefula
Дата: 23.11.13
ну конечно попутал... )))

I>Ага, понял, ты нашел доказательство, что дотнетных OR/M нет вещей, которые должны быть в OR/M искаропки ?
I>Есть целый форум на данном сайте, посвящен таким вот вопросам. Сходи туда, если ты хотел выяснить вопрос.

Мне это не нужно) Это я так, напомнил просто, что не всё так однозначно. )))

I>>>Это слишком древняя фраза, что бы пользоваться её без оглядки.

_>>Я думаю она справедлива для всего инженерного дела, одним из подвидов которого и является программирование.
I>И это чушь. Красота, как эстетическое, сильно субъективна, фактически — мода. Сегодня самолёты красивы, а завтра скажут, что это тупорылые огурцы. Из этого не следует, что самолеты должны задним числом перестать летать.

Истинная красота (которая гармония) не особо субъективна) А частенько может быть вообще выражена математическими выражениями.

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


Я думаю что на любом вменяемом языке (не брейнфаке) можно написать и красиво и ужасно. А вот написать красиво и при этом одновременно получить максимально быстрый код можно далеко не на каждом языке.
Re[66]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 11:30
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Ага, понял, ты нашел доказательство, что дотнетных OR/M нет вещей, которые должны быть в OR/M искаропки ?

I>>Есть целый форум на данном сайте, посвящен таким вот вопросам. Сходи туда, если ты хотел выяснить вопрос.

_>Мне это не нужно) Это я так, напомнил просто, что не всё так однозначно. )))


Здесь нет никакой неоднозначности а просто отсутствие вижлы в конкретный момент времени. На таких вот моментах ты и строишь свои "теории".
Сейчас у меня тоже нет вижлы и соответственно, ничего я тебе не покажу, даже на счет 2+2. Прикинь, какой вывод можно сделать: "Сенсация ! Дотнет не умеет 2+2 !!!!11одинодин"

I>>И это чушь. Красота, как эстетическое, сильно субъективна, фактически — мода. Сегодня самолёты красивы, а завтра скажут, что это тупорылые огурцы. Из этого не следует, что самолеты должны задним числом перестать летать.


_>Истинная красота (которая гармония) не особо субъективна) А частенько может быть вообще выражена математическими выражениями.


Вообще то субъективна. У разных культур разное представление о красоте и гармонии.

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

_>Я думаю что на любом вменяемом языке (не брейнфаке) можно написать и красиво и ужасно. А вот написать красиво и при этом одновременно получить максимально быстрый код можно далеко не на каждом языке.

Ну да, за неимением формулировки "красота" надо просто повторять "красиво" и всё станет красиво, ага.
Re[17]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 11:42
Оценка: +1
Здравствуйте, ·, Вы писали:

_>>shared pointer нужен в случае параллельного доступа к данным из разных потоков с неизвестным заранее временем жизни. Это совсем не частный случай даже в системах с подобным параллельным доступом. А если использовать более продуманные архитектуры (типа той же модели акторов), то подобные вопросы не встают в принципе. Тем более, что при использование семантики перемещения модель акторов становится такой же эффективной, как и просто общая память (в варианте без блокировок).

·>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.

Ничего подобного. Ты путаешь время жизни объектов и время жизни потоков. Вот смотри, допустим у нас есть главный поток (не обязательно по приложению, а скажем по задачке некой), который порождает N других потоков, с которыми взаимодействует через общую память (не факт что лучшее решение, но раз ты его хочешь, то давай обсудим). Для этого достаточно выделить память в главном потоке и хранить её как unique_ptr (или вообще просто объявить локальную переменную, что заметно удобнее). А дочерним потокам передать голый указатель (или вообще ссылку, что заметно удобнее) на эти данные. Такая система будет 100% безопасна в случае гарантий завершения дочерних потоков раньше главного. Если подобные гарантии не следуют из логики задачи, то их можно легко получить ручным способом, разместив в конце главного потока код ожидания (банальный thread.join() в случае C++) завершения дочерних потоков.

Так что, как видишь, у нас нет никаких намёков на необходимость использования shared_ptr для реализации взаимодействия потоков через общую память.

·>Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.


Всё правильно, упрощение. Которое при этом обеспечивает ещё и гарантию безопасности (которую в случае модели общей памяти надо достигать локами, в любом языке программирования) взаимодействия потоков. Ну а при правильной реализации можно получить ещё и быстродействие не хуже модели общей памяти.
Re[19]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 07.10.15 11:56
Оценка:
Здравствуйте, ·, Вы писали:

·>А как узнать-то? Особенно в случае сложной системы, код которой постоянно меняется толпой программистов?


В случае бардака — никак.

·>Я имею в виду, что "сигнал" это тоже нечто передаваемое между тредами — и тоже не даётся бесплатно и обычно содержит локи внутри.


Сигнал о конце работы вряд ли создаст проблему производительности.

·>Зачем же локи-то... Есть же volatile, happens-before, atomic и прочие вкусности.

·>Да и, скажем, в жабе-шарпе есть иммутабельные классы, которые безопасно использовать всегда без всяких оговорок. В C++ они принципиально невозможны из-за наличия деструктора, не говоря уж о const_cast и почри памяти.
Если уж говорить про const_cast, то я могу сказать, что в жабе можно сделать так, что 2*2=5. Это тоже правда, и это тоже наброс.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[67]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 12:06
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Эту библиотеку мало используют, потому что она только недавно появилась на свет. Если тебя интересуют популярные и проверенные временем ORM решения на C++ то смотри:

_>>1. ODB — довольно жирный фреймворк на эту тему.
_>>2. SOCI — лёгкая библиотечка (мой выбор до появления sqlpp11, т.к. я не люблю жирные фреймворки).
S>Так и приводи примеры из них. Я тебе кучу ссылок и примеров привожу. Просто понятно, что ты ими не пользуешься.

Какие примеры и для чего? ) Ты сформулируй точно тезис, который пытаешься доказать. Желательно с аргументами. Я на него посмотрю и выскажу своё согласие/несогласие. Тоже с аргументами. А пока я не пойму о чём у нас собственно основной спор и для чего ты выкладываешь какие-то куски кода.

_>>Это похоже как раз ты имел дело исключительно с EF и меряешь по нему весь остальной мир. ))) Я же имел дело с ORM в разных языках, в том числе и в динамических (где с этим всё гораздо проще и сильнее). И там популярны совсем другие практики (хотя очевидно, что сделать аналогичное решение тривиально).

S> Я исключительно имею дело с 1С. EF это хобби. И я вижу огромные плюсы.

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

_>>Ну так всё в точности как я и говорил. ObservableCollection, реализующая биндинг, не имеет никакого отношения к EF. Или может тебе показалось, что я говорил что биндинга нет во всём .net? )))

S> Ну вообще то это есть реализация классов и прокси которая реализуется компилятором и которые являются сущностями EF.

ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.
Re[20]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 12:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Испокон веков писали на С++, даже ОС реального времени наклепали десятками для таких случаев.

I>·>Испоконнее — pure C или даже ассемблер. Но традиция — не аргумент.
I>Ассемблер — очень смешно.
На спец-железе — не очень.

I>·>Нет гарантии и в случае с умными указателями, что освобождение заковыристого графа не нарвётся на lock или тупо будет работать долго, например, удаление одного объекта вызвало разрушение целой толпы других, gc же может съесть слона по кусочкам. А вообще есть Zing JVM и прочие RT GC. Задежка GC более 10ms — репортим баг.

I>Умный указатель это решается легко и руками.
Как? Как контролировать, что smartPtr.release() сожрёт не более N микросекунд?

I>lock — в low latency никто такое не имплементит изначально

I>"удаление одного объекта вызвало разрушение целой толпы других" -
I> а 1 в 1 как в джаве, только проблемы переносятся на GC
Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.
Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.

I> б 1 в 1 как в джаве, если разрушение это не просто занулени, а еще небольшая логика

I> в если убрать сматрпоинтеры, что часто даже лучше чем в джаве
I>Итого — на плюсах как минимум не хуже
Да, очевидно. Ибо сама java на C++ написана.

I>GC ты вообще не контролируешь, никак и гарантии у тебя сильно хилые.

GC это те же смартпоинтеры по сути, но более строгие, а значит контроля больше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[18]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 12:14
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.

_>Ничего подобного. Ты путаешь время жизни объектов и время жизни потоков. Вот смотри, допустим у нас есть главный поток (не обязательно по приложению, а скажем по задачке некой), который порождает N других потоков, с которыми взаимодействует через общую память (не факт что лучшее решение, но раз ты его хочешь, то давай обсудим). Для этого достаточно выделить память в главном потоке и хранить её как unique_ptr (или вообще просто объявить локальную переменную, что заметно удобнее). А дочерним потокам передать голый указатель (или вообще ссылку, что заметно удобнее) на эти данные. Такая система будет 100% безопасна в случае гарантий завершения дочерних потоков раньше главного. Если подобные гарантии не следуют из логики задачи, то их можно легко получить ручным способом, разместив в конце главного потока код ожидания (банальный thread.join() в случае C++) завершения дочерних потоков.
thread.join — опять локи. Да и жизнь потоков тут не причём.
Собственно об этом я и говорю "100% безопасна в случае" vs "100% безопасна".

_>Так что, как видишь, у нас нет никаких намёков на необходимость использования shared_ptr для реализации взаимодействия потоков через общую память.

Если надо "100% безопасна", то никуда не денешься.

_>·>Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.

_>Всё правильно, упрощение. Которое при этом обеспечивает ещё и гарантию безопасности (которую в случае модели общей памяти надо достигать локами, в любом языке программирования) взаимодействия потоков. Ну а при правильной реализации можно получить ещё и быстродействие не хуже модели общей памяти.
Да не надо локи. Есть много других механизмов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[20]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 12:20
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>А как узнать-то? Особенно в случае сложной системы, код которой постоянно меняется толпой программистов?

TB>В случае бардака — никак.
Почему никак? В случае java всегда так.

TB>·>Я имею в виду, что "сигнал" это тоже нечто передаваемое между тредами — и тоже не даётся бесплатно и обычно содержит локи внутри.

TB>Сигнал о конце работы вряд ли создаст проблему производительности.
Если не создаст — повезло с задачей. В low latency — любой lock создаёт проблемы.

TB>·>Зачем же локи-то... Есть же volatile, happens-before, atomic и прочие вкусности.

TB>·>Да и, скажем, в жабе-шарпе есть иммутабельные классы, которые безопасно использовать всегда без всяких оговорок. В C++ они принципиально невозможны из-за наличия деструктора, не говоря уж о const_cast и почри памяти.
TB>Если уж говорить про const_cast, то я могу сказать, что в жабе можно сделать так, что 2*2=5. Это тоже правда, и это тоже наброс.
Эээ. Давай, сделай. Интересно как можно похакать верифицируемый байт-код.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[19]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 12:32
Оценка: +1
Здравствуйте, ·, Вы писали:

_>>Ничего подобного. Ты путаешь время жизни объектов и время жизни потоков. Вот смотри, допустим у нас есть главный поток (не обязательно по приложению, а скажем по задачке некой), который порождает N других потоков, с которыми взаимодействует через общую память (не факт что лучшее решение, но раз ты его хочешь, то давай обсудим). Для этого достаточно выделить память в главном потоке и хранить её как unique_ptr (или вообще просто объявить локальную переменную, что заметно удобнее). А дочерним потокам передать голый указатель (или вообще ссылку, что заметно удобнее) на эти данные. Такая система будет 100% безопасна в случае гарантий завершения дочерних потоков раньше главного. Если подобные гарантии не следуют из логики задачи, то их можно легко получить ручным способом, разместив в конце главного потока код ожидания (банальный thread.join() в случае C++) завершения дочерних потоков.

·>thread.join — опять локи. Да и жизнь потоков тут не причём.
·>Собственно об этом я и говорю "100% безопасна в случае" vs "100% безопасна".

Лок перед завершение потока никого не беспокоит, т.к. это по сути просто отложенное освобождение ресурсов — никаких данных уже никто не ожидает.

_>>Так что, как видишь, у нас нет никаких намёков на необходимость использования shared_ptr для реализации взаимодействия потоков через общую память.

·>Если надо "100% безопасна", то никуда не денешься.

Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.

_>>·>Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.

_>>Всё правильно, упрощение. Которое при этом обеспечивает ещё и гарантию безопасности (которую в случае модели общей памяти надо достигать локами, в любом языке программирования) взаимодействия потоков. Ну а при правильной реализации можно получить ещё и быстродействие не хуже модели общей памяти.
·>Да не надо локи. Есть много других механизмов.

Например? )
Re[68]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 12:37
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Эту библиотеку мало используют, потому что она только недавно появилась на свет. Если тебя интересуют популярные и проверенные временем ORM решения на C++ то смотри:

_>>>1. ODB — довольно жирный фреймворк на эту тему.
_>>>2. SOCI — лёгкая библиотечка (мой выбор до появления sqlpp11, т.к. я не люблю жирные фреймворки).
S>>Так и приводи примеры из них. Я тебе кучу ссылок и примеров привожу. Просто понятно, что ты ими не пользуешься.

_>Какие примеры и для чего? ) Ты сформулируй точно тезис, который пытаешься доказать. Желательно с аргументами. Я на него посмотрю и выскажу своё согласие/несогласие. Тоже с аргументами. А пока я не пойму о чём у нас собственно основной спор и для чего ты выкладываешь какие-то куски кода.

Я привожу то, что хочу видеть в тех библиотеках, которые как ты считаешь круче EF

_>>>Это похоже как раз ты имел дело исключительно с EF и меряешь по нему весь остальной мир. ))) Я же имел дело с ORM в разных языках, в том числе и в динамических (где с этим всё гораздо проще и сильнее). И там популярны совсем другие практики (хотя очевидно, что сделать аналогичное решение тривиально).

S>> Я исключительно имею дело с 1С. EF это хобби. И я вижу огромные плюсы.

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


Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.

_>>>Ну так всё в точности как я и говорил. ObservableCollection, реализующая биндинг, не имеет никакого отношения к EF. Или может тебе показалось, что я говорил что биндинга нет во всём .net? )))

S>> Ну вообще то это есть реализация классов и прокси которая реализуется компилятором и которые являются сущностями EF.

_>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.

Кончно, оно есть у DBSEt.Local
https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx

Пространство имен: System.Data.Entity
Сборка: EntityFramework (в EntityFramework.dll)
и солнце б утром не вставало, когда бы не было меня
Re[21]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 07.10.15 12:39
Оценка:
Здравствуйте, ·, Вы писали:

·>Почему никак? В случае java всегда так.

Да, жаба лучше себя ведёт, когда надо нанять 100500 индусов, это её известно преимущество.

·>Если не создаст — повезло с задачей. В low latency — любой lock создаёт проблемы.

Сборка мусора — это тоже лок.

·>Эээ. Давай, сделай. Интересно как можно похакать верифицируемый байт-код.

http://ideone.com/o1h0hR
const_cast ничем не лучше этого кода.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[21]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 13:05
Оценка:
Здравствуйте, ·, Вы писали:

I>>GC ты вообще не контролируешь, никак и гарантии у тебя сильно хилые.

·>GC это те же смартпоинтеры по сути, но более строгие, а значит контроля больше.

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

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

С с GC у тебя будет всегда GC и никуда от этого не денешься. Любое твое телодвижение должно быть согласовано с GC, иначе будут вылазить задержки.
Ошибся "здесь" — задержка вылезет черз секунду "там"
Re[17]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 13:28
Оценка:
Здравствуйте, ·, Вы писали:

dot>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.


При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
Вот конкретный пример (первые минут двадцать)
http://www.youtube.com/watch?v=Q-7y1u9kZV0
Отредактировано 07.10.2015 13:28 Evgeny.Panasyuk . Предыдущая версия .
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 14:11
Оценка:
Здравствуйте, ·, Вы писали:

dot>Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.


Если ограничивать GC пороговой latency — то можно получить OOM — банально скорость очистки будет меньше необходимой.
При этом учти что полноценный цикл GC линеен от количества N живых объектов — может быть например большое N, при малом потоке изменений reachable/unreachable.

dot>Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.


Почему вручную-то? Если есть такой развесистый граф владения — то и очищай его по частям, автоматически.
Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.
Re[22]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 14:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>GC это тяжелый алгоритм, который работает в фоне, ты максимум можешь выключить его или включить, конфигурацию задать на старте и всё.

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

"писать как на Си (для производительности)" — распространённый миф/байка. Отказавшись от C++ в пользу "как на C" — ты не получишь никаких преимуществ относительно производительности, а вот недостатки вполне. Точнее есть пара тонких абстрактных моментов, но речь точно не о них.
И, например, там где нужен ref-counting в C++ — он нужен и в C http://rsdn.ru/forum/philosophy/6200891.1
Автор: Evgeny.Panasyuk
Дата: 02.10.15
Re[20]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 14:30
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>thread.join — опять локи. Да и жизнь потоков тут не причём.

_>·>Собственно об этом я и говорю "100% безопасна в случае" vs "100% безопасна".
_>Лок перед завершение потока никого не беспокоит, т.к. это по сути просто отложенное освобождение ресурсов — никаких данных уже никто не ожидает.
Тут ведь как... Поток можно и не завершать, или приступить к обработке следующего действия.

_>>>Так что, как видишь, у нас нет никаких намёков на необходимость использования shared_ptr для реализации взаимодействия потоков через общую память.

_>·>Если надо "100% безопасна", то никуда не денешься.
_>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.

_>>>·>Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.

_>>>Всё правильно, упрощение. Которое при этом обеспечивает ещё и гарантию безопасности (которую в случае модели общей памяти надо достигать локами, в любом языке программирования) взаимодействия потоков. Ну а при правильной реализации можно получить ещё и быстродействие не хуже модели общей памяти.
_>·>Да не надо локи. Есть много других механизмов.
_>Например? )
CAS, volatile, happens-before.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 14:45
Оценка:
Здравствуйте, ·, Вы писали:

_>>>>Так что, как видишь, у нас нет никаких намёков на необходимость использования shared_ptr для реализации взаимодействия потоков через общую память.

_>>·>Если надо "100% безопасна", то никуда не денешься.
_>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
dot>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.

Этот use-case формулируется немного по-другому, например: нужно чтобы ресурс освобождался как только завершится последний поток его использующий, и какой из них будет последним — заранее не известно.
Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java. На Java кстати какое решение можешь предложить?

_>>>>·>Модель акторов — в первую очередь для упрощения параллелизма, а не low latency.

_>>>>Всё правильно, упрощение. Которое при этом обеспечивает ещё и гарантию безопасности (которую в случае модели общей памяти надо достигать локами, в любом языке программирования) взаимодействия потоков. Ну а при правильной реализации можно получить ещё и быстродействие не хуже модели общей памяти.
_>>·>Да не надо локи. Есть много других механизмов.
_>>Например? )
dot>CAS, volatile, happens-before.

На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 14:57
Оценка:
Здравствуйте, ·, Вы писали:

TB>>А вот при одновременном обращении к содержимому указателя — возможно, локи нужны, как и в жабе и в шарпе.

dot>Зачем же локи-то... Есть же volatile, happens-before, atomic и прочие вкусности.

Это лишь средства, с помощью которых в том числе получаются локи

dot>Да и, скажем, в жабе-шарпе есть иммутабельные классы, которые безопасно использовать всегда без всяких оговорок. В C++ они принципиально невозможны из-за наличия деструктора,


Причём тут деструктор? Он относится к времени жизни, а не к иммутабельности/константности. Когда деструктор начал работу — время жизни объекта уже закончилось, если к нему кто-то обратился после этого извне — то будут проблемы, независимо от того была ли константность или нет.

dot>не говоря уж о const_cast


Не, не серьёзно.

dot>и почри памяти.


В любой непонятной ситуации приводи как аргумент возможную порчу памяти
Re[17]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 15:21
Оценка:
Здравствуйте, ·, Вы писали:

EP>>·>Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.

dot>Кстати, в java unique практически сам выводится — в тех тривиальных случаях когда ты бы стал использовать unique, java обыно делает escape analysis,

Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен
Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.

dot>да и Young Generation собирается очень быстро.


Во сколько раз "быстро" быстрее "мгновенно"?

EP>>·>Если нужна передача данных между тредами — нужен shared pointer,

EP>>Он нужен только в случаях когда потоки владеют какими-то общими данными и точный момент удаления заранее не определён.
EP>>Если просто нужно передать данные и владение в другой поток, то достаточно и unique, и то не факт — может быть хватит обычного перемещения.
dot>Не владеют, а шарят...

А шарят они что по-твоему? Цитата из стандарта: "shared_ptr implements semantics of shared ownership"

dot>Будешь передавать weak_ptr, а значит опять локи.


Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.

dot>Для перемещения — YG опять же.


Причём тут YG? Перемещать можно даже старые объекты

dot>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.


А например OOM — тоже вполне серьёзно

dot>А ещё аллокация из кучи — глобальный лок. В общем, тормоза повсюду.


Специальные аллокаторы и т.п. — вполне распространённая практика.
Значит в случае Java ты готов использовать и специальную VM, и специальный GC, отказываться от классов, а в случае C++ специальные аллокатор ни в коем случае

dot>Короче, может и можно писать low latency на C++, но сложнее на порядок.


Это фантазии, ничем не обоснованные.

EP>>·>который использует lock (mutex?) -

EP>>Обычно в реализациях атомарные inc/dec.
dot>Это где? Вот тут вроде mutex.

И там же atomics. Mutex это лишь fallback для платформ в которых нет подходящих атомарных операций
Re[69]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 15:25
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Какие примеры и для чего? ) Ты сформулируй точно тезис, который пытаешься доказать. Желательно с аргументами. Я на него посмотрю и выскажу своё согласие/несогласие. Тоже с аргументами. А пока я не пойму о чём у нас собственно основной спор и для чего ты выкладываешь какие-то куски кода.

S> Я привожу то, что хочу видеть в тех библиотеках, которые как ты считаешь круче EF

"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?

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

S>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.

Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.

_>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.

S> Кончно, оно есть у DBSEt.Local
S>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>Пространство имен: System.Data.Entity
S>Сборка: EntityFramework (в EntityFramework.dll)

А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )
Re[21]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 15:47
Оценка:
Здравствуйте, ·, Вы писали:

_>>Лок перед завершение потока никого не беспокоит, т.к. это по сути просто отложенное освобождение ресурсов — никаких данных уже никто не ожидает.

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

Тогда значит и данные тем более никуда не денутся. )

_>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.

·>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.

С чего это ты взял, что не могу? ) Да, и ты снова привёл не конкретный пример, а абстрактные рассуждения. Давай конкретную задачку и посмотрим могу или нет... )))

_>>·>Да не надо локи. Есть много других механизмов.

_>>Например? )
·>CAS, volatile, happens-before.

Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.
Re[70]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 15:56
Оценка:
Здравствуйте, alex_public, Вы писали:



_>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?

Заметно быстрее чего? Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.
Проблема в скорости в том, что нет прокси для получения навигационных свойств, дополнительные данные для биндинга итд.
Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.
Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.

Кстати неизвестно насколько твой sqlpp11 генерирует оптимальный SQL код на сложных запросах. Я приводил результирующие SQL на нетривиальных запросах.
В своё время EF был очень далек от оптимальности. Сейчас уже достаточно близко к идеалу. Как и что генерит sqlpp11 неизвестно.

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

S>>Ты взял на себя утверждение, что EF отстой. Тебе и доказывать. Я привожу тебе решения которые есть в EF.

_>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.

И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.

_>>>ObservableCollection не генерируется компилятором, а лежит в System.dll. И да, в EF создаются всякие там промежуточные классы для работы с БД (на то оно и ORM), но к биндингу с GUI это отношения не имеет.

S>> Кончно, оно есть у DBSEt.Local
S>>https://msdn.microsoft.com/ru-ru/library/gg696248(v=vs.113).aspx
S>>Пространство имен: System.Data.Entity
S>>Сборка: EntityFramework (в EntityFramework.dll)

_>А ещё классы из EF наверняка умеют исключения кидать. И возможно события какие-то. Означает ли это, что исключения и т.п. реализованы в EF? )

Это значит, что оболочка на запросом намного более функциональная, чем в sqlpp11. Я в свое время делал объектную модель над DBF. Данные считывались в структуру над которой строились свойства и тд. Все очень быстро с минимумом затрат. И никому это не было нужно не смотря на охринительную скорость.
Просто люди не понимали и пользовались более понятными инструментами.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 07.10.2015 16:38 Serginio1 . Предыдущая версия .
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 16:31
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Почему никак? В случае java всегда так.

TB>Да, жаба лучше себя ведёт, когда надо нанять 100500 индусов, это её известно преимущество.
Т.е. неиндусы — никогда не ошибаются? Даже дело не в том, что ошибаются или нет — проверить никак нельзя.

TB>·>Если не создаст — повезло с задачей. В low latency — любой lock создаёт проблемы.

TB>Сборка мусора — это тоже лок.
Не всегда, и не везде.

TB>·>Эээ. Давай, сделай. Интересно как можно похакать верифицируемый байт-код.

TB>http://ideone.com/o1h0hR
TB>const_cast ничем не лучше этого кода.
Во-первых, это не "2+2 == 5", а "Integer.valueOf(4) == 5".
Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно.
В-третьих, вот так в C++ писать уже можно?
volatile ImmutableClass *var = NULL;
...
//thread 1
var = new ImmutableClass();
//thread 2
if(var != NULL)
  Var.doSomething();

Раньше, афаир, нельзя было.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 16:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>GC ты вообще не контролируешь, никак и гарантии у тебя сильно хилые.

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

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

I>На худой конец, "писать как на Си"

I>С с GC у тебя будет всегда GC и никуда от этого не денешься. Любое твое телодвижение должно быть согласовано с GC, иначе будут вылазить задержки.

I>Ошибся "здесь" — задержка вылезет черз секунду "там"
gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.
А вообще говоря, все эти смартпоинтеры по сути — примитивные алгоритмы gc.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[18]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 16:40
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.


EP>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.

EP>Вот конкретный пример (первые минут двадцать)
EP>http://www.youtube.com/watch?v=Q-7y1u9kZV0
Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы). Невалидные же указатели могут испортить всё что угодно во всём процессе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[71]: Java vs C# vs C++
От: alex_public  
Дата: 07.10.15 16:42
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?

S> Заметно быстрее чего?

Вроде бы вполне ясно написано. sqlpp11 заметно быстрее EF (да и вообще любого ORM на базе linq).

S>Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.


Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.

S>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.


Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

S> Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.


Что значит я ставлю скорость во главу угла? ) Я пока что всего лишь сделал утверждение о быстродействие двух разных ORM. И я так понимаю по этому поводу нет никаких возражений? ))) Если же начинать говорить о выборе какого-то из них для какой-то конкретной задачи, то это уже глупо будет, т.к. данные ORM реализованы на разных платформах, выбор между которыми для какой-то задачи явно будет определяться не возможностями ORM, а более серьёзными вещами. А соответственно выбрав платформу мы автоматически получим выбор ORM (ну если говорить о выборе между двумя обсуждаемыми вариантами, так то под каждую платформу есть много вариантов).

_>>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.

S> И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
S> SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
S>Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.

Лучше смотреть не в википедии, а на сайте производителя http://www.sqlalchemy.org и там на самом деле весьма много отличий. )))
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 16:48
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.

EP>Если ограничивать GC пороговой latency — то можно получить OOM — банально скорость очистки будет меньше необходимой.
EP>При этом учти что полноценный цикл GC линеен от количества N живых объектов — может быть например большое N, при малом потоке изменений reachable/unreachable.
ООМ везде можно получить. Тем более мы говорим о латенси, т.е. затупить большие latency spikes, а не высокий throughput когда шпарит высокая нагрузка постоянно.

dot>>Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.

EP>Почему вручную-то? Если есть такой развесистый граф владения — то и очищай его по частям, автоматически.
По каким частям? Как эти части определить? В каком порядке очищать? Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc.

EP>Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.

Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 16:48
Оценка:
Здравствуйте, ·, Вы писали:

dot>Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно.


Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.

dot>В-третьих, вот так в C++ писать уже можно?

dot>
dot>volatile ImmutableClass *var = NULL;
dot>...
dot>//thread 1
dot>var = new ImmutableClass();
dot>//thread 2
dot>if(var != NULL)
dot>  Var.doSomething();
dot>

dot>Раньше, афаир, нельзя было.

В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 16:56
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Это не частный случай, а наиболее простая имплементация. Конечно, можно внимательно изучить, установить время жизни каждого объектика, но это сложно контролировать и тестировать, а в случае ошибки — undefined behaviour. В случае же java — самое страшное что будет — это latency spike из-за garbage collection, а не порча данных, как в случае ошибок с указателями.

EP>>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
EP>>Вот конкретный пример (первые минут двадцать)
EP>>http://www.youtube.com/watch?v=Q-7y1u9kZV0
dot>Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы).

Да, но мы-то обсуждаем именно такой случай, именно эту самую область кода. И эта ручная error-prone нарезка на структуры, отказ от GC и т.п. — по сути выливается в уровень ниже чем C, и в результате приводит к вполне ожидаемым ошибкам: http://rsdn.ru/forum/philosophy/6201205.1
Автор: Evgeny.Panasyuk
Дата: 02.10.15
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 07.10.15 16:57
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

_>>>·>Если надо "100% безопасна", то никуда не денешься.

_>>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
dot>>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.
EP>Этот use-case формулируется немного по-другому, например: нужно чтобы ресурс освобождался как только завершится последний поток его использующий, и какой из них будет последним — заранее не известно.
EP>Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java.
Не завершится, а освободит последнюю ссылку на ресурс. Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение, вызывая непредсказуемые проблемы с latency.

EP>На Java кстати какое решение можешь предложить?

На java память ресурс другого типа. "Освобождать память" там нельзя. А для ресурсов в общем случае — наследники java.lang.ref.Reference.

_>>>·>Да не надо локи. Есть много других механизмов.

_>>>Например? )
dot>>CAS, volatile, happens-before.
EP>На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.
Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[23]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 16:58
Оценка: :)
Здравствуйте, ·, Вы писали:

I>>Ошибся "здесь" — задержка вылезет черз секунду "там"

·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.

Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве.
Re[23]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 17:04
Оценка: -1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>На худой конец, "писать как на Си"


EP>"писать как на Си (для производительности)" — распространённый миф/байка.


Это факты.

>Отказавшись от C++ в пользу "как на C" — ты не получишь никаких преимуществ относительно производительности, а вот недостатки вполне.


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

EP>И, например, там где нужен ref-counting в C++ — он нужен и в C


Наоборот. Рефкаунтинг нужен только в редких случаях. Что характерно, в таких случаях он нужен и в менеджед средах. В С++ это чуть не везде, как дешовая замена ГЦ, от чего растут жесточайшие проблемы.
Re[23]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 17:11
Оценка: +1
Здравствуйте, ·, Вы писали:

EP>>Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java.

·>Не завершится, а освободит последнюю ссылку на ресурс. Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение, вызывая непредсказуемые проблемы с latency.

Это самое "внезапно" если речь про освобождение памяти, лечится известными способами.
А если чтото большее, то "внезапно" будет и в джаве. Например этот последний должен помахать ручкой, сделать запись, что все, отработали, и запустить новую операцию.
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 17:12
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Да, но gc не обязан это делать всё и сразу, вместо паузы в 100ms он сделает 1500 пауз по 100us. Да, throughput может и меньше, зато latency предсказуемее.

EP>>Если ограничивать GC пороговой latency — то можно получить OOM — банально скорость очистки будет меньше необходимой.
EP>>При этом учти что полноценный цикл GC линеен от количества N живых объектов — может быть например большое N, при малом потоке изменений reachable/unreachable.
dot>ООМ везде можно получить.

Я описываю конкретный case, который есть при использовании GC, и которого нет при использовании scope-based lifetime.
Не надо оправдываться абстрактными "OOM везде можно получить" — я так тоже умею: "везде можно получить расстрел памяти, даже при использовании Java"

dot>>>Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.

EP>>Почему вручную-то? Если есть такой развесистый граф владения — то и очищай его по частям, автоматически.
dot>По каким частям?

Например очищать фиксированное количество объектов за раз, оставшиеся ставить в очередь.

dot>Как эти части определить?


Как того требует задача. Если нужно ограничить время — то соответственно засекаешь время/тики, или что там удобнее.

dot>В каком порядке очищать?


Например в порядке очереди.

dot>Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc.


Нет, это неверно. Задача GC в первую очередь отличить reachable от unreachable объектов. А уж делать reclaim порциями, или за один присест — это уже отдельное свойство, причём ортогональное наличию/отсутствию GC.
И, кстати, для C++ возможен и runtime'овый GC (прям в стандарте есть специальное API), и библиотечный (я даже как-то делал for fun).

EP>>Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.

dot>Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).

При этом сделав O(N) обход живых объектов, которого нет в случае с C++
Re[23]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 07.10.15 17:28
Оценка:
Здравствуйте, ·, Вы писали:

·>Т.е. неиндусы — никогда не ошибаются? Даже дело не в том, что ошибаются или нет — проверить никак нельзя.

То есть С++ требовательнее к дисциплине программиста. Это его недостаток. Что не так?

·>Не всегда, и не везде.

Любую схему (по крайней мере, среди тупой императивщины) можно реализовать в С++. Если очень надо. Это иногда намного менее удобно, чем в других языках, ясен пень, ну так С++ и не пихают везде подряд, и серебрянной пулей он не является.

·>запретить const_cast же — невозможно.

Это уныло. Ругать язык за то, что в нём можно сделать диверсию — это уныло, потому что диверсию можно сделать в любом языке, что я и показал. И говорить, что якобы в одном языке обнаружить такую откровенную (как конст_каст) диверсию проще, чем в другом — это тоже уныло.

·>В-третьих, вот так в C++ писать уже можно?

А проблема-то в чём? Расскажи, почему в жабе так можно делать (с локами? без них?), а в С++ нельзя? Что за хрень эти иммутабельные классы? Аааа, я понял, в жабе нету типа "указатель на константу", поэтому "иммутальные классы" преподносятся, как откровение.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 17:39
Оценка:
Здравствуйте, ·, Вы писали:

_>>>>·>Если надо "100% безопасна", то никуда не денешься.

_>>>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.
dot>>>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.
EP>>Этот use-case формулируется немного по-другому, например: нужно чтобы ресурс освобождался как только завершится последний поток его использующий, и какой из них будет последним — заранее не известно.
EP>>Вот так — да, как вариант решения подсчёт ссылок, и то в малом количестве мест. Только решать эту проблему нужно и в C, и сюрприз в Java.
dot>Не завершится, а освободит последнюю ссылку на ресурс.

Верно.

dot>Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение,


Пусть просто поставит в очередь, делов-то

EP>>На Java кстати какое решение можешь предложить?

dot>На java память ресурс другого типа. "Освобождать память" там нельзя.

А я поэтому и сказал конкретно "ресурс", а не просто "объект". Да и память не ресурс только если она не ограниченна — упрёшься в предел, получишь удар по latency, на который постоянно ссылаешься.

dot>А для ресурсов в общем случае — наследники java.lang.ref.Reference.


Каким образом они обеспечат prompt finalization?

_>>>>·>Да не надо локи. Есть много других механизмов.

_>>>>Например? )
dot>>>CAS, volatile, happens-before.
EP>>На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.
dot>Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.

При GC чуть проще реализация lockfree структур данных, за счёт ABA, но при этом сами GC в большинстве своём не lockfree (lockfree GC видел только в статьях) — то есть тут уже большой терминологический вопрос, остаётся ли структура данных lockfree при не non-lockfree GC
Да и такие структуры должны реализовывать профессионалы своего дела, так как это трудная/опасная тема.
Re[72]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 17:42
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>"Круче" — это не инженерный термин. Я такого не использовал. Я говорил о том, что sqlpp11 заметно быстрее (вот это уже инженерный термин) EF при одинаковом синтаксисе. Против этого есть какие-то возражения или нет?

S>> Заметно быстрее чего?

_>Вроде бы вполне ясно написано. sqlpp11 заметно быстрее EF (да и вообще любого ORM на базе linq).


S>>Я могу через t4 используя Linq сгенерировать запросы и классы для заполнения. По скорости будет то же самое.


_>Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.


S>>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.


_>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

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

S>> Еще раз ты ставишь скорость во главу угла. Еще раз напомню про 1С где скорость интерпритатора не в разы, а в сотни и тысячи раз медленнее. Но мало кого это беспокоит. Главное скорость разработки.


_>Что значит я ставлю скорость во главу угла? ) Я пока что всего лишь сделал утверждение о быстродействие двух разных ORM. И я так понимаю по этому поводу нет никаких возражений? ))) Если же начинать говорить о выборе какого-то из них для какой-то конкретной задачи, то это уже глупо будет, т.к. данные ORM реализованы на разных платформах, выбор между которыми для какой-то задачи явно будет определяться не возможностями ORM, а более серьёзными вещами. А соответственно выбрав платформу мы автоматически получим выбор ORM (ну если говорить о выборе между двумя обсуждаемыми вариантами, так то под каждую платформу есть много вариантов).


Еще раз твои утверждения голословны. Почему ты считаешь, что наколеночная реализация сделает оптимальный реализацию СКул запроса. Где тесты одинаковых запросов?
_>>>Не надо от моего имени высказывать какие-то странные фразы. Я говорил вполне конкретные вещи (см. выше) и их уже вполне доказал. А SQLAlchemy я посоветовал посмотреть уже не в качестве аргумента в данной дискуссии, а просто для расширения кругозора на тему вариантов реализации мощных ORM. А то знать только подобное EF — это как-то печально.
Ничего ты не доказал. Ты только утверждаешь, что генерится запрос на этапе компиляции. Его эффективность ты не доказал. На самом деле бывают очень сложнве запросы, где не всегда эффективно генерится запрос. Кроме того запросы кэширутся и есть куча динамических запросов которые могут различаться как по количеству параметров запроса так и по условиям соединениям итд.
Все твои выкладки голословны. Нет ни одного сравнения.
S>> И это говорит человек незнающий 1С и EF. Я тебе кучу примеров и статей на русском. А ты дал просто название, без всяких ссылок. Поверь мне интересны новые подходы.
S>> SQLAlchemy я так понимаю, что это библиотека для питона. Вопрос в чем отличие от 1С?
S>>Посмотрел https://ru.wikibooks.org/wiki/SQLAlchemy. Не увидел ничего нового.

_>Лучше смотреть не в википедии, а на сайте производителя http://www.sqlalchemy.org и там на самом деле весьма много отличий. )))

Смотрел, там так и не нашел. Так если ты знаток ЕФ расскажи плюсы и минусы. Заметь я тебе кучу примеров привел, что бы е быть голословным
и солнце б утром не вставало, когда бы не было меня
Re[24]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 17:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>На худой конец, "писать как на Си"

EP>>"писать как на Си (для производительности)" — распространённый миф/байка.
I>Это факты.

Приведи аргументы в поддержку "фактов".

>>Отказавшись от C++ в пользу "как на C" — ты не получишь никаких преимуществ относительно производительности, а вот недостатки вполне.

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

Относительно производительности — сплошные недостатки

I>В С++ это чуть не везде, как дешовая замена ГЦ,


Дешёвая замена GC это прежде всего scope-based lifetime management.
Даже если использовать refcounting не только для решения задач в которых есть естественное разделение владения, а и для случаев где можно спокойно обойтись например unique_ptr — таких случаев всё равно на порядки меньше чем "new" в управляемых языках.

I>от чего растут жесточайшие проблемы.


Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).
Непосредственно ref-counting (в тех случаях где он не нужен по задаче, но нужны указатели) — это где-то на уровне процентов от общих проблем.
Re[11]: Java vs C# vs C++
От: PM  
Дата: 07.10.15 18:30
Оценка: +1
Здравствуйте, ·, Вы писали:

PM>> Почитайте на досуге как авторы LMAX героически боролись (и вроде бы продолжают бороться) с JVM — пытаясь выровнять данные по границе кэш-линии; как затюнинговать сборку мусора, чтобы система не замерзала в неподходящий момент (и перезапускать всё разв в сутки в конечном итоге)


PM>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>

·>Собственно сейчас в моде Zing JVM, там задержки не более 10ms, в основном ~100us.
·>Писать такое на C++... неее... проще застрелиться.
·>А перезапуск нужен не для gc, а чтобы на диск состояние скинуть, ибо использовать классические СУБД — теоретически невозможно.

Задержка 10ms может быть неприемлемой в некоторых задачах, в том числе и в биржевых системах.

Состояние на диск постоянно скидывается в LMAX в отдельном потоке в файл журнала. И разработчики LMAX повоевали и здесь чтобы добиться предсказуемого результата. Ну и для сетевого I/O наверняка использовали какой-нибудь NIO.

Я почитал ваши сообщения в ветке. Ещё одна иллюстрация, что люди не из мира C++ продолжают верить в мифы 15-20 летней давности. Авторы LMAX скорее всего тоже подумали: "Писать такое на C++... неее... проще застрелиться" и взяли хорошо известный им и широко распространённый инструмент. Хорошо, что при этом они не застрелились

Часть кода, кстати, открыта: https://github.com/LMAX-Exchange/disruptor и выглядит на мой взгляд over engineering. Хотя, может для Java мира это нормально
Re[72]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.15 20:31
Оценка:
Здравствуйте, alex_public, Вы писали:



_>Безусловно. А можно даже и без t4 просто голые sql строки вставить и опять же будет отличная скорость. Нюанс в том, что в обоих этих случаях синтаксис станет не как у linq. А вот sqlpp11 сохраняет такой синтаксис без потерь в скорости.


S>>Есть дополнительные расходы. Но функциональность sqlpp11 не в какое сравнение с EF нет и близко.


_>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

Еще раз без навигационных свойств снижает функциональность в разы. Поверь мне, так как знаю разницу.
По быстродействию. Самая распространенная задача это когда есть некий отчет, где пользователь может наложить до 6 и более условий.
Причем например для справочников эти условия могут быть как равны элементу либо входить в группу. Невыбранные параметры не участвуют в запросе.
Смыла в статическом запросе никакого нет. Кроме того поддержка разных баз, провайдеров итд
Но опять когда эта скорость нужна? Для клиента то он её просто незаметит. А например для Asp.Net то если сильнозагруженный сервер по 1000 запросов в секунду, то тогда стоит заморочится на скорость. Но таких задач ооочень мало.

Ну и поддержка БД в EF больше https://social.msdn.microsoft.com/Forums/ru-RU/16b09dc7-64ea-47b4-ba1c-a94499378355/ef6-more-than-one-factory?forum=adodotnetentityframework
и солнце б утром не вставало, когда бы не было меня
Отредактировано 08.10.2015 6:29 Serginio1 . Предыдущая версия .
Re[25]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.10.15 20:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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

EP>Относительно производительности — сплошные недостатки

Тебе снова показать какую часть ты не сумел прочитать ? "Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов". low latency никогда не требовал экстремальной производительности от компилятора, потому и пишется реалтайм в т.ч. на менеджед языках.

EP>Даже если использовать refcounting не только для решения задач в которых


Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ?

EP>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).


Ужос, кто бы мог подумать ?

EP>Непосредственно ref-counting (в тех случаях где он не нужен по задаче, но нужны указатели) — это где-то на уровне процентов от общих проблем.


Вообще говоря неверно. Там где он не нужен, освобождение графа объектов может занять "хрен знает сколько", а это уже на low latency не тянет.
Re[26]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 07.10.15 21:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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

EP>>Относительно производительности — сплошные недостатки
I>Тебе снова показать какую часть ты не сумел прочитать ?

А ты перестал пить коньяк по утрам? Реально, завязывай со своей дешёвой демагогией.

I>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов".


Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".

I>low latency никогда не требовал экстремальной производительности от компилятора,


Это прежде всего low latency, а для low нужна в том числе скорость.

EP>>Даже если использовать refcounting не только для решения задач в которых

I>Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ?

На C та часть которая "не только" (то есть опциональная) — она не реализуема.

EP>>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).

I>Ужос, кто бы мог подумать ?

Видимо не ты, раз говоришь что от ref-counting "растут жесточайшие проблемы".

EP>>Непосредственно ref-counting (в тех случаях где он не нужен по задаче, но нужны указатели) — это где-то на уровне процентов от общих проблем.

I>Вообще говоря неверно. Там где он не нужен, освобождение графа объектов может занять "хрен знает сколько", а это уже на low latency не тянет.

Ты выделенное читал?
Re: Java vs C# vs C++
От: A13x США  
Дата: 08.10.15 04:16
Оценка:
Здравствуйте, xRAZORx, Вы писали:

RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


Я делал замеры — эквивалентный С++ код часто сравним, а иногда очень сильно отстает от эквивалентного кода на java (оверхед для generic хипа) — см. тему.
Заранее оговорюсь — что в определенных задачах, конечно, С++ может показать сильный отрыв и по быстродействию и по потреблению памяти, хотя в прикладном программировании таких задач не так много.
В то же время jvm может выполнять оптимизации принципиально недоступные для при статической компиляции.

Для желающих проверить на практике — предлагаю желающим реализовать простейший интерпретатор нетипизированного лямбда исчисления на С++ (ну то есть REPL который бы понимал что-то вроде такого) и сравнить его быстродейтвие с тем, что можно реализовать на яве (мой вариант меньше 500 строк и по быстродействию уделывает известные мне интерпретаторы scheme). Насколько я себе представляю возможные реализации — на стресс тестах будет большое количество виртуальных вызовов и большое количество выделений памяти под мелкие объекты.

И да, согласен, что это тоже не типичная прикладная задача

Eсли лень реализовывать — достаточно сравнить эти два варианта: на С++ и на Java — приближенные к тому, что пришлось бы иметь в коде интерпретатора.
Re[30]: Java vs C# vs C++
От: m.aksenov Россия http://maksenov.info/
Дата: 08.10.15 04:41
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>Я вот могу ещё один очень известный пример привести на похожую тему. Питон сейчас очень популярен в научной среде. Причём не только для написания скриптов (что логично), но и для сложных и тяжёлых вычислений. Казалось бы нонсенс, но секрет раскрывается просто — для таких дел используются специальные библиотеки (типа numpy), которые написаны опять же на C/C++. В итоге получаем сочетания максимального быстрого написания кода с одновременной неплохой производительностью.


В научной среде популярны: Matlab, Mathematica, Statistica, R, Octave, Fortran, наконец. И большинство этих инструментов эффективнее питона (даже с C/C++ биндингами) с точки зрения производительности.

Питон активно пользуют т.н. data scientists, но по причинам, которые к производительности отношение имеют отдаленное.
Re[2]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 05:08
Оценка:
Здравствуйте, A13x, Вы писали:

RAZ>>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.

A>Я делал замеры — эквивалентный С++ код часто сравним,

Сильное утверждение. На каком уровне? И там и там высокий уровень? Или на Java низкий?

A>а иногда очень сильно отстает от эквивалентного кода на java (оверхед для generic хипа) — см. тему.


Так там такая задача(очень близкая к реализации языка с GC, типа Unlambda), что позволяет раскрываться языку с GC+JIT во всей красе.
И даже при всём при этом получилось забороть
Автор: Evgeny.Panasyuk
Дата: 29.06.15
ref-counting'ом

A>Заранее оговорюсь — что в определенных задачах, конечно, С++ может показать сильный отрыв и по быстродействию и по потреблению памяти, хотя в прикладном программировании таких задач не так много.


Не так много задач где это требуется/заметно? Или не так много где есть сильный отрыв?
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 05:21
Оценка:
Здравствуйте, m.aksenov, Вы писали:

_>>Я вот могу ещё один очень известный пример привести на похожую тему. Питон сейчас очень популярен в научной среде. Причём не только для написания скриптов (что логично), но и для сложных и тяжёлых вычислений. Казалось бы нонсенс, но секрет раскрывается просто — для таких дел используются специальные библиотеки (типа numpy), которые написаны опять же на C/C++. В итоге получаем сочетания максимального быстрого написания кода с одновременной неплохой производительностью.

MA>В научной среде популярны: Matlab, Mathematica, Statistica, R, Octave, Fortran, наконец. И большинство этих инструментов эффективнее питона (даже с C/C++ биндингами) с точки зрения производительности.
MA>Питон активно пользуют т.н. data scientists, но по причинам, которые к производительности отношение имеют отдаленное.

Python популярен у инженеров различных областей. Причём на нём пишут и как отдельные программы, так и используют в виде скриптовых движков (например ParaView).
Re[32]: Java vs C# vs C++
От: m.aksenov Россия http://maksenov.info/
Дата: 08.10.15 06:01
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Python популярен у инженеров различных областей. Причём на нём пишут и как отдельные программы, так и используют в виде скриптовых движков (например ParaView).


Инженерная и научная среды различаются.

Да, использовать Python / Jython в качестве скриптового движка это разумное решение, так как язык сам по себе не самый неплохой, но причины встраивания именно его в распространенности и относительной простоте, а не производительности каких-то там библиотек. По качеству среды / документации Python пока проигрывает специализированным пакетам.
Re[27]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.15 11:18
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Тебе снова показать какую часть ты не сумел прочитать ?


EP>А ты перестал пить коньяк по утрам? Реально, завязывай со своей дешёвой демагогией.


low latency и производительность кода это одно и тоже ? А производительность всей системы ?

I>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов".

EP>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".

Наоборот.

I>>low latency никогда не требовал экстремальной производительности от компилятора,

EP>Это прежде всего low latency, а для low нужна в том числе скорость.

В первую очередь кое что другое, ибо в low-latency работает в т.ч. и джава.

EP>>>Даже если использовать refcounting не только для решения задач в которых

I>>Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ?
EP>На C та часть которая "не только" (то есть опциональная) — она не реализуема.

Реализуема, только иначе.

EP>>>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).

I>>Ужос, кто бы мог подумать ?
EP>Видимо не ты, раз говоришь что от ref-counting "растут жесточайшие проблемы".

Именно. рефкаунтинг может дать не меньшие тормоза, нежели GC.
Re[32]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.15 11:23
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

MA>>Питон активно пользуют т.н. data scientists, но по причинам, которые к производительности отношение имеют отдаленное.


EP>Python популярен у инженеров различных областей. Причём на нём пишут и как отдельные программы, так и используют в виде скриптовых движков (например ParaView).


В научной среде применение другое, время написания программы часто сравнимо с временем работы. Никто не жаждет отлаживать реф-каунтинг в многопоточном приложении, если софтина работает день-два, после чего надо писать новую софтину.
Re[28]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 11:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов".

EP>>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".
I>Наоборот.

Аргументированно

I>>>low latency никогда не требовал экстремальной производительности от компилятора,

EP>>Это прежде всего low latency, а для low нужна в том числе скорость.
I>В первую очередь кое что другое,

Если в первую очередь другое, то для этого есть другое название.

I>ибо в low-latency работает в т.ч. и джава.


На Java можно в том числе создавать быстрый код. Затратно, но можно.

EP>>>>Даже если использовать refcounting не только для решения задач в которых

I>>>Давай попроще — вот эти "не только", их тоже надо в Си переносить, потому что ты из заюзал в С++ ?
EP>>На C та часть которая "не только" (то есть опциональная) — она не реализуема.
I>Реализуема, только иначе.

Расшифруй.

EP>>>>Основные проблемы растут от использования указателей вообще (будь то naked, smart, GC).

I>>>Ужос, кто бы мог подумать ?
EP>>Видимо не ты, раз говоришь что от ref-counting "растут жесточайшие проблемы".
I>Именно. рефкаунтинг может дать не меньшие тормоза, нежели GC.

А ты представляешь как реализуется ref-counting в C++11?
Отредактировано 08.10.2015 11:45 Evgeny.Panasyuk . Предыдущая версия .
Re[18]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 12:36
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен

EP>Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.
Не обязательно на стеке, ещё есть thread local heap.
Код может быть очень развесистохитрым, а unique_ptr выведется сам, как результат EA.

dot>>да и Young Generation собирается очень быстро.

EP>Во сколько раз "быстро" быстрее "мгновенно"?
O(1)

EP>>>·>Если нужна передача данных между тредами — нужен shared pointer,

EP>>>Он нужен только в случаях когда потоки владеют какими-то общими данными и точный момент удаления заранее не определён.
EP>>>Если просто нужно передать данные и владение в другой поток, то достаточно и unique, и то не факт — может быть хватит обычного перемещения.
dot>>Не владеют, а шарят...
EP>А шарят они что по-твоему? Цитата из стандарта: "shared_ptr implements semantics of shared ownership"
dot>>Будешь передавать weak_ptr, а значит опять локи.
EP>Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.
shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.

dot>>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.

EP>А например OOM — тоже вполне серьёзно
ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.

dot>>А ещё аллокация из кучи — глобальный лок. В общем, тормоза повсюду.

EP>Специальные аллокаторы и т.п. — вполне распространённая практика.
EP>Значит в случае Java ты готов использовать и специальную VM, и специальный GC, отказываться от классов, а в случае C++ специальные аллокатор ни в коем случае
VM и GC не влияет на код, просто пускаешь тот же апп под другой VM.
Отказываться от классов? Это как? В смысле раскладывать данные по массивам? Массивы не отказ от классов, а от полей классов. Эта техника не специфична для Java, в С++ тоже так делают:
http://programmers.stackexchange.com/questions/246474/data-oriented-design-impractical-with-more-than-1-2-structure-members

dot>>Короче, может и можно писать low latency на C++, но сложнее на порядок.

EP>Это фантазии, ничем не обоснованные.
EP>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
EP>Вот конкретный пример (первые минут двадцать)
Посмотрел начало ролика. В общем там неплохо сказано — быстрое ядро относительно маленькое, зато обвязка — на порядок больше. Поэтому в целом и получается этот порядок.
И, кстати, я заметил, что java-specific там практически ничего не было. Основной упор именно на то, что надо понимать как работает железо, а какой язык — не важно, техники отличаются деталями реализации, принцип же тот же.

EP>>>·>который использует lock (mutex?) -

EP>>>Обычно в реализациях атомарные inc/dec.
dot>>Это где? Вот тут вроде mutex.
EP>И там же atomics. Mutex это лишь fallback для платформ в которых нет подходящих атомарных операций
А. Да. Не так посмотрел, там оказывается специализации под разные стратегии.
В общем да. Да, на плюсах можно делать то же, что и в Яве. Ведь Ява на плюсах написана. Но из-за арифметики указателей и прочего нормальный gc сделать всё равно не выйдет, только всякие ref counting и прочее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 12:40
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Ну ОК, раз ты так считаешь, то тогда приведи пример взаимодействия потоков в котором на твой взгляд невозможно обойтись без shared_ptr.

_>·>Если тебе нужно чтобы не было обращений по невалидным указателям, то ты не можешь делать предположение, что объект по голому указателю ещё жив — надо использовать smart pointers.
_>С чего это ты взял, что не могу? ) Да, и ты снова привёл не конкретный пример, а абстрактные рассуждения. Давай конкретную задачку и посмотрим могу или нет... )))
Сможешь, конечно. Можно всё и на brainfuck написать, вопрос в том, что проще и на чём будет проще убедиться в работоспособности решения.

_>>>·>Да не надо локи. Есть много других механизмов.

_>>>Например? )
_>·>CAS, volatile, happens-before.
_>Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.
Полная загрузка процессора в low latency как раз частенько используется — для того, чтобы операционка не вздумала вытеснить критичный тред. Ещё этот тред к одному ядру привязывается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 12:50
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно.

EP>Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.
Задоблаешься. Скажем, частенько при интеграции с другими библиотеками, особенно C, может вылезти:
const Obj obj = ...;
doSomethingWithImmutableObj(obj);
...
void *obj = &obj;
...
Obj *obj2 = (Obj *)obj2;
...
obj2.modify();

И нифига ненаверифицируешь.
И вообще, никакая это не верификация, а статический анализ.

dot>>В-третьих, вот так в C++ писать уже можно?

EP>В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.
О, наконец-то стало можно. Если не ошибаюсь, в С++ это появилось c 2011, в Яве же с 2004.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[20]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 12:53
Оценка: -1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы).


EP>Да, но мы-то обсуждаем именно такой случай, именно эту самую область кода. И эта ручная error-prone нарезка на структуры, отказ от GC и т.п. — по сути выливается в уровень ниже чем C, и в результате приводит к вполне ожидаемым ошибкам: http://rsdn.ru/forum/philosophy/6201205.1
Автор: Evgeny.Panasyuk
Дата: 02.10.15

Заметь, эта ошибка в C++, т.е. к яве отношения не имеет. А java-specific никакой проблемы не представляет (ну, кроме как вместо бесплатной Oracle VM нужно покупать Zing JVM).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 13:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Ошибся "здесь" — задержка вылезет черз секунду "там"

I>·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.
I>Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве.
Расскажи это как миниимум упомянутым dxFeed и LMAX.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.15 13:03
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов".

EP>>>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".
I>>Наоборот.

EP>Аргументированно


Ну и логика

Вот это аргумент: 'Это не "как на Си"'
А вот это — 'Это "как на Си"' — уже нет
Браво !

I>>ибо в low-latency работает в т.ч. и джава.


EP>На Java можно в том числе создавать быстрый код. Затратно, но можно.


Настолько быстрый, как С++ это невозможно. И тем не менее джава есть в low latence. А следовательно твой

EP>>>На C та часть которая "не только" (то есть опциональная) — она не реализуема.

I>>Реализуема, только иначе.

EP>Расшифруй.


Это значит, что те же задачи решаются и в Си, за доказательством смотри полноту по тьюрингу и реализации ОС РВ.

EP>А ты представляешь как реализуется ref-counting в C++11?


А при чем здесь 11 ? Есть куча кода написаного в тысячах контор:

"Зануление счетчика, вызов деструктора, который вызывает зануление другого счетчика, который вызывает деструктор,и тд и тд"
Re[19]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 13:14
Оценка:
Здравствуйте, ·, Вы писали:

EP>>Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен

EP>>Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.
dot>Не обязательно на стеке, ещё есть thread local heap.
dot>Код может быть очень развесистохитрым, а unique_ptr выведется сам, как результат EA.

И каким образом у тебя получился тут unique_ptr?

dot>>>Будешь передавать weak_ptr, а значит опять локи.

EP>>Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.
dot>shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.

Как weak_ptr относится к дискуссии?

dot>>>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.

EP>>А например OOM — тоже вполне серьёзно
dot>ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.

OOM он конечно везде OOM, но причины наступления бывают разные

dot>>>А ещё аллокация из кучи — глобальный лок. В общем, тормоза повсюду.

EP>>Специальные аллокаторы и т.п. — вполне распространённая практика.
EP>>Значит в случае Java ты готов использовать и специальную VM, и специальный GC, отказываться от классов, а в случае C++ специальные аллокатор ни в коем случае
dot>VM и GC не влияет на код, просто пускаешь тот же апп под другой VM.
dot>Отказываться от классов? Это как? В смысле раскладывать данные по массивам? Массивы не отказ от классов, а от полей классов. Эта техника не специфична для Java, в С++ тоже так делают:
dot>http://programmers.stackexchange.com/questions/246474/data-oriented-design-impractical-with-more-than-1-2-structure-members

Нет, именно от классов. То что ты привёл это иногда называется Structure of Arrays, в C++ кстати я такую трансформацию реализовывал в библиотечном виде, то есть раскидывание происходит автоматически.

Я же говорю про обычные структуры, в Java нет даже их. То есть положить в один массив плотно друг к другу данные вида:
struct Foo
{
    double a;
    int b;
    char c, d;
};
напрямую не получится, и это существенный источник тормозов. В зависимости от ситуации медленнее может быть на несколько порядков. На ровном месте вырастают целые деревья индерекций.
Обходится например через огород low-level эмуляции на чём-то типа ByteBuffer.

dot>>>Короче, может и можно писать low latency на C++, но сложнее на порядок.

EP>>Это фантазии, ничем не обоснованные.
EP>>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
EP>>Вот конкретный пример (первые минут двадцать)
dot>Посмотрел начало ролика. В общем там неплохо сказано — быстрое ядро относительно маленькое, зато обвязка — на порядок больше. Поэтому в целом и получается этот порядок.

Субъектива он там нагнал предостаточно (ЕМНИП было даже что-то типа "для нормального C++ кода, нужны те кто ковыряется внутри кода GCC").
Давай обсуждать объективные вещи.

dot>И, кстати, я заметил, что java-specific там практически ничего не было. Основной упор именно на то, что надо понимать как работает железо, а какой язык — не важно, техники отличаются деталями реализации, принцип же тот же.


Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.

dot>А. Да. Не так посмотрел, там оказывается специализации под разные стратегии.

dot>В общем да. Да, на плюсах можно делать то же, что и в Яве. Ведь Ява на плюсах написана. Но из-за арифметики указателей и прочего нормальный gc сделать всё равно не выйдет, только всякие ref counting и прочее.

Я делал библиотечный копирующий GC for fun — простой вариант с одним поколением уместился в несколько сотен строк. Естественно есть ограничения, но тем не менее.
AFAIR, в Mozzila используют библиотечный GC в местах interop'а с JS.
Re[25]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.15 13:16
Оценка:
Здравствуйте, ·, Вы писали:

I>>·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.

I>>Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве.
·>Расскажи это как миниимум упомянутым dxFeed и LMAX.

Есть куча проектов, которые загнулись из за того, что так и не смогли сбороть этот GC. Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.
Re[25]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 13:27
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Во-вторых, попробуй такой трюк проверни со включенным security manager, запретить const_cast же — невозможно.

EP>>Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.
dot>Задоблаешься. Скажем, частенько при интеграции с другими библиотеками, особенно C, может вылезти:
dot>
dot>Obj *obj2 = (Obj *)obj2;
dot>

dot>И нифига ненаверифицируешь.

Старый cast легко отлавливается компилятором, например опция GCC -Werror-old-style-cast

dot>И вообще, никакая это не верификация, а статический анализ.


Это верификация соответствия требованиям.

dot>>>В-третьих, вот так в C++ писать уже можно?

EP>>В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.
dot>О, наконец-то стало можно. Если не ошибаюсь, в С++ это появилось c 2011, в Яве же с 2004.

В стандарте C++11 появились std::atomic, memory model, да и вообще понятие потока.
Библиотечные же реализации работают и в C++1998.
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 13:28
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>ООМ везде можно получить.

EP>Я описываю конкретный case, который есть при использовании GC, и которого нет при использовании scope-based lifetime.
Понятно, что С++ позволяет сделать больше, чем Java. Но GC это очень хороший алгоритм и даёт много преимуществ в широком классе задач, в т.ч. low latency.

EP>Не надо оправдываться абстрактными "OOM везде можно получить" — я так тоже умею: "везде можно получить расстрел памяти, даже при использовании Java"

Расстрел памяти в Java? Как???

dot>>>>Можно, конечно, такое же соорудить и в C++, но это будет закат солнца вручную.

EP>>>Почему вручную-то? Если есть такой развесистый граф владения — то и очищай его по частям, автоматически.
dot>>По каким частям?
EP>Например очищать фиксированное количество объектов за раз, оставшиеся ставить в очередь.
Фиксированное чем? Как узнать сколько за раз?

dot>>Как эти части определить?

EP>Как того требует задача. Если нужно ограничить время — то соответственно засекаешь время/тики, или что там удобнее.
Время чего? Вот у тебя
smartPtr.release(); // упс, заняло 300ms, хотя обычно занимает 3us. Нам не повезло оказаться последним юзером объекта и граф объектов оказался больше обычного.

Куда именно ты поставишь тики?

dot>>В каком порядке очищать?

EP>Например в порядке очереди.
Как выстоить в очередь граф объектов?

dot>>Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc.

EP>Нет, это неверно. Задача GC в первую очередь отличить reachable от unreachable объектов. А уж делать reclaim порциями, или за один присест — это уже отдельное свойство, причём ортогональное наличию/отсутствию GC.
GC в Java это целый комплекс алгоритмов с тучей настроек. Задача — освобождать память от unreachable объектов, а не просто "отличить".

EP>И, кстати, для C++ возможен и runtime'овый GC (прям в стандарте есть специальное API), и библиотечный (я даже как-то делал for fun).

Но как? Precise GC принципиально невозможен. С safepoints тоже проблемы. Дизайн Java позволяет использовать гораздо более мощные алгоритмы GC, чем те, которые доступны в C++ коде.

EP>>>Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.

dot>>Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).
EP>При этом сделав O(N) обход живых объектов, которого нет в случае с C++
В YG это N малО, а OG обходится не часто, и обычно минимально влияя на основные потоки. (Мы рассматриваем low latency, когда память не забита под завязку, конечно).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 13:38
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Т.е. неиндусы — никогда не ошибаются? Даже дело не в том, что ошибаются или нет — проверить никак нельзя.

TB>То есть С++ требовательнее к дисциплине программиста. Это его недостаток. Что не так?
Дело не в дисциплине, а в гарантии правильности. Если у тебя есть некий критичный кусочек кода — его можно проанализировать очень внимательно (или даже доказать) и быть уверенным, что именно он так и отработает. В случае С++ — это невозможно принципиально — расстрел памяти ведёт к непредсказуемым результатам любой части кода.

TB>·>запретить const_cast же — невозможно.

TB>Это уныло. Ругать язык за то, что в нём можно сделать диверсию — это уныло, потому что диверсию можно сделать в любом языке, что я и показал. И говорить, что якобы в одном языке обнаружить такую откровенную (как конст_каст) диверсию проще, чем в другом — это тоже уныло.
Знаю, что уныло, но факт остаётся фактом. И не диверсия, а просто ошибка.

TB>·>В-третьих, вот так в C++ писать уже можно?

TB>А проблема-то в чём? Расскажи, почему в жабе так можно делать (с локами? без них?), а в С++ нельзя? Что за хрень эти иммутабельные классы? Аааа, я понял, в жабе нету типа "указатель на константу", поэтому "иммутальные классы" преподносятся, как откровение.
Укзатель на константу? Это оно?
Data openFile(const Path &path)
{
  if(!isAccessAllowed(path)) throw InvalidAccess();
  return readData(path);
}

Проблему сам найдёшь? Откровение открылось?

Иммутабельный класс это значит, что его можно использовать в любое время из любого треда и быть уверенным, что результат будет тем же.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 13:44
Оценка: +1
Здравствуйте, ·, Вы писали:

dot>>>Ролик не смотрел, дома посмотрю... Но могу заметить, что эти все нарезки обычно делаются в довольно ограниченной области кода. И все эти порчи данных довольно изолированы (или как минимум изолируемы).

EP>>Да, но мы-то обсуждаем именно такой случай, именно эту самую область кода. И эта ручная error-prone нарезка на структуры, отказ от GC и т.п. — по сути выливается в уровень ниже чем C, и в результате приводит к вполне ожидаемым ошибкам: http://rsdn.ru/forum/philosophy/6201205.1
Автор: Evgeny.Panasyuk
Дата: 02.10.15

dot>Заметь, эта ошибка в C++,

Ошибка в Java варианте.

dot>т.е. к яве отношения не имеет. А java-specific никакой проблемы не представляет


Это именно Java-specifc ошибка.
Так как нет структур (а например с классами вместо структур на C# этот пример тормозит ~80x) — ему пришлось
Автор: mik1
Дата: 02.06.15
вместо массива Complex, руками нарезать массив double на Complex, и руками сплавлять обход и перемножение элементов массива в одну операцию. И именно в этом месте у него вылезла ошибка.
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 13:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение,

EP>Пусть просто поставит в очередь, делов-то
Поставит что? Сразу весь развесистый граф? А если надо только часть освободить? Ставить каждый самый мелкий объект? А очереди не поплохеет? В общем опять, закат gc вручую.

EP>>>На Java кстати какое решение можешь предложить?

dot>>На java память ресурс другого типа. "Освобождать память" там нельзя.
EP>А я поэтому и сказал конкретно "ресурс", а не просто "объект". Да и память не ресурс только если она не ограниченна — упрёшься в предел, получишь удар по latency, на который постоянно ссылаешься.
В low latency единственный ресурс обычно память. Из LL кода никто в своём уме коннекты к БД не открывает, с SOAP сервисам не обращается.

dot>>А для ресурсов в общем случае — наследники java.lang.ref.Reference.

EP>Каким образом они обеспечат prompt finalization?
А надо? А зачем вообще ресурсы обязательно освобождать из финалайзеров? Я не понял какую задачу ты описываешь.

EP>>>На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.

dot>>Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.
EP>При GC чуть проще реализация lockfree структур данных, за счёт ABA, но при этом сами GC в большинстве своём не lockfree (lockfree GC видел только в статьях) — то есть тут уже большой терминологический вопрос, остаётся ли структура данных lockfree при не non-lockfree GC
Если локи расставляются сами компилятором и лочится на предсказуемое время — почему бы и нет.

EP>Да и такие структуры должны реализовывать профессионалы своего дела, так как это трудная/опасная тема.

В том то и дело. Это уже и реализовали в виде JVM — бери, да используй, а не изобретай велосипед.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 08.10.15 13:48
Оценка:
Здравствуйте, ·, Вы писали:

·>Дело не в дисциплине, а в гарантии правильности. Если у тебя есть некий критичный кусочек кода — его можно проанализировать очень внимательно (или даже доказать) и быть уверенным, что именно он так и отработает. В случае С++ — это невозможно принципиально — расстрел памяти ведёт к непредсказуемым результатам любой части кода.


Да-да, я это слышал, это из первой лекции для студентов "недостатки С++". /_-

·>Знаю, что уныло, но факт остаётся фактом. И не диверсия, а просто ошибка.


Случайно сделать 10 ошибок в слове "int" и получить "const_cast"? Или как?

·>Проблему сам найдёшь? Откровение открылось?


Нет, проблемы не вижу, кроме случая, когда в команде бардак и разработчики диверсанты, "случайно" пишущие const_cast, срущие в данные, которые другой поток считает константными, делящие на ноль и невзначай вставляющие в код команду форматирования винчестера.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[2]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 08.10.15 13:59
Оценка:
Здравствуйте, A13x, Вы писали:

A>Для желающих проверить на практике — предлагаю желающим реализовать простейший интерпретатор нетипизированного лямбда исчисления на С++ (ну то есть REPL который бы понимал что-то вроде такого) и сравнить его быстродейтвие с тем, что можно реализовать на яве (мой вариант меньше 500 строк и по быстродействию уделывает известные мне интерпретаторы scheme). Насколько я себе представляю возможные реализации — на стресс тестах будет большое количество виртуальных вызовов и большое количество выделений памяти под мелкие объекты.


Дык можно запилить свой хитрый аллокатор для мелких объектов просто, а подвох-то в чём?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[12]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 14:00
Оценка:
Здравствуйте, PM, Вы писали:

PM>>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>

PM>·>Собственно сейчас в моде Zing JVM, там задержки не более 10ms, в основном ~100us.
PM>·>Писать такое на C++... неее... проще застрелиться.
PM>·>А перезапуск нужен не для gc, а чтобы на диск состояние скинуть, ибо использовать классические СУБД — теоретически невозможно.
PM>Задержка 10ms может быть неприемлемой в некоторых задачах, в том числе и в биржевых системах.
Я знаю, я говорю, что 10ms это уже проблема — на которую тут же заводится bug report.

PM>Состояние на диск постоянно скидывается в LMAX в отдельном потоке в файл журнала. И разработчики LMAX повоевали и здесь чтобы добиться предсказуемого результата. Ну и для сетевого I/O наверняка использовали какой-нибудь NIO.

В журнал скидываются транзакции (дельты), а раз в день делается снапшот состояния.
Война была, да и до сих пор ведётся не с java, а с архитектурой и железом. 90% тех решений подходит и для С++.

PM>Я почитал ваши сообщения в ветке. Ещё одна иллюстрация, что люди не из мира C++ продолжают верить в мифы 15-20 летней давности. Авторы LMAX скорее всего тоже подумали: "Писать такое на C++... неее... проще застрелиться" и взяли хорошо известный им и широко распространённый инструмент. Хорошо, что при этом они не застрелились

На плюсах есть куски или нативные либы, но как-то постепенно перетекает всё в java. Ибо работает так же, а добавляется куча преимуществ (см ролик http://rsdn.ru/forum/philosophy/6205646.1
Автор: Evgeny.Panasyuk
Дата: 07.10.15
)
Как в одно время был процесс переползания с ассемблеров на фортран, на С, на С++, теперь вот java. Конечно, на arduino яву не запустишь, но нишу LL она уверенно отвоёвывает.

PM>Часть кода, кстати, открыта: https://github.com/LMAX-Exchange/disruptor и выглядит на мой взгляд over engineering. Хотя, может для Java мира это нормально

Видимо поэтому этот over engineering стырили https://code.google.com/p/disruptor-cpp/ https://github.com/disruptor-net/Disruptor-net Как видишь — дело не в языке, а в архитектуре.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 14:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>>>"Как на Си" это в первую очередь вещи, где нужен полный контроль над временем выполнения, не "хрен знает сколько" а скажем "не более 8000 тактов".

EP>>>>Это не "как на Си". Контроль над временем вообще ортогонален "как на Си".
I>>>Наоборот.
EP>>Аргументированно
I>Ну и логика
I>Вот это аргумент: 'Это не "как на Си"'
I>А вот это — 'Это "как на Си"' — уже нет
I>Браво !

Врёшь же. Я конкретно сказал что контроль над временем ортогонален "как на Си".

I>>>ибо в low-latency работает в т.ч. и джава.

EP>>На Java можно в том числе создавать быстрый код. Затратно, но можно.
I>Настолько быстрый, как С++ это невозможно. И тем не менее джава есть в low latence. А следовательно твой

Настолько же быстрый — да, вряд ли. А вот разница в десятки процентов (не считая векторизацию и т.п.) вполне достижима. Огромной ценой, но тем не менее.

EP>>>>На C та часть которая "не только" (то есть опциональная) — она не реализуема.

I>>>Реализуема, только иначе.
EP>>Расшифруй.
I>Это значит, что те же задачи решаются и в Си, за доказательством смотри полноту по тьюрингу

Причём тут полнота по Тьюрингу? В данном месте обсуждаем использование ref-counting там где в этом нет необходимости, то есть для подстраховки.

EP>>А ты представляешь как реализуется ref-counting в C++11?

I>А при чем здесь 11 ?

При том что на нём передёргиваний счётчиков на порядки меньше. И соответственно меньше overhead'а привнесённого непосредственно подсчётом ссылок.

I>Есть куча кода написаного в тысячах контор:

I>"Зануление счетчика, вызов деструктора, который вызывает зануление другого счетчика, который вызывает деструктор,и тд и тд"

В этом плане ref-counting практически никаких тормозов не добавляет (пара лишних операций перед очисткой) — подобная каскадная очистка есть и без него.
Re[31]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.15 14:27
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Вот это аргумент: 'Это не "как на Си"'

I>>А вот это — 'Это "как на Си"' — уже нет
I>>Браво !

EP>Врёшь же. Я конкретно сказал что контроль над временем ортогонален "как на Си".


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

I>>Настолько быстрый, как С++ это невозможно. И тем не менее джава есть в low latence. А следовательно твой

EP>Настолько же быстрый — да, вряд ли. А вот разница в десятки процентов (не считая векторизацию и т.п.) вполне достижима. Огромной ценой, но тем не менее.

То есть, в кратце, незачем выжимать сок из Сишного кода, если код на десятки процентов медленнее справляется с работой. Правильно ?

EP>>>Расшифруй.

I>>Это значит, что те же задачи решаются и в Си, за доказательством смотри полноту по тьюрингу
EP>Причём тут полнота по Тьюрингу? В данном месте обсуждаем использование ref-counting там где в этом нет необходимости, то есть для подстраховки.

Из этой самой полноты следует "в этом нет необходимости, то есть для подстраховки"

EP>При том что на нём передёргиваний счётчиков на порядки меньше. И соответственно меньше overhead'а привнесённого непосредственно подсчётом ссылок.


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

I>>Есть куча кода написаного в тысячах контор:

I>>"Зануление счетчика, вызов деструктора, который вызывает зануление другого счетчика, который вызывает деструктор,и тд и тд"

EP>В этом плане ref-counting практически никаких тормозов не добавляет (пара лишних операций перед очисткой) — подобная каскадная очистка есть и без него.


Твоя "подстраховка", требует ресурсов. Каскадная очистка — часть этой самой подстраховки. Вместо явной логики "вычислить и освободить явно" выбираем неявную "пусть деструкторы срабатывают каскадом по цепочке, авось пронесёт"
Re[20]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 14:45
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен

EP>>>Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.
dot>>Не обязательно на стеке, ещё есть thread local heap.
dot>>Код может быть очень развесистохитрым, а unique_ptr выведется сам, как результат EA.
EP>И каким образом у тебя получился тут unique_ptr?
Если VM оптимизатор видит, что объект используется только в одном месте, он переносит ссылку на стек, т.е. по сути выводит unique_ptr.

EP>>>Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.

dot>>shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.
EP>Как weak_ptr относится к дискуссии?
Как я понял, ты предлагаешь выделить один тред как владелец объекта, т.е. тот, кто держит shared_ptr, а другие треды — просто пользователи объекта, им отдаётся weak_ptr (не голые же указатели передавать?!).

dot>>>>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.

EP>>>А например OOM — тоже вполне серьёзно
dot>>ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.
EP>OOM он конечно везде OOM, но причины наступления бывают разные
OOM не кидается в случае если gc есть что освободить.

dot>>Отказываться от классов? Это как? В смысле раскладывать данные по массивам? Массивы не отказ от классов, а от полей классов. Эта техника не специфична для Java, в С++ тоже так делают:

dot>>http://programmers.stackexchange.com/questions/246474/data-oriented-design-impractical-with-more-than-1-2-structure-members
EP>Нет, именно от классов. То что ты привёл это иногда называется Structure of Arrays, в C++ кстати я такую трансформацию реализовывал в библиотечном виде, то есть раскидывание происходит автоматически.
EP>Я же говорю про обычные структуры, в Java нет даже их. То есть положить в один массив плотно друг к другу данные вида:
EP>
EP>struct Foo
EP>{
EP>    double a;
EP>    int b;
EP>    char c, d;
EP>};
EP>
напрямую не получится, и это существенный источник тормозов. В зависимости от ситуации медленнее может быть на несколько порядков. На ровном месте вырастают целые деревья индерекций.

EP>Обходится например через огород low-level эмуляции на чём-то типа ByteBuffer.
Делаешь класс (зачем от классов то отказываться?!)
class FooArray
{
   ByteBuffer data;
   getA();setA();
   getB();setB();
   getC();setC();
   getD();setD();
}

Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет. Почему-то я уверен, что "трансформацию реализовывал в библиотечном виде" будет выглядеть гораздо хуже и иметь довольно нетривиальный код.

EP>>>Это фантазии, ничем не обоснованные.

EP>>>При использовании Java в таких случаях отказываются и от GC и от классов, и нарезают вручную массивы байт на структуры. Получить порчу данных в таком случае на порядки проще чем на высокоуровневом C++.
EP>>>Вот конкретный пример (первые минут двадцать)
dot>>Посмотрел начало ролика. В общем там неплохо сказано — быстрое ядро относительно маленькое, зато обвязка — на порядок больше. Поэтому в целом и получается этот порядок.
EP>Субъектива он там нагнал предостаточно (ЕМНИП было даже что-то типа "для нормального C++ кода, нужны те кто ковыряется внутри кода GCC").
EP>Давай обсуждать объективные вещи.
Так вполне объективно: LL ядро — один сервис, обвязка вокруг него — ещё пол сотни.

dot>>И, кстати, я заметил, что java-specific там практически ничего не было. Основной упор именно на то, что надо понимать как работает железо, а какой язык — не важно, техники отличаются деталями реализации, принцип же тот же.

EP>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.
Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.

dot>>А. Да. Не так посмотрел, там оказывается специализации под разные стратегии.

dot>>В общем да. Да, на плюсах можно делать то же, что и в Яве. Ведь Ява на плюсах написана. Но из-за арифметики указателей и прочего нормальный gc сделать всё равно не выйдет, только всякие ref counting и прочее.
EP>Я делал библиотечный копирующий GC for fun — простой вариант с одним поколением уместился в несколько сотен строк. Естественно есть ограничения, но тем не менее.
EP>AFAIR, в Mozzila используют библиотечный GC в местах interop'а с JS.
Простые варианты и делаются просто. А когда ты начинаешь делать не for fun, а серьёзно — становится всё плохо.
Mozilla не LL, а JS вообще однопоточный. В общем, всё на порядки проще.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 14:50
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>·>gc прощает гораздо больше ошибок. И самое страшное что может случиться — тормоза. Без него — всё что угодно, и тормоза, и порча памяти, и утечки.

I>>>Самое страшное — твою софтину для биржи на джаве никто не купит. Отсюда ясно, что часть софта в принципе никто даже не станет пытаться писать на джаве.
I>·>Расскажи это как миниимум упомянутым dxFeed и LMAX.
I>Есть куча проектов, которые загнулись из за того, что так и не смогли сбороть этот GC.
А конкретнее? Ни одного С++ проекта не загнулась из-за сложности кода?

I> Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.

Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 14:57
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.

dot>>Задоблаешься. Скажем, частенько при интеграции с другими библиотеками, особенно C, может вылезти:
dot>>
dot>>Obj *obj2 = (Obj *)obj2;
dot>>

dot>>И нифига ненаверифицируешь.
EP>Старый cast легко отлавливается компилятором, например опция GCC -Werror-old-style-cast
Ну пусть будет reinterpret_cast<Obj *>(obj) какая разница-то?

dot>>И вообще, никакая это не верификация, а статический анализ.

EP>Это верификация соответствия требованиям.
Под верификацией обычно понимается проверка формальными методами. А так — анализ, тестирование.

EP>>>В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.

dot>>О, наконец-то стало можно. Если не ошибаюсь, в С++ это появилось c 2011, в Яве же с 2004.
EP>В стандарте C++11 появились std::atomic, memory model, да и вообще понятие потока.
EP>Библиотечные же реализации работают и в C++1998.
Ну так нечестно. А то я скажу, что "gc можно отключить в java" если использовать библиотеки с off-heap.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 15:01
Оценка:
Здравствуйте, ·, Вы писали:

EP>>Не надо оправдываться абстрактными "OOM везде можно получить" — я так тоже умею: "везде можно получить расстрел памяти, даже при использовании Java"

dot>Расстрел памяти в Java? Как???

Элементарно. Её может расстрелять сторонняя native библиотека, причём даже не из-за бага в самой библиотеке, а потому что Java код нарушил предусловия. Или например может расстрелять свой же Runtime — гарантии нет
Это аргумент примерно того же порядка что и "OOM везде можно получить" в ответ на описание конкретного use-case'а.

dot>>>Как эти части определить?

EP>>Как того требует задача. Если нужно ограничить время — то соответственно засекаешь время/тики, или что там удобнее.
dot>Время чего? Вот у тебя
dot>
dot>smartPtr.release(); // упс, заняло 300ms, хотя обычно занимает 3us. Нам не повезло оказаться последним юзером объекта и граф объектов оказался больше обычного.
dot>


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

dot>>>В каком порядке очищать?

EP>>Например в порядке очереди.
dot>Как выстоить в очередь граф объектов?

Например в деструкторе smart-pointer'а не сразу удалять, а ставить в очередь.

dot>>>Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc.

EP>>Нет, это неверно. Задача GC в первую очередь отличить reachable от unreachable объектов. А уж делать reclaim порциями, или за один присест — это уже отдельное свойство, причём ортогональное наличию/отсутствию GC.
dot>GC в Java это целый комплекс алгоритмов с тучей настроек. Задача — освобождать память от unreachable объектов, а не просто "отличить".

А ещё он внутри делает сложение целых чисел. Из этого не следует что сложение целых чисел это "переизобретание современного GC".

EP>>И, кстати, для C++ возможен и runtime'овый GC (прям в стандарте есть специальное API), и библиотечный (я даже как-то делал for fun).

dot>Но как? Precise GC принципиально невозможен.

Возможен. Заводится отдельная GC Heap, все указатели на элементы внутри этой кучи заворачиваются в gc_ptr<T>.
Отличать root от не root можно разными способами. Например если сам объект-указатель типа gc_ptr находится не в этой куче — то это root.
AFAIR, нечто подобное используется в SpiderMonkey.

EP>>>>Да и возникают они в Java на порядки чаще чем в C++. Элементарный пример: массив объектов, агрегирующих другие объекты, агрегирующих другие ... — вполне типичная ситуация. На Java будет тот самый развесистый граф, а на C++ может быть просто по сути один вектор освобождающийся за O(1) — так как value semantics.

dot>>>Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).
EP>>При этом сделав O(N) обход живых объектов, которого нет в случае с C++
dot>В YG это N малО, а OG обходится не часто,

Чем больше N — тем чаще. В любом случае это не O(1).

dot>и обычно минимально влияя на основные потоки.


Memory throughput не бесконечная, более того — часто является bottleneck'ом. GC во время обхода интенсивно использует память, сужая этот bottleneck.
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 15:17
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Дело не в дисциплине, а в гарантии правильности. Если у тебя есть некий критичный кусочек кода — его можно проанализировать очень внимательно (или даже доказать) и быть уверенным, что именно он так и отработает. В случае С++ — это невозможно принципиально — расстрел памяти ведёт к непредсказуемым результатам любой части кода.

TB>Да-да, я это слышал, это из первой лекции для студентов "недостатки С++". /_-
И с тех пор ты никогда в жизни не расстрелял память или не видел, когда вполне дисциплинированый дев расстреливал?

TB>·>Знаю, что уныло, но факт остаётся фактом. И не диверсия, а просто ошибка.

TB>Случайно сделать 10 ошибок в слове "int" и получить "const_cast"? Или как?
const_cast не единственный способ потерять константность.

TB>·>Проблему сам найдёшь? Откровение открылось?

TB>Нет, проблемы не вижу, кроме случая, когда в команде бардак и разработчики диверсанты, "случайно" пишущие const_cast, срущие в данные, которые другой поток считает константными, делящие на ноль и невзначай вставляющие в код команду форматирования винчестера.
В ядре линуха такие баги находили (а там, видимо бардак и диверсанты).
Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 15:24
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение,

EP>>Пусть просто поставит в очередь, делов-то
dot>Поставит что? Сразу весь развесистый граф? А если надо только часть освободить? Ставить каждый самый мелкий объект? А очереди не поплохеет?

Не каждый объект, а те которые не успеваем освободить.

EP>>>>На Java кстати какое решение можешь предложить?

dot>>>На java память ресурс другого типа. "Освобождать память" там нельзя.
EP>>А я поэтому и сказал конкретно "ресурс", а не просто "объект". Да и память не ресурс только если она не ограниченна — упрёшься в предел, получишь удар по latency, на который постоянно ссылаешься.
dot>В low latency единственный ресурс обычно память.

Сильное утверждение. Да и это проблема ко всему относится, а не только к low latency.

dot>Из LL кода никто в своём уме коннекты к БД не открывает, с SOAP сервисам не обращается.


Файлы не открывают? Соединения не устанавливают?

dot>>>А для ресурсов в общем случае — наследники java.lang.ref.Reference.

EP>>Каким образом они обеспечат prompt finalization?
dot>А надо?

Надо, это задача.

dot>А зачем вообще ресурсы обязательно освобождать из финалайзеров?


Освобождай откуда угодно, но покажи как это реализуется в Java.

dot>Я не понял какую задачу ты описываешь.


Ту же самую, с потоками, при завершении последнего нужно освободить ресурс.

EP>>>>На них точно также получаются локи. Чтобы их не было, нужно использовать например lock-free / wait-free схемы.

dot>>>Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.
EP>>При GC чуть проще реализация lockfree структур данных, за счёт ABA, но при этом сами GC в большинстве своём не lockfree (lockfree GC видел только в статьях) — то есть тут уже большой терминологический вопрос, остаётся ли структура данных lockfree при не non-lockfree GC
dot>Если локи расставляются сами компилятором и лочится на предсказуемое время — почему бы и нет.

Потому что lock'и это не lockfree, принципиально. Смотри определение. Lockfree это прежде всего некоторые гарантии, а не например скорость — скорость вообще может быть меньше.
Да и кто сказал что время предсказуемо? Например GC заснул захватив lock, остальные ждут. Тут желательно хотя бы obstruction free

EP>>Да и такие структуры должны реализовывать профессионалы своего дела, так как это трудная/опасная тема.

dot>В том то и дело. Это уже и реализовали в виде JVM — бери, да используй, а не изобретай велосипед.

А я предлагал изобретать? Я сказал что ABA проще решается при использовании GC, решать её при этом самому не обязательно.
Re[32]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 15:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>Врёшь же. Я конкретно сказал что контроль над временем ортогонален "как на Си".

I>Это просто твоё мнение, ничем не аргументированое.

Это аргумент. Ты можешь быть согласен с ним или нет.

I>Я его услышал,


Ты если не согласен с аргументом, или не понял, то так и скажи, и попроси разъяснения.

I>выдал симметричное, только мне понадобилось всего слово для этого.


Ты вообще не выдал никакого аргумента.

EP>>>>Расшифруй.

I>>>Это значит, что те же задачи решаются и в Си, за доказательством смотри полноту по тьюрингу
EP>>Причём тут полнота по Тьюрингу? В данном месте обсуждаем использование ref-counting там где в этом нет необходимости, то есть для подстраховки.
I>Из этой самой полноты следует "в этом нет необходимости, то есть для подстраховки"

Это
Задача была сделать подстраховку, я сказал что такая подстраховка не реализуема на C, ты сказал что "реализуема, только иначе", а теперь говоришь суть реализации в том что в этом нет необходимости

EP>>При том что на нём передёргиваний счётчиков на порядки меньше. И соответственно меньше overhead'а привнесённого непосредственно подсчётом ссылок.

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

То есть ты не понимаешь в чём тут отличие у C++11

I>>>Есть куча кода написаного в тысячах контор:

I>>>"Зануление счетчика, вызов деструктора, который вызывает зануление другого счетчика, который вызывает деструктор,и тд и тд"
EP>>В этом плане ref-counting практически никаких тормозов не добавляет (пара лишних операций перед очисткой) — подобная каскадная очистка есть и без него.
I>Твоя "подстраховка", требует ресурсов. Каскадная очистка — часть этой самой подстраховки. Вместо явной логики "вычислить и освободить явно" выбираем неявную "пусть деструкторы срабатывают каскадом по цепочке, авось пронесёт"

Ещё раз, эта каскадная очистка была бы и без ref-counting. Understand?
Re[21]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 16:31
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Escape analysis вообще из другой оперы. Это например про аллокации объектов на стэке вместо кучи — в таких случаях никакой unique_ptr не нужен

EP>>>>Более того аллокация на стэке — это default для C++, и работает даже в случаях escape.
dot>>>Не обязательно на стеке, ещё есть thread local heap.
dot>>>Код может быть очень развесистохитрым, а unique_ptr выведется сам, как результат EA.
EP>>И каким образом у тебя получился тут unique_ptr?
dot>Если VM оптимизатор видит, что объект используется только в одном месте, он переносит ссылку на стек, т.е. по сути выводит unique_ptr.

И не в покер, а в преферанс. И не выиграл, а проиграл.
И не ссылку, а сам объект. И не unique_ptr, а просто стэковый объект.

EP>>>>Что? Причём тут теперь weak_ptr? Уже какая-то каша пошла.

dot>>>shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.
EP>>Как weak_ptr относится к дискуссии?
dot>Как я понял, ты предлагаешь выделить один тред как владелец объекта, т.е. тот, кто держит shared_ptr, а другие треды — просто пользователи объекта, им отдаётся weak_ptr (не голые же указатели передавать?!).

Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика
Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.

dot>>>>>Последствия обращения к неверным указателям — серьёзнее. Не простой краш, а хз что.

EP>>>>А например OOM — тоже вполне серьёзно
dot>>>ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.
EP>>OOM он конечно везде OOM, но причины наступления бывают разные
dot>OOM не кидается в случае если gc есть что освободить.

Упёрлись в потолок, GC начинает очень долго освобождать за O(N), отбирая ресурсы у других потоков, общая пропускная способность снижается (забиты каналы памяти, и аллокации происходят медленней), извне приходят всё новые задачи для которых в свою очередь нужна всё новая память, в конце концов либо OOM либо DoS.

dot>>>Отказываться от классов? Это как? В смысле раскладывать данные по массивам? Массивы не отказ от классов, а от полей классов. Эта техника не специфична для Java, в С++ тоже так делают:

dot>>>http://programmers.stackexchange.com/questions/246474/data-oriented-design-impractical-with-more-than-1-2-structure-members
EP>>Нет, именно от классов. То что ты привёл это иногда называется Structure of Arrays, в C++ кстати я такую трансформацию реализовывал в библиотечном виде, то есть раскидывание происходит автоматически.
EP>>Я же говорю про обычные структуры, в Java нет даже их. То есть положить в один массив плотно друг к другу данные вида:
EP>>
EP>>struct Foo
EP>>{
EP>>    double a;
EP>>    int b;
EP>>    char c, d;
EP>>};
EP>>
напрямую не получится, и это существенный источник тормозов. В зависимости от ситуации медленнее может быть на несколько порядков. На ровном месте вырастают целые деревья индерекций.

EP>>Обходится например через огород low-level эмуляции на чём-то типа ByteBuffer.
dot>Делаешь класс (зачем от классов то отказываться?!)

Вот в этом "делаешь" и есть проблема.

dot>
dot>class FooArray
dot>{
dot>   ByteBuffer data;
dot>   getA();setA();
dot>   getB();setB();
dot>   getC();setC();
dot>   getD();setD();
dot>}
dot>


Такой Array и другие контейнеры нужно делать для каждого типа данных. У тебя будут FooArray, BarArray, FooPriorityQueue, BarPriorityQueue и т.д.
Либо как вариант добавлять лишней динамичности, но от неё будут свои тормоза, причём как размеры заранее не известны.

dot>Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет.


Это одна из главных причин тормозов в языках с превалирующей pointer semantics. Положил класс с несколькими полями-объектами в массив — уже на ровном месте выросло целое дерево индерекций и аллокаций.

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


Нет, не хуже, также как и обычный вариант. В реализации — да, код не самый простой, но она пишется один раз.
Да и это же Array of Structures, нужно не так часто. Речь же про то, что в Java же нет самых обычных структур — для быстрого кода это супер-критично, именно поэтому и нарезают вручную.

dot>>>И, кстати, я заметил, что java-specific там практически ничего не было. Основной упор именно на то, что надо понимать как работает железо, а какой язык — не важно, техники отличаются деталями реализации, принцип же тот же.

EP>>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.
dot>Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.

Хуже, намного. Разве пример со структурами тебя не убедил? — это реально уровень ниже чем C, на ровном месте. Так это только один аспект.
Быстрый код на C++ можно писать на высоком уровне абстракции — не нужно отказываться ни от замыканий, ни от классов, ни от ФВП и полиморфизма — и при этом он будет давать точно такое же (либо практически такое же) быстродействие как и такой же код написанный на низком уровне вручную — в этом одна из главных фишек C++.
Re[2]: Java vs C# vs C++
От: mrTwister Россия  
Дата: 08.10.15 16:49
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?


Меня больше позабавило, что сортировка на unsafe указателях — это типичный код на C#
лэт ми спик фром май харт
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 16:51
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Возможно. Даже если опасаешься false positives/negatives grep'а — то легко написать простейший верификатор на базе Clang AST Matchers.

dot>>>Задоблаешься. Скажем, частенько при интеграции с другими библиотеками, особенно C, может вылезти:
dot>>>
dot>>>Obj *obj2 = (Obj *)obj2;
dot>>>

dot>>>И нифига ненаверифицируешь.
EP>>Старый cast легко отлавливается компилятором, например опция GCC -Werror-old-style-cast
dot>Ну пусть будет reinterpret_cast<Obj *>(obj) какая разница-то?

1. reinterpret_cast не снимает константность, мы же о ней говорим?
2. ловится тем же grep'ом

dot>>>И вообще, никакая это не верификация, а статический анализ.

EP>>Это верификация соответствия требованиям.
dot>Под верификацией обычно понимается проверка формальными методами. А так — анализ, тестирование.

Это не тестирование точно. Под определение верификации попадает, причём и на рус/eng. Ну да ладно, это уже чистая терминология.

EP>>>>В Java у volatile семантика другая нежели чем у C++. Для этой же цели используются std/boost::atomic. То есть будет не volatile ImmutableClass *, а atomic<ImmutableClass *>.

dot>>>О, наконец-то стало можно. Если не ошибаюсь, в С++ это появилось c 2011, в Яве же с 2004.
EP>>В стандарте C++11 появились std::atomic, memory model, да и вообще понятие потока.
EP>>Библиотечные же реализации работают и в C++1998.
dot>Ну так нечестно.

Почему не честно-то? Например де-юре потоков в языке C++ не было, де-факто были на каждой платформе их поддерживающей, плюс были и есть кроссплатформенные библиотеки типа Intel Threading Building Blocks, Boost.Thread.

dot>А то я скажу, что "gc можно отключить в java" если использовать библиотеки с off-heap.


Так ведь так и делают, работают против языка, убегают от GC, потому что он доставляет вполне конкретные проблемы.

В случае же с boost::thread и т.п. — наоборот работа вместе с языком, а не вопреки ему — std::thread вошёл в стандарт практически в таком же виде, каком он и так был де-факто в библиотеках C++98.
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 16:54
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Не надо оправдываться абстрактными "OOM везде можно получить" — я так тоже умею: "везде можно получить расстрел памяти, даже при использовании Java"

dot>>Расстрел памяти в Java? Как???
EP>Элементарно. Её может расстрелять сторонняя native библиотека, причём даже не из-за бага в самой библиотеке, а потому что Java код нарушил предусловия. Или например может расстрелять свой же Runtime — гарантии нет
EP>Это аргумент примерно того же порядка что и "OOM везде можно получить" в ответ на описание конкретного use-case'а.
Ты описал юзкейс когда память освобождается медленнее чем потребляется. Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах?
Если ты имеешь в виду, что gc выделенного времени не хватило чтобы освободить память, то jvm всегда даёт шанс gc прежде чем бросить ООМ исключение. Да, будет latency spike, но не ООМ. Но это бага конфигурации, исправляется.

EP>>>Как того требует задача. Если нужно ограничить время — то соответственно засекаешь время/тики, или что там удобнее.

dot>>Время чего? Вот у тебя
dot>>
dot>>smartPtr.release(); // упс, заняло 300ms, хотя обычно занимает 3us. Нам не повезло оказаться последним юзером объекта и граф объектов оказался больше обычного.
dot>>

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

EP>>>Например в порядке очереди.

dot>>Как выстоить в очередь граф объектов?
EP>Например в деструкторе smart-pointer'а не сразу удалять, а ставить в очередь.
Если много мелких объектов — очереди поплохеет, будет хороший такой contention point.

EP>>>Нет, это неверно. Задача GC в первую очередь отличить reachable от unreachable объектов. А уж делать reclaim порциями, или за один присест — это уже отдельное свойство, причём ортогональное наличию/отсутствию GC.

dot>>GC в Java это целый комплекс алгоритмов с тучей настроек. Задача — освобождать память от unreachable объектов, а не просто "отличить".
EP>А ещё он внутри делает сложение целых чисел. Из этого не следует что сложение целых чисел это "переизобретание современного GC".
Ты задачу GC как-то странно определил. Не отличает он, а освобождает. Отличить — подзадача.

EP>>>И, кстати, для C++ возможен и runtime'овый GC (прям в стандарте есть специальное API), и библиотечный (я даже как-то делал for fun).

dot>>Но как? Precise GC принципиально невозможен.
EP>Возможен. Заводится отдельная GC Heap, все указатели на элементы внутри этой кучи заворачиваются в gc_ptr<T>.
EP>Отличать root от не root можно разными способами. Например если сам объект-указатель типа gc_ptr находится не в этой куче — то это root.
EP>AFAIR, нечто подобное используется в SpiderMonkey.
Я не понимаю чем "написать либу которая делает gc" и "написать jvm которая делает gc". Так хоть можно сказать, что и в маш-кодах gc есть.

dot>>>>Сам же написал "GC линеен от количества N живых объектов", т.е. сдохший шмат графа можно освобождать также за примерно O(1).

EP>>>При этом сделав O(N) обход живых объектов, которого нет в случае с C++
dot>>В YG это N малО, а OG обходится не часто,
EP>Чем больше N — тем чаще. В любом случае это не O(1).
Я имею в виду O(1) если N — количество дохлых объектов, для ситуации когда ты сказал "массив объектов, агрегирующих ... просто по сути один вектор освобождающийся за O(1)". Да, этот один вектор умирающий целиком будет освобождаться за O(1), т.е. независимо от размера этого самого вектора. Да, оно будет зависеть от наличия других живых объектов, но это не то, что я понял из этих твоих слов.

dot>>и обычно минимально влияя на основные потоки.

EP>Memory throughput не бесконечная, более того — часто является bottleneck'ом. GC во время обхода интенсивно использует память, сужая этот bottleneck.
Пусть, для LL критичной системы gc будет работать на другом ядре, используя другой банк памяти (опять же, заметь, — ничего java specific).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 17:23
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Не надо оправдываться абстрактными "OOM везде можно получить" — я так тоже умею: "везде можно получить расстрел памяти, даже при использовании Java"

dot>>>Расстрел памяти в Java? Как???
EP>>Элементарно. Её может расстрелять сторонняя native библиотека, причём даже не из-за бага в самой библиотеке, а потому что Java код нарушил предусловия. Или например может расстрелять свой же Runtime — гарантии нет
EP>>Это аргумент примерно того же порядка что и "OOM везде можно получить" в ответ на описание конкретного use-case'а.
dot>Ты описал юзкейс когда память освобождается медленнее чем потребляется.

Причём это происходит по вине самого GC.

dot>Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах?


Нет линейной зависимости времени очистки от количества живых объектов. В случае же GC, на одной и той же скорости входящего потока он может либо успевать очищать, либо нет — и это сильно зависит от текущего количества живых объектов.

dot>Если ты имеешь в виду, что gc выделенного времени не хватило чтобы освободить память, то jvm всегда даёт шанс gc прежде чем бросить ООМ исключение. Да, будет latency spike, но не ООМ. Но это бага конфигурации, исправляется.


Так в это время (пока JVM даёт шанс) будут накапливаться всё новые и новые запросы, требующие всё новую и новую память. Это либо OOM либо DoS, а не просто spike.

EP>>>>Как того требует задача. Если нужно ограничить время — то соответственно засекаешь время/тики, или что там удобнее.

dot>>>Время чего? Вот у тебя
dot>>>
dot>>>smartPtr.release(); // упс, заняло 300ms, хотя обычно занимает 3us. Нам не повезло оказаться последним юзером объекта и граф объектов оказался больше обычного.
dot>>>

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

Зачем?

EP>>>>Например в порядке очереди.

dot>>>Как выстоить в очередь граф объектов?
EP>>Например в деструкторе smart-pointer'а не сразу удалять, а ставить в очередь.
dot>Если много мелких объектов — очереди поплохеет, будет хороший такой contention point.

Очередь может быть thread local.

EP>>>>Нет, это неверно. Задача GC в первую очередь отличить reachable от unreachable объектов. А уж делать reclaim порциями, или за один присест — это уже отдельное свойство, причём ортогональное наличию/отсутствию GC.

dot>>>GC в Java это целый комплекс алгоритмов с тучей настроек. Задача — освобождать память от unreachable объектов, а не просто "отличить".
EP>>А ещё он внутри делает сложение целых чисел. Из этого не следует что сложение целых чисел это "переизобретание современного GC".
dot>Ты задачу GC как-то странно определил. Не отличает он, а освобождает. Отличить — подзадача.

В любом случае, ты же говоришь что если делать отложенное очищение, то получаем GC. А если делать сразу почему тогда не GC? А если тоже считаешь что GC, зачем тогда вообще выделять отдельно случай с отложенным очищением?

EP>>>>И, кстати, для C++ возможен и runtime'овый GC (прям в стандарте есть специальное API), и библиотечный (я даже как-то делал for fun).

dot>>>Но как? Precise GC принципиально невозможен.
EP>>Возможен. Заводится отдельная GC Heap, все указатели на элементы внутри этой кучи заворачиваются в gc_ptr<T>.
EP>>Отличать root от не root можно разными способами. Например если сам объект-указатель типа gc_ptr находится не в этой куче — то это root.
EP>>AFAIR, нечто подобное используется в SpiderMonkey.
dot>Я не понимаю чем "написать либу которая делает gc" и "написать jvm которая делает gc". Так хоть можно сказать, что и в маш-кодах gc есть.

Разница в том, что написанная библиотека используется внутри самого host-языка. То есть эти gc_ptr — они используется не внутри какой-то виртуальной среды созданной библиотекой, а внутри вызывающего host-языка.

dot>>>и обычно минимально влияя на основные потоки.

EP>>Memory throughput не бесконечная, более того — часто является bottleneck'ом. GC во время обхода интенсивно использует память, сужая этот bottleneck.
dot>Пусть, для LL критичной системы gc будет работать на другом ядре, используя другой банк памяти (опять же, заметь, — ничего java specific).

Какой другой банк памяти? Ему нужно обходить именно ту память, с которой работают полезные потоки, тем самым путаясь у них под ногами.
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 17:25
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение,

EP>>>Пусть просто поставит в очередь, делов-то
dot>>Поставит что? Сразу весь развесистый граф? А если надо только часть освободить? Ставить каждый самый мелкий объект? А очереди не поплохеет?
EP>Не каждый объект, а те которые не успеваем освободить.
А как мы будем выяснять — успеем или не успеем?

dot>>>>На java память ресурс другого типа. "Освобождать память" там нельзя.

EP>>>А я поэтому и сказал конкретно "ресурс", а не просто "объект". Да и память не ресурс только если она не ограниченна — упрёшься в предел, получишь удар по latency, на который постоянно ссылаешься.
dot>>В low latency единственный ресурс обычно память.
EP>Сильное утверждение. Да и это проблема ко всему относится, а не только к low latency.
Что-то не понял. Которая проблема?

dot>>Из LL кода никто в своём уме коннекты к БД не открывает, с SOAP сервисам не обращается.

EP>Файлы не открывают? Соединения не устанавливают?
Нет, конечно. С ума что-ли сошел? Кто ж файл будет открывать из LL треда?!

dot>>>>А для ресурсов в общем случае — наследники java.lang.ref.Reference.

EP>>>Каким образом они обеспечат prompt finalization?
dot>>А надо?
EP>Надо, это задача.
Какая именно задача? Ты не путаешь задачу со способом решения?

dot>>А зачем вообще ресурсы обязательно освобождать из финалайзеров?

EP>Освобождай откуда угодно, но покажи как это реализуется в Java.
try(Connection connection = database.openConnection())
{
  connection.doSomething();
}// connection released.

или
database.use(connection -> 
{
  connection.doSomething();
});


dot>>Я не понял какую задачу ты описываешь.

EP>Ту же самую, с потоками, при завершении последнего нужно освободить ресурс.
Эээ.. Попробую сформулировать. Открыть файл, раздать открытый файл пачке тредов, которые могут так же кидаться файлами с другими тредами и закрыть, когда последний тред его обработает. Так? Собственно решение будет аналогично С++, взять какой-нибудь подходящий класс из java.lang.concurrent.* и реализовать контроль пользователей ресурса.
Ещё раз, в java есть только один специально обрабатываемый ресурс — память. Не надо натягивать gc на контроль любых ресурсов, он только для памяти.
Я понимаю откуда растёт это заблуждение. Деструктор в С++ может быть использован как для памяти, так и для любых других ресурсов. Не надо переносить это понимание в java. В java gc — только для памяти. Другие ресурсы — с помощью try-with-resources контролируются.

dot>>>>Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.

EP>>>При GC чуть проще реализация lockfree структур данных, за счёт ABA, но при этом сами GC в большинстве своём не lockfree (lockfree GC видел только в статьях) — то есть тут уже большой терминологический вопрос, остаётся ли структура данных lockfree при не non-lockfree GC
dot>>Если локи расставляются сами компилятором и лочится на предсказуемое время — почему бы и нет.
EP>Потому что lock'и это не lockfree, принципиально. Смотри определение. Lockfree это прежде всего некоторые гарантии, а не например скорость — скорость вообще может быть меньше.
EP>Да и кто сказал что время предсказуемо? Например GC заснул захватив lock, остальные ждут. Тут желательно хотя бы obstruction free
lockfree это гарантии на уровне кода, а что там делает окружение — не важно. Скажем, если операционка вытесняет твой поток — по сути она лочит его — исполнение приостанавливается. А ещё и CPU может заснуть, скажем для экономии энергии или для регуляции тепловыделения. И что? lockfree и на C++ невозможен?
В том то и дело, что gc в java это часть окружения для твоего кода, и отсутсвие дедлоков в lockfree коде можно гарантировать. Библиотечный gc в C++ — упс.

EP>>>Да и такие структуры должны реализовывать профессионалы своего дела, так как это трудная/опасная тема.

dot>>В том то и дело. Это уже и реализовали в виде JVM — бери, да используй, а не изобретай велосипед.
EP>А я предлагал изобретать? Я сказал что ABA проще решается при использовании GC, решать её при этом самому не обязательно.
Много что проще решается. Я тебе сразу сказал "Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc."
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 17:43
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Если VM оптимизатор видит, что объект используется только в одном месте, он переносит ссылку на стек, т.е. по сути выводит unique_ptr.

EP>И не в покер, а в преферанс. И не выиграл, а проиграл.
EP>И не ссылку, а сам объект. И не unique_ptr, а просто стэковый объект.
Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

dot>>>>shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.

EP>>>Как weak_ptr относится к дискуссии?
dot>>Как я понял, ты предлагаешь выделить один тред как владелец объекта, т.е. тот, кто держит shared_ptr, а другие треды — просто пользователи объекта, им отдаётся weak_ptr (не голые же указатели передавать?!).
EP>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика
EP>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.
Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются.

EP>>>>>А например OOM — тоже вполне серьёзно

dot>>>>ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.
EP>>>OOM он конечно везде OOM, но причины наступления бывают разные
dot>>OOM не кидается в случае если gc есть что освободить.
EP>Упёрлись в потолок, GC начинает очень долго освобождать за O(N), отбирая ресурсы у других потоков, общая пропускная способность снижается (забиты каналы памяти, и аллокации происходят медленней), извне приходят всё новые задачи для которых в свою очередь нужна всё новая память, в конце концов либо OOM либо DoS.
Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java.

EP>Вот в этом "делаешь" и есть проблема.


EP>Такой Array и другие контейнеры нужно делать для каждого типа данных. У тебя будут FooArray, BarArray, FooPriorityQueue, BarPriorityQueue и т.д.

EP>Либо как вариант добавлять лишней динамичности, но от неё будут свои тормоза, причём как размеры заранее не известны.
В LL не так уж и много разных структур. И, как и в С++, и, скорее, всего будут поверх array.

dot>>Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет.

EP>Это одна из главных причин тормозов в языках с превалирующей pointer semantics. Положил класс с несколькими полями-объектами в массив — уже на ровном месте выросло целое дерево индерекций и аллокаций.
В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это. Да, разные инструменты — разные способы решения задач.

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

EP>Нет, не хуже, также как и обычный вариант. В реализации — да, код не самый простой, но она пишется один раз.
EP>Да и это же Array of Structures, нужно не так часто. Речь же про то, что в Java же нет самых обычных структур — для быстрого кода это супер-критично, именно поэтому и нарезают вручную.
Критически быстрого кода не так много. А значит "нужно не так часто".

EP>>>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.

dot>>Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.
EP>Хуже, намного. Разве пример со структурами тебя не убедил? — это реально уровень ниже чем C, на ровном месте. Так это только один аспект.
EP>Быстрый код на C++ можно писать на высоком уровне абстракции — не нужно отказываться ни от замыканий, ни от классов, ни от ФВП и полиморфизма — и при этом он будет давать точно такое же (либо практически такое же) быстродействие как и такой же код написанный на низком уровне вручную — в этом одна из главных фишек C++.
Тут не фичи и уровни абстракции, а хранение и передача данных главное. И там и там об этом надо заботиться. В Яве — не создавать лишних индирекций, в плюса — не делать лишних копий и аккуратно заботиться о владении. Ведь тоже ничего хорошего в том, когда все эти уровни абстракции только и делают, что решают проблемы владения, тогда как в яве оно само, из коробки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 17:50
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>И нифига ненаверифицируешь.

EP>>>Старый cast легко отлавливается компилятором, например опция GCC -Werror-old-style-cast
dot>>Ну пусть будет reinterpret_cast<Obj *>(obj) какая разница-то?
EP>1. reinterpret_cast не снимает константность, мы же о ней говорим?
С void* не снимает?

EP>2. ловится тем же grep'ом

Ну поймали. Для какой-то там 3rd party C библиотеки — оно необходимо. Дальше что?

dot>>А то я скажу, что "gc можно отключить в java" если использовать библиотеки с off-heap.

EP>Так ведь так и делают, работают против языка, убегают от GC, потому что он доставляет вполне конкретные проблемы.
И что? Отстутсвие gc тоже доставляет вполне конкретные проблемы, и, кстати, на порядки чаще.

EP>В случае же с boost::thread и т.п. — наоборот работа вместе с языком, а не вопреки ему — std::thread вошёл в стандарт практически в таком же виде, каком он и так был де-факто в библиотеках C++98.

DirectBuffer тоже вошел давно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 18:06
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Элементарно. Её может расстрелять сторонняя native библиотека, причём даже не из-за бага в самой библиотеке, а потому что Java код нарушил предусловия. Или например может расстрелять свой же Runtime — гарантии нет

EP>>>Это аргумент примерно того же порядка что и "OOM везде можно получить" в ответ на описание конкретного use-case'а.
dot>>Ты описал юзкейс когда память освобождается медленнее чем потребляется.
EP>Причём это происходит по вине самого GC.
Ну подкрути параметры чуток, не проблема.

dot>>Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах?

EP>Нет линейной зависимости времени очистки от количества живых объектов. В случае же GC, на одной и той же скорости входящего потока он может либо успевать очищать, либо нет — и это сильно зависит от текущего количества живых объектов.
Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы.

dot>>Если ты имеешь в виду, что gc выделенного времени не хватило чтобы освободить память, то jvm всегда даёт шанс gc прежде чем бросить ООМ исключение. Да, будет latency spike, но не ООМ. Но это бага конфигурации, исправляется.

EP>Так в это время (пока JVM даёт шанс) будут накапливаться всё новые и новые запросы, требующие всё новую и новую память. Это либо OOM либо DoS, а не просто spike.
Это значит, что тупо не хватает ресурсов CPU, в этом случае загнётся всё.

dot>>>>Время чего? Вот у тебя

dot>>>>
dot>>>>smartPtr.release(); // упс, заняло 300ms, хотя обычно занимает 3us. Нам не повезло оказаться последним юзером объекта и граф объектов оказался больше обычного.
dot>>>>

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

dot>>>>Как выстоить в очередь граф объектов?

EP>>>Например в деструкторе smart-pointer'а не сразу удалять, а ставить в очередь.
dot>>Если много мелких объектов — очереди поплохеет, будет хороший такой contention point.
EP>Очередь может быть thread local.
И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос.

dot>>>>GC в Java это целый комплекс алгоритмов с тучей настроек. Задача — освобождать память от unreachable объектов, а не просто "отличить".

EP>>>А ещё он внутри делает сложение целых чисел. Из этого не следует что сложение целых чисел это "переизобретание современного GC".
dot>>Ты задачу GC как-то странно определил. Не отличает он, а освобождает. Отличить — подзадача.
EP>В любом случае, ты же говоришь что если делать отложенное очищение, то получаем GC. А если делать сразу почему тогда не GC? А если тоже считаешь что GC, зачем тогда вообще выделять отдельно случай с отложенным очищением?
Это тоже подзадача GC — решать сразу или отложить.

EP>>>Возможен. Заводится отдельная GC Heap, все указатели на элементы внутри этой кучи заворачиваются в gc_ptr<T>.

EP>>>Отличать root от не root можно разными способами. Например если сам объект-указатель типа gc_ptr находится не в этой куче — то это root.
EP>>>AFAIR, нечто подобное используется в SpiderMonkey.
dot>>Я не понимаю чем "написать либу которая делает gc" и "написать jvm которая делает gc". Так хоть можно сказать, что и в маш-кодах gc есть.
EP>Разница в том, что написанная библиотека используется внутри самого host-языка. То есть эти gc_ptr — они используется не внутри какой-то виртуальной среды созданной библиотекой, а внутри вызывающего host-языка.
Так и деструкторы и прочие С++ фишки можно реализовать в java, см. offheap. Выделяешь память как блок внутри DirectBuffer, вместо использования оператора new. Непонятно только к чему всё это.

dot>>>>и обычно минимально влияя на основные потоки.

EP>>>Memory throughput не бесконечная, более того — часто является bottleneck'ом. GC во время обхода интенсивно использует память, сужая этот bottleneck.
dot>>Пусть, для LL критичной системы gc будет работать на другом ядре, используя другой банк памяти (опять же, заметь, — ничего java specific).
EP>Какой другой банк памяти? Ему нужно обходить именно ту память, с которой работают полезные потоки, тем самым путаясь у них под ногами.
Хм, не знаю. Может быть, но пока не доводилось с подобными проблемами сталкиваться. В Memory throughput пока не упирались. LL обычно пишется garbage-free, и поэтому нагрузка на gc минимальна. В high throughput — да, возможно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 18:12
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>>>Мало того, тот кому не повезло освобождать ссылку последним — не придётся тратить ВНЕЗАПНО время на освобождение,

EP>>>>Пусть просто поставит в очередь, делов-то
dot>>>Поставит что? Сразу весь развесистый граф? А если надо только часть освободить? Ставить каждый самый мелкий объект? А очереди не поплохеет?
EP>>Не каждый объект, а те которые не успеваем освободить.
dot>А как мы будем выяснять — успеем или не успеем?

Замерами — например смотрим максимальное/среднее/etc время очистки одного узла. Причём тот же finalize есть и Java.
Если же речь идёт о hard real time — то там применяются совершенно другие приёмы.

dot>>>>>На java память ресурс другого типа. "Освобождать память" там нельзя.

EP>>>>А я поэтому и сказал конкретно "ресурс", а не просто "объект". Да и память не ресурс только если она не ограниченна — упрёшься в предел, получишь удар по latency, на который постоянно ссылаешься.
dot>>>В low latency единственный ресурс обычно память.
EP>>Сильное утверждение. Да и это проблема ко всему относится, а не только к low latency.
dot>Что-то не понял. Которая проблема?

Задача работы с ресурсами.

dot>>>>>А для ресурсов в общем случае — наследники java.lang.ref.Reference.

EP>>>>Каким образом они обеспечат prompt finalization?
dot>>>А надо?
EP>>Надо, это задача.
dot>Какая именно задача? Ты не путаешь задачу со способом решения?

Задача — своевременное освобождение ресурсов.

dot>>>А зачем вообще ресурсы обязательно освобождать из финалайзеров?

EP>>Освобождай откуда угодно, но покажи как это реализуется в Java.
dot>
dot>try(Connection connection = database.openConnection())
dot>{
dot>  connection.doSomething();
dot>}// connection released.
dot>

dot>или
dot>
dot>database.use(connection -> 
dot>{
dot>  connection.doSomething();
dot>});
dot>


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

dot>>>Я не понял какую задачу ты описываешь.

EP>>Ту же самую, с потоками, при завершении последнего нужно освободить ресурс.
dot>Эээ.. Попробую сформулировать. Открыть файл, раздать открытый файл пачке тредов, которые могут так же кидаться файлами с другими тредами и закрыть, когда последний тред его обработает. Так? Собственно решение будет аналогично С++, взять какой-нибудь подходящий класс из java.lang.concurrent.* и реализовать контроль пользователей ресурса.

Как именно? Как ресурс будет передаваться в потоки? Кто и как будет решать что нужно удалить?

dot>Ещё раз, в java есть только один специально обрабатываемый ресурс — память. Не надо натягивать gc на контроль любых ресурсов, он только для памяти.


А я не натягиваю. Я предлагаю тебе решить, или хотя бы описать решение любым способом.

dot>Я понимаю откуда растёт это заблуждение. Деструктор в С++ может быть использован как для памяти, так и для любых других ресурсов. Не надо переносить это понимание в java. В java gc — только для памяти. Другие ресурсы — с помощью try-with-resources контролируются.


Про заблуждение это ты придумал. Я прекрасно знаю об этих всех костылях а-ля with/using/try-with-resources.

dot>>>>>Ну да... Только, как мне кажется. эти схемы гораздо проще если есть gc.

EP>>>>При GC чуть проще реализация lockfree структур данных, за счёт ABA, но при этом сами GC в большинстве своём не lockfree (lockfree GC видел только в статьях) — то есть тут уже большой терминологический вопрос, остаётся ли структура данных lockfree при не non-lockfree GC
dot>>>Если локи расставляются сами компилятором и лочится на предсказуемое время — почему бы и нет.
EP>>Потому что lock'и это не lockfree, принципиально. Смотри определение. Lockfree это прежде всего некоторые гарантии, а не например скорость — скорость вообще может быть меньше.
EP>>Да и кто сказал что время предсказуемо? Например GC заснул захватив lock, остальные ждут. Тут желательно хотя бы obstruction free
dot>lockfree это гарантии на уровне кода, а что там делает окружение — не важно. Скажем, если операционка вытесняет твой поток — по сути она лочит его — исполнение приостанавливается. А ещё и CPU может заснуть, скажем для экономии энергии или для регуляции тепловыделения. И что? lockfree и на C++ невозможен?

Прочитай определение lock-free.

dot>Я тебе сразу сказал "Когда ответишь на эти вопросы и многие другие, то переизобретёшь современный gc."


Опять неверно.
Re[23]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 18:59
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Если VM оптимизатор видит, что объект используется только в одном месте, он переносит ссылку на стек, т.е. по сути выводит unique_ptr.

EP>>И не в покер, а в преферанс. И не выиграл, а проиграл.
EP>>И не ссылку, а сам объект. И не unique_ptr, а просто стэковый объект.
dot>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

То есть имелось в виду scoped_ptr — более ограниченная версия unique_ptr. Например unique_ptr можно возвращать из функции.
И то, если брать случай с массивом как ты сказал — то тут не нужен никакой *_ptr, достаточно просто vector:
{
    vector<Widget> values(N);
    foo();
    // ...
}


dot>массив не убегает за пределы, то при выходе из стека объект грохнется


Каким образом грохнется? Речь только про некомпактифицируемые кучи?

dot>>>>>shared_ptr у треда-владельца, а "зависимые" — имеют weak_ptr.

EP>>>>Как weak_ptr относится к дискуссии?
dot>>>Как я понял, ты предлагаешь выделить один тред как владелец объекта, т.е. тот, кто держит shared_ptr, а другие треды — просто пользователи объекта, им отдаётся weak_ptr (не голые же указатели передавать?!).
EP>>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика
EP>>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.
dot>Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются.

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

EP>>>>>>А например OOM — тоже вполне серьёзно

dot>>>>>ООМ происходит в яве ровно так же как и в плюсах. Всё то же самое.
EP>>>>OOM он конечно везде OOM, но причины наступления бывают разные
dot>>>OOM не кидается в случае если gc есть что освободить.
EP>>Упёрлись в потолок, GC начинает очень долго освобождать за O(N), отбирая ресурсы у других потоков, общая пропускная способность снижается (забиты каналы памяти, и аллокации происходят медленней), извне приходят всё новые задачи для которых в свою очередь нужна всё новая память, в конце концов либо OOM либо DoS.
dot>Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java.

Не грохнется — у него нет зависимости O(N) от количества живых объектов.

EP>>Вот в этом "делаешь" и есть проблема.

EP>>Такой Array и другие контейнеры нужно делать для каждого типа данных. У тебя будут FooArray, BarArray, FooPriorityQueue, BarPriorityQueue и т.д.
EP>>Либо как вариант добавлять лишней динамичности, но от неё будут свои тормоза, причём как размеры заранее не известны.
dot>В LL не так уж и много разных структур.

Ты постоянно говоришь о каком-то одном use-case'ы.
Даже если и мало — всё равно придётся опускаться на очень низкий уровень, исключительно из-за самого языка.

dot>И, как и в С++, и, скорее, всего будут поверх array.


Это ты о чём?
Например на C++ есть выгода от структур (в смысле хранения по значению) даже для вещей типа сбалансированных деревьев — так как уменьшает количество индерекций — само значение хранится в узле, а не указатель на значение.

dot>>>Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет.

EP>>Это одна из главных причин тормозов в языках с превалирующей pointer semantics. Положил класс с несколькими полями-объектами в массив — уже на ровном месте выросло целое дерево индерекций и аллокаций.
dot>В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это.

Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры

dot>Да, разные инструменты — разные способы решения задач.


Тут не спорю

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

EP>>Нет, не хуже, также как и обычный вариант. В реализации — да, код не самый простой, но она пишется один раз.
EP>>Да и это же Array of Structures, нужно не так часто. Речь же про то, что в Java же нет самых обычных структур — для быстрого кода это супер-критично, именно поэтому и нарезают вручную.
dot>Критически быстрого кода не так много. А значит "нужно не так часто".

Мы же быстрый код обсуждаем?

EP>>>>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.

dot>>>Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.
EP>>Хуже, намного. Разве пример со структурами тебя не убедил? — это реально уровень ниже чем C, на ровном месте. Так это только один аспект.
EP>>Быстрый код на C++ можно писать на высоком уровне абстракции — не нужно отказываться ни от замыканий, ни от классов, ни от ФВП и полиморфизма — и при этом он будет давать точно такое же (либо практически такое же) быстродействие как и такой же код написанный на низком уровне вручную — в этом одна из главных фишек C++.
dot>Тут не фичи и уровни абстракции, а хранение и передача данных главное. И там и там об этом надо заботиться. В Яве — не создавать лишних индирекций, в плюса — не делать лишних копий и аккуратно заботиться о владении. Ведь тоже ничего хорошего в том, когда все эти уровни абстракции только и делают, что решают проблемы владения, тогда как в яве оно само, из коробки.

Это уже передёргивание. Да, работу с памятью GC упрощают (при этом не гарантируя отсутствие утечек). Да, на C++ нужно думать/помнить о владении (это не означает что каждый new на Java превращается в *_ptr).
Нет, уровни абстракции о которых я говорю решают далеко не только проблемы владения — они позволяют писать высокоуровневый И быстрый код.
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 19:11
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>>>И нифига ненаверифицируешь.

EP>>>>Старый cast легко отлавливается компилятором, например опция GCC -Werror-old-style-cast
dot>>>Ну пусть будет reinterpret_cast<Obj *>(obj) какая разница-то?
EP>>1. reinterpret_cast не снимает константность, мы же о ней говорим?
dot>С void* не снимает?

reinterpret_cast не снимает const с const void *p.

EP>>2. ловится тем же grep'ом

dot>Ну поймали. Для какой-то там 3rd party C библиотеки — оно необходимо. Дальше что?

Явно разрешаем несколько таких unsafe мест. И?

EP>>В случае же с boost::thread и т.п. — наоборот работа вместе с языком, а не вопреки ему — std::thread вошёл в стандарт практически в таком же виде, каком он и так был де-факто в библиотеках C++98.

dot>DirectBuffer тоже вошел давно.

Так смысл-то не то что boost::thread есть давно, а в том что он удобен для своей задачи. Если же смотреть на эти все *Buffer для эмуляции структур — то очевидно что сами структуры удобнее на порядки
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 19:43
Оценка:
Здравствуйте, ·, Вы писали:

EP>>Причём это происходит по вине самого GC.

dot>Ну подкрути параметры чуток, не проблема.

Это уберёт линейную сложность?

dot>>>Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах?

EP>>Нет линейной зависимости времени очистки от количества живых объектов. В случае же GC, на одной и той же скорости входящего потока он может либо успевать очищать, либо нет — и это сильно зависит от текущего количества живых объектов.
dot>Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы.

В очереди объекты которые уже готовы для очистки. А вот сколько там живых reachable объектов — не важно, пусть хоть десять миллиардов.

dot>Это значит, что тупо не хватает ресурсов CPU, в этом случае загнётся всё.


Так не хватает-то их из-за линейной сложности GC.

EP>>Зачем?

dot>Определить граф-остаток.

Зачем его определять? Что это даст?
Пока не превысим бюджет времени — удаляем сами, как только времени осталось меньше чем требует max объект — ставим остаток в очередь.

EP>>Очередь может быть thread local.

dot>И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос.

От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC.

dot>Это тоже подзадача GC — решать сразу или отложить.


А ещё в подзадачах GC есть сложение целых.

EP>>Разница в том, что написанная библиотека используется внутри самого host-языка. То есть эти gc_ptr — они используется не внутри какой-то виртуальной среды созданной библиотекой, а внутри вызывающего host-языка.

dot>Так и деструкторы и прочие С++ фишки можно реализовать в java,

Каким образом ты реализуешь деструкторы? Какое будет использование? Каким образом реализуешь например Expression Templates и прочие compile-time EDSL?

dot>см. offheap. Выделяешь память как блок внутри DirectBuffer, вместо использования оператора new. Непонятно только к чему всё это.


Ну так этот блок придётся вручную нарезать на структуры, о чём я выше и говорил.
Re[13]: Java vs C# vs C++
От: PM  
Дата: 08.10.15 19:49
Оценка:
Здравствуйте, ·, Вы писали:

PM>>>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>


·>Война была, да и до сих пор ведётся не с java, а с архитектурой и железом. 90% тех решений подходит и для С++.


Только цена усилий по улучшению быстродействия в проекте на C++ гораздо меньше. Понадобилось попадание в кэш-линию и исключение false sharing — выровняли структуру. Не нужно переключение контекста — привязали поток к конкретному ядру. SIMD, вычисления на GPU, сетевой стек в user space. В Java с этим будут трудности. И героически преодолевать их — см. выделенное.

PM>>Я почитал ваши сообщения в ветке. Ещё одна иллюстрация, что люди не из мира C++ продолжают верить в мифы 15-20 летней давности. Авторы LMAX скорее всего тоже подумали: "Писать такое на C++... неее... проще застрелиться" и взяли хорошо известный им и широко распространённый инструмент. Хорошо, что при этом они не застрелились

·>На плюсах есть куски или нативные либы, но как-то постепенно перетекает всё в java. Ибо работает так же, а добавляется куча преимуществ (см ролик http://rsdn.ru/forum/philosophy/6205646.1
Автор: Evgeny.Panasyuk
Дата: 07.10.15
)

·>Как в одно время был процесс переползания с ассемблеров на фортран, на С, на С++, теперь вот java. Конечно, на arduino яву не запустишь, но нишу LL она уверенно отвоёвывает.

Да, да, "write once, run anywhere", Java завоюет мир... Когда-то читал про такое, лет 20 назад. По-моему ниша Java всё та же — корпоративные и банковские приложения. Может андроид слегка добавил, пока разработчики не выяснили, что писать мобильные приложения выгоднее с общим ядром на C++ и пользовательским интерфейсом под конкретную платформу.

Я, может быть, тоже продолжаю верить в мифы 20-летней давности про Java, но пока темы в этом разделе лишь укрепляют их

PM>>Часть кода, кстати, открыта: https://github.com/LMAX-Exchange/disruptor и выглядит на мой взгляд over engineering. Хотя, может для Java мира это нормально

·>Видимо поэтому этот over engineering стырили https://code.google.com/p/disruptor-cpp/ https://github.com/disruptor-net/Disruptor-net Как видишь — дело не в языке, а в архитектуре.

Это издержки портирования с другого языка. Таким же образом из Java мира перевели jUnit. И где тот cppUnit? В новых проектах на C++ теперь обычно встречаются Catch, Boost.Test, Google test потому что они используют идиомы C++

И для Disruptor есть непохожая на Java реализация: https://github.com/bytemaster/disruptor
Re[27]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 08.10.15 19:55
Оценка:
Здравствуйте, ·, Вы писали:

·>И с тех пор ты никогда в жизни не расстрелял память или не видел, когда вполне дисциплинированый дев расстреливал?

·>В ядре линуха такие баги находили (а там, видимо бардак и диверсанты).

А, я забыл, программы на жабе и шарпе никогда на глючат и в них не бывает багов.

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


Всё смешалось в кучу, люди, кони. Как наличие деструкторов мешает иммутабельным типам?
Расскажи, в жабошарпах можно ли кастовать мутабельный указатель в немутабельный?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 20:29
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>И с тех пор ты никогда в жизни не расстрелял память или не видел, когда вполне дисциплинированый дев расстреливал?

TB>·>В ядре линуха такие баги находили (а там, видимо бардак и диверсанты).
TB>А, я забыл, программы на жабе и шарпе никогда на глючат и в них не бывает багов.
Ты вроде обещал, что будет дисциплина — проблемы не будет. Однако, чуда не вышло.

TB>·>Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).

TB>Всё смешалось в кучу, люди, кони. Как наличие деструкторов мешает иммутабельным типам?
Что наличие ссылки на иммутабельный объект не даёт гарантии, что его поведение не поменяется.

TB>Расскажи, в жабошарпах можно ли кастовать мутабельный указатель в немутабельный?

В смысле присвоить новое значение к final полю/переменной? Нет, конечно. Нельзя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 08.10.15 20:41
Оценка:
Здравствуйте, ·, Вы писали:

·>Ты вроде обещал, что будет дисциплина — проблемы не будет. Однако, чуда не вышло.


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

·>Что наличие ссылки на иммутабельный объект не даёт гарантии, что его поведение не поменяется.


Я тупой, так что давай выкладывай все звенья логической цепи.

TB>>Расскажи, в жабошарпах можно ли кастовать мутабельный указатель в немутабельный?

·>В смысле присвоить новое значение к final полю/переменной? Нет, конечно. Нельзя.

Ааа, иммутабельный класс — это класс, в котором все поля final?
Можно ли в С++ можно всем полям написать const? Нет, конечно. Нельзя. (Сарказм).
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[14]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 20:48
Оценка:
Здравствуйте, PM, Вы писали:

PM>>>>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>

PM>·>Война была, да и до сих пор ведётся не с java, а с архитектурой и железом. 90% тех решений подходит и для С++.
PM>Только цена усилий по улучшению быстродействия в проекте на C++ гораздо меньше.
Не правда.

PM> Понадобилось попадание в кэш-линию и исключение false sharing — выровняли структуру. Не нужно переключение контекста — привязали поток к конкретному ядру.

PM> SIMD, вычисления на GPU, сетевой стек в user space. В Java с этим будут трудности. И героически преодолевать их — см. выделенное.
И что из этого невозможно сделать ява?
А какие именно трудности? Можно по пунктам?
SIMD инструкции генерятся JIT (хотя интересно услышать о их полезности в low latency/finance).
сетевой стек — это этот что-ли? http://docs.oracle.com/javase/tutorial/sdp/sockets/
GPU — тоже непонятна полезность, да и тоже куча всего http://stackoverflow.com/questions/22866901/using-java-with-nvidia-gpus-cuda
С остальным вообще не ясно что за проблемы, не рокет сайнс.

PM>·>На плюсах есть куски или нативные либы, но как-то постепенно перетекает всё в java. Ибо работает так же, а добавляется куча преимуществ (см ролик http://rsdn.ru/forum/philosophy/6205646.1
Автор: Evgeny.Panasyuk
Дата: 07.10.15
)

PM>·>Как в одно время был процесс переползания с ассемблеров на фортран, на С, на С++, теперь вот java. Конечно, на arduino яву не запустишь, но нишу LL она уверенно отвоёвывает.
PM>Да, да, "write once, run anywhere", Java завоюет мир... Когда-то читал про такое, лет 20 назад. По-моему ниша Java всё та же — корпоративные и банковские приложения. Может андроид слегка добавил, пока разработчики не выяснили, что писать мобильные приложения выгоднее с общим ядром на C++ и пользовательским интерфейсом под конкретную платформу.
Я и не утверждало всём мире. Мир не завоевала, но LL нишу занимает прочно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 20:53
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Ты вроде обещал, что будет дисциплина — проблемы не будет. Однако, чуда не вышло.


TB>Ты вроде обещал, что будет жаба — проблемы не будет. Однако, чуда не вышло.

Так в яве и нет проблемы битых указателей. Чудо, однако. А то что нативный код может поднасрать, это не аргумент. А ещё java кнопку reset не может запретить нажать, и что?

TB>Ещё раз: я не спорю с тем, что в крестах напортачить проще и требования к программистам выше. Ты сейчас типа пытаешься доказать мне, что жаба — серебрянная пуля?

Нет, что некоторые классы проблем решает.

TB>·>Что наличие ссылки на иммутабельный объект не даёт гарантии, что его поведение не поменяется.

TB>Я тупой, так что давай выкладывай все звенья логической цепи.
Меняешь чуток код и вдруг вылазишь за время жизни объекта. Упс, битый указатель.

TB>>>Расскажи, в жабошарпах можно ли кастовать мутабельный указатель в немутабельный?

TB>·>В смысле присвоить новое значение к final полю/переменной? Нет, конечно. Нельзя.
TB>Ааа, иммутабельный класс — это класс, в котором все поля final?
TB>Можно ли в С++ можно всем полям написать const? Нет, конечно. Нельзя. (Сарказм).
Можно, конечно. Но деструктор запретить-то нельзя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 08.10.15 21:03
Оценка:
Здравствуйте, ·, Вы писали:

·>Так в яве и нет проблемы битых указателей. Чудо, однако. А то что нативный код может поднасрать, это не аргумент. А ещё java кнопку reset не может запретить нажать, и что?


Ты путаешь С++ и чистую сишку. В С++ при правильном использовании тоже нет битых указателей.

·>Меняешь чуток код и вдруг вылазишь за время жизни объекта. Упс, битый указатель.


Как можно грохнуть объект, пока он ещё кем-то используется? По-моему, это косяк программиста куда более серьёзный, чем просто какой-то битый указатель.

·>Можно, конечно. Но деструктор запретить-то нельзя.


...но ГЦ и финализатор запретить нельзя...
(я хз, к чему это, просто разговор поддержать)
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 08.10.15 21:30
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Так в яве и нет проблемы битых указателей. Чудо, однако. А то что нативный код может поднасрать, это не аргумент. А ещё java кнопку reset не может запретить нажать, и что?

TB>Ты путаешь С++ и чистую сишку. В С++ при правильном использовании тоже нет битых указателей.
Тут в топике мне предлагают использовать голые указатели. Это правильное использование? А cyclic references тоже правильное?

TB>·>Меняешь чуток код и вдруг вылазишь за время жизни объекта. Упс, битый указатель.

TB>Как можно грохнуть объект, пока он ещё кем-то используется? По-моему, это косяк программиста куда более серьёзный, чем просто какой-то битый указатель.
В С++ — запросто. В java — никак.

TB>·>Можно, конечно. Но деструктор запретить-то нельзя.

TB>...но ГЦ и финализатор запретить нельзя...
TB>(я хз, к чему это, просто разговор поддержать)
Конечно нельзя. Но обратиться к объекту, попавшему ГЦ на растерзание — тоже нельзя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[33]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.15 21:49
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Врёшь же. Я конкретно сказал что контроль над временем ортогонален "как на Си".

I>>Это просто твоё мнение, ничем не аргументированое.

EP>Это аргумент. Ты можешь быть согласен с ним или нет.


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

EP>Задача была сделать подстраховку, я сказал что такая подстраховка не реализуема на C, ты сказал что "реализуема, только иначе"


У твоей подстраховки один побочный эффект — время выполнения может быть недетерминированым.

EP>То есть ты не понимаешь в чём тут отличие у C++11


Ты утомляешь передёргиваниями.

I>>Твоя "подстраховка", требует ресурсов. Каскадная очистка — часть этой самой подстраховки. Вместо явной логики "вычислить и освободить явно" выбираем неявную "пусть деструкторы срабатывают каскадом по цепочке, авось пронесёт"


EP>Ещё раз, эта каскадная очистка была бы и без ref-counting. Understand?


Я же сказал, что каскадная очистка это один из возможных вариантов реализации. Тебе её удобно делать деструкторами. Отсюда ясно, что хрен его знает, какое будет время работы.
Re[34]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 08.10.15 22:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

EP>>>>Врёшь же. Я конкретно сказал что контроль над временем ортогонален "как на Си".

I>>>Это просто твоё мнение, ничем не аргументированое.
EP>>Это аргумент. Ты можешь быть согласен с ним или нет.
I>А противоположная формулировка, хочешь ты или нет, тоже аргумент или как ?

А смысл просто так повторять противоположную формулировку? Скажи что не согласен потому-то и тому-то, или хотя бы попроси разъяснения — зачем кирпичом прикидываться?

I>А если она из одного слова, как отсылка к контексту ?

I>Опаньки !

На C можно писать как с "контролем над временем", так и без него — это ортогональное свойство. Точно также и для C++. Поэтому контроль над временем ортогонален "как на Си".
Вот есть бы сказал что "как на блаб", при этом блаб бы использовался исключительно для задач контролем над временем — был бы другой разговор.

EP>>Задача была сделать подстраховку, я сказал что такая подстраховка не реализуема на C, ты сказал что "реализуема, только иначе"

I>У твоей подстраховки один побочный эффект — время выполнения может быть недетерминированым.

Эта подстраховка никак не влияет на порядок вызова деструкторов, он остаётся таким же как было бы и без неё.

EP>>То есть ты не понимаешь в чём тут отличие у C++11

I>Ты утомляешь передёргиваниями.

Я причём тут передёргивание? Ты не понимаешь важный для дискуссии аспект. В C++11 есть нововведение позволяющее существенно снизить количество ref inc/dec.

I>>>Твоя "подстраховка", требует ресурсов. Каскадная очистка — часть этой самой подстраховки. Вместо явной логики "вычислить и освободить явно" выбираем неявную "пусть деструкторы срабатывают каскадом по цепочке, авось пронесёт"

EP>>Ещё раз, эта каскадная очистка была бы и без ref-counting. Understand?
I>Я же сказал, что каскадная очистка это один из возможных вариантов реализации. Тебе её удобно делать деструкторами. Отсюда ясно, что хрен его знает, какое будет время работы.

Нет, ты потерял контекст. Мы сейчас рассматриваем случай где использование ref-counting избыточно, то есть не продиктовано самой задачей, как в случае с разделяемым владением(а такие задачи сами по себе редки). В этом случае ref-counting никак не влияет на порядок вызова деструкторов.
Отредактировано 08.10.2015 22:21 Evgeny.Panasyuk . Предыдущая версия . Еще …
Отредактировано 08.10.2015 22:13 Evgeny.Panasyuk . Предыдущая версия .
Re[73]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 05:05
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

S> Еще раз нет навигационных свойств. А в них весь смысл. Еще раз нет сравнения эффективности на сложных запросах. Как ты можешь утверждать без тестов. Это уже религия.

Не, ну если для тебя весь смысл ORM в этих самых "навигационных свойствах", то что тут можно ещё сказать...

Что касается эффективности. Т.к. время исполнения запросов в БД не зависит от вида ORM, то есть смысл сравнивать только накладные расходы вокруг запроса. Для linq версий они были озвучены (я приводил ссылку), причём не мною, а как раз реальным специалистом по C#. Что же касается sqlpp11, то в принципе можно считать, что там эти накладные расходы равны нулю (если рассматривать относительно случая ручного задания sql строки).

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


Эээ что? ) Оптимизацией запросов занимается человек, а не ORM. Хотя бы потому, что ORM просто физически не может сделать никакую внятную оптимизацию, т.к. не знает особенностей конкретной БД.
Re[73]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 05:13
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

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

Самая распространённая задача где? ) К примеру в веб'е (а я думаю можно не уточнять, что эта область намного больше любых ERP и т.п.?) такое надо ещё постараться найти. А вот как раз статические запросы вида GetUserById, GetProductById и т.п. выглядывают из-за каждого угла.

S> Но опять когда эта скорость нужна? Для клиента то он её просто незаметит. А например для Asp.Net то если сильнозагруженный сервер по 1000 запросов в секунду, то тогда стоит заморочится на скорость. Но таких задач ооочень мало.


Ну вообще то эффективный код позволяет экономить деньги на железе в любом случае, вне зависимости от нагруженности сервера. Просто в случае небольшого трафика это будут копейки, которые не окупают повышенную зарплату соответствующих специалистов. А вот в случае популярных сервисов оказывается уже выгоднее платить им деньги, но сократить количество серверов.
Re[74]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 05:17
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

S>> Еще раз нет навигационных свойств. А в них весь смысл. Еще раз нет сравнения эффективности на сложных запросах. Как ты можешь утверждать без тестов. Это уже религия.

_>Не, ну если для тебя весь смысл ORM в этих самых "навигационных свойствах", то что тут можно ещё сказать...

Вот имено. Как то некорректно сравнивать ООП с процедурным программированием. Слышали не раз.

_>Что касается эффективности. Т.к. время исполнения запросов в БД не зависит от вида ORM, то есть смысл сравнивать только накладные расходы вокруг запроса. Для linq версий они были озвучены (я приводил ссылку), причём не мною, а как раз реальным специалистом по C#. Что же касается sqlpp11, то в принципе можно считать, что там эти накладные расходы равны нулю (если рассматривать относительно случая ручного задания sql строки).


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


_>Эээ что? ) Оптимизацией запросов занимается человек, а не ORM. Хотя бы потому, что ORM просто физически не может сделать никакую внятную оптимизацию, т.к. не знает особенностей конкретной БД.

Выдает то конечный текст SQL алгоритм. Причем для разных СУБД он будет свой. А сложность запросов бывает высокой, а не просто Select * From
и солнце б утром не вставало, когда бы не было меня
Re[74]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 05:31
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Вроде бы весь набор операций, нужный для работы с sql имеется. Причём в полном соответствие с linq синтаксисом (одним из двух вариантов). А что ещё надо для ORM? )

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

_>Самая распространённая задача где? ) К примеру в веб'е (а я думаю можно не уточнять, что эта область намного больше любых ERP и т.п.?) такое надо ещё постараться найти. А вот как раз статические запросы вида GetUserById, GetProductById и т.п. выглядывают из-за каждого угла.

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

S>> Но опять когда эта скорость нужна? Для клиента то он её просто незаметит. А например для Asp.Net то если сильнозагруженный сервер по 1000 запросов в секунду, то тогда стоит заморочится на скорость. Но таких задач ооочень мало.


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


Давай посчитаем. 1С справляется как минимум с сотней клиентов. При этом нагрузка на 1 SQL и 1 сервер приложений далека то 100 процентов.
Предприятий такого плана 80% как минимум. Мелкий и средний бизнесс
Сложность задач это миллионы строк. Один отчет может занимать десятки тысяч строк. И на 1С это может делать далеко не супер квалифицированный человек.
Если это делать на С++, то просто столько специалистов не найдется. При этом ЗП одного специалиста 1С сравнима с 1 сервером. Вот и считай, что выгодно.
Как правильно тут заметили, когда у тебя сотни и тысячи серверов то стоит задуматься и о скорости. Но понятно, что таких задач минимум, от реальных задач.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 09.10.2015 5:50 Serginio1 . Предыдущая версия .
Re[2]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 05:44
Оценка: +1
Здравствуйте, A13x, Вы писали:

A>Я делал замеры — эквивалентный С++ код часто сравним, а иногда очень сильно отстает от эквивалентного кода на java (оверхед для generic хипа) — см. тему.

A>Заранее оговорюсь — что в определенных задачах, конечно, С++ может показать сильный отрыв и по быстродействию и по потреблению памяти, хотя в прикладном программировании таких задач не так много.
A>В то же время jvm может выполнять оптимизации принципиально недоступные для при статической компиляции.

На самом деле как раз наоборот. Это задач требующих подсчёт ссылок (говоря C++ языком) в прикладном программирование не так много.

A>Для желающих проверить на практике — предлагаю желающим реализовать простейший интерпретатор нетипизированного лямбда исчисления на С++ (ну то есть REPL который бы понимал что-то вроде такого) и сравнить его быстродейтвие с тем, что можно реализовать на яве (мой вариант меньше 500 строк и по быстродействию уделывает известные мне интерпретаторы scheme). Насколько я себе представляю возможные реализации — на стресс тестах будет большое количество виртуальных вызовов и большое количество выделений памяти под мелкие объекты.

A>И да, согласен, что это тоже не типичная прикладная задача
A>Eсли лень реализовывать — достаточно сравнить эти два варианта: на С++ и на Java — приближенные к тому, что пришлось бы иметь в коде интерпретатора.

Ну вообще то Евгений же ещё в той темке показал решений на C++, обгоняющее данный Java код. Единственное что тут стоит отметить, это наличие уже в C++, а не Java коде низкоуровневых кусков (кастомных аллокаторов) ради оптимизации. Ну так на то оно и редкая задачка.

Но в любом случае хочу поприветствовать это твоё выступление в данном обсуждение. Потому что это кажется первое и пока единственное реально аргументированное выступление на тему преимуществ управляемых языков.
Re[23]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 05:52
Оценка:
Здравствуйте, ·, Вы писали:

_>>С чего это ты взял, что не могу? ) Да, и ты снова привёл не конкретный пример, а абстрактные рассуждения. Давай конкретную задачку и посмотрим могу или нет... )))

·>Сможешь, конечно. Можно всё и на brainfuck написать, вопрос в том, что проще и на чём будет проще убедиться в работоспособности решения.

ОК, давай кроме факта возможности написания такого кода потребуем ещё и оценки его краткости, красоты и т.п. Ну так где пример задачки? )

_>>·>CAS, volatile, happens-before.

_>>Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.
·>Полная загрузка процессора в low latency как раз частенько используется — для того, чтобы операционка не вздумала вытеснить критичный тред. Ещё этот тред к одному ядру привязывается.

Это подходит только для простенькой задачки, в которой она единственная на системе и при этом сами вычисления не тяжёлые. Для более сложных случаев (например обработке видео в реальном времени) такие фокусы только помешают.
Re[21]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 06:00
Оценка:
Здравствуйте, ·, Вы писали:

EP>>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.

·>Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.

Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.
Re[27]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 06:01
Оценка:
Здравствуйте, ·, Вы писали:

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


А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?
Re[75]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 06:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Самая распространённая задача где? ) К примеру в веб'е (а я думаю можно не уточнять, что эта область намного больше любых ERP и т.п.?) такое надо ещё постараться найти. А вот как раз статические запросы вида GetUserById, GetProductById и т.п. выглядывают из-за каждого угла.

S> И в вэбе. Клиенту нужно получить данные о его заказах в разрезе заказа, заказов его покупателей, товаров привязанных к заказу без заказа, только готовые заказы итд.
S>Например 1С это тоже Вэб клиент. А таких отчетов почти каждый. У тебя просто опыта нет.

В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.

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

S> Давай посчитаем. 1С справляется как минимум с сотней клиентов. При этом нагрузка на 1 SQL и 1 сервер приложений далека то 100 процентов.
S>Предприятий такого плана 80% как минимум. Мелкий и средний бизнесс

Эээээ, как вообще можно указывать подобные цифры без точного описания железа? ) Как бы Atom с 1 GB RAM и 18-и ядерный Xeon с 256 GB RAM дают очень разную производительность и стоят очень разные деньги...

S>Сложность задач это миллионы строк. Один отчет может занимать десятки тысяч строк. И на 1С это может делать далеко не супер квалифицированный человек.

S>Если это делать на С++, то просто столько специалистов не найдется. При этом ЗП одного специалиста 1С сравнима с 1 сервером. Вот и считай, что выгодно.
S>Как правильно тут заметили, когда у тебя сотни и тысячи серверов то стоит задуматься и о скорости. Но понятно, что таких задач минимум, от реальных задач.

А что, тут кто-то предлагал писать бухгалтерские отчёты на C++? Естественно такое пишут на скриптовых языках (где-то это свой язык, как в 1C или SAP, а где-то и обычный, типа Python/JS) соответствующей платформы. А вот саму платформу пишут уже на C++, ну если конечно хочется хоть какого-то быстродействия. )))
Re[76]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 07:17
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Самая распространённая задача где? ) К примеру в веб'е (а я думаю можно не уточнять, что эта область намного больше любых ERP и т.п.?) такое надо ещё постараться найти. А вот как раз статические запросы вида GetUserById, GetProductById и т.п. выглядывают из-за каждого угла.

S>> И в вэбе. Клиенту нужно получить данные о его заказах в разрезе заказа, заказов его покупателей, товаров привязанных к заказу без заказа, только готовые заказы итд.
S>>Например 1С это тоже Вэб клиент. А таких отчетов почти каждый. У тебя просто опыта нет.

_>В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.

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

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

S>> Давай посчитаем. 1С справляется как минимум с сотней клиентов. При этом нагрузка на 1 SQL и 1 сервер приложений далека то 100 процентов.
S>>Предприятий такого плана 80% как минимум. Мелкий и средний бизнесс

_>Эээээ, как вообще можно указывать подобные цифры без точного описания железа? ) Как бы Atom с 1 GB RAM и 18-и ядерный Xeon с 256 GB RAM дают очень разную производительность и стоят очень разные деньги...

Ну я озвучил стоимость сервера равной ЗП программиста. Так что выбирай из этих условий.

S>>Сложность задач это миллионы строк. Один отчет может занимать десятки тысяч строк. И на 1С это может делать далеко не супер квалифицированный человек.

S>>Если это делать на С++, то просто столько специалистов не найдется. При этом ЗП одного специалиста 1С сравнима с 1 сервером. Вот и считай, что выгодно.
S>>Как правильно тут заметили, когда у тебя сотни и тысячи серверов то стоит задуматься и о скорости. Но понятно, что таких задач минимум, от реальных задач.

_>А что, тут кто-то предлагал писать бухгалтерские отчёты на C++? Естественно такое пишут на скриптовых языках (где-то это свой язык, как в 1C или SAP, а где-то и обычный, типа Python/JS) соответствующей платформы. А вот саму платформу пишут уже на C++, ну если конечно хочется хоть какого-то быстродействия. )))


Мы говорим о производительности. Так производительности скриптовых языков хватает в большинстве задач. А скорость .Net намного выше при этом дает динамическую типизацию через dynamic. Очень удобно при работе с неопределенными типами.
http://habrahabr.ru/post/144330/
и солнце б утром не вставало, когда бы не было меня
Отредактировано 09.10.2015 8:03 Serginio1 . Предыдущая версия .
Re[33]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 09.10.15 07:22
Оценка:
Здравствуйте, ·, Вы писали:

·>Тут в топике мне предлагают использовать голые указатели. Это правильное использование? А cyclic references тоже правильное?

Если ты знаешь хозяина (unique_ptr) и его время жизни — то да.

TB>>·>Меняешь чуток код и вдруг вылазишь за время жизни объекта. Упс, битый указатель.

TB>>Как можно грохнуть объект, пока он ещё кем-то используется? По-моему, это косяк программиста куда более серьёзный, чем просто какой-то битый указатель.
·>В С++ — запросто. В java — никак.
Как страшно жить!

TB>>·>Можно, конечно. Но деструктор запретить-то нельзя.

TB>>...но ГЦ и финализатор запретить нельзя...
TB>>(я хз, к чему это, просто разговор поддержать)
·>Конечно нельзя. Но обратиться к объекту, попавшему ГЦ на растерзание — тоже нельзя.
И обратиться к объекту, который уничтожается — тоже нельзя, если программист понимает, что он делает. Если не понимает — то и жаба не поможет. В целом в С++ напортачить проще, из-за чего он и не стал популярнее жабы.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[27]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 08:07
Оценка:
Здравствуйте, ·, Вы писали:

I>>Есть куча проектов, которые загнулись из за того, что так и не смогли сбороть этот GC.

·>А конкретнее? Ни одного С++ проекта не загнулась из-за сложности кода?

Джава приходит в реалтайм, трейдинг и тд и тд с большим опозданием. Во многих областях джавы и близко нет.
Собтсвенно, пытаются писать много, но взлетает далеко не все. Там где не взлетела джава, как правило уже лет 10 и больше С++ в полный рост.

I>> Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.

·>Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.

Это заблуждение. У тебя практически вся архитектура приложения нацелена на минимизацию проблем с GC. Ты или забыл про это, или еще не понял.
Re[35]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 08:13
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>>>Это просто твоё мнение, ничем не аргументированое.

EP>>>Это аргумент. Ты можешь быть согласен с ним или нет.
I>>А противоположная формулировка, хочешь ты или нет, тоже аргумент или как ?

EP>А смысл просто так повторять противоположную формулировку? Скажи что не согласен потому-то и тому-то, или хотя бы попроси разъяснения — зачем кирпичом прикидываться?


Начни с себя. Ты ведь начал голословно вещать, что всё де миф и тд и тд.

EP>На C можно писать как с "контролем над временем", так и без него — это ортогональное свойство. Точно также и для C++. Поэтому контроль над временем ортогонален "как на Си".

EP>Вот есть бы сказал что "как на блаб", при этом блаб бы использовался исключительно для задач контролем над временем — был бы другой разговор.

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

I>>У твоей подстраховки один побочный эффект — время выполнения может быть недетерминированым.

EP>Эта подстраховка никак не влияет на порядок вызова деструкторов, он остаётся таким же как было бы и без неё.

Я про количество и глубину, а не порядок вызова.
EP>Я причём тут передёргивание? Ты не понимаешь важный для дискуссии аспект. В C++11 есть нововведение позволяющее существенно снизить количество ref inc/dec.

Киев, дядька, бузина.

I>>Я же сказал, что каскадная очистка это один из возможных вариантов реализации. Тебе её удобно делать деструкторами. Отсюда ясно, что хрен его знает, какое будет время работы.


EP>Нет, ты потерял контекст. Мы сейчас рассматриваем случай где использование ref-counting избыточно, то есть не продиктовано самой задачей, как в случае с разделяемым владением(а такие задачи сами по себе редки). В этом случае ref-counting никак не влияет на порядок вызова деструкторов.


Это ты хочешь понамекать, что якобы единтсвенная проблема это инкремент-декремент относительно общей массы. Я говорю совсем про другое.
Re[34]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 08:15
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>>>·>Можно, конечно. Но деструктор запретить-то нельзя.

TB>>>...но ГЦ и финализатор запретить нельзя...
TB>>>(я хз, к чему это, просто разговор поддержать)
TB>·>Конечно нельзя. Но обратиться к объекту, попавшему ГЦ на растерзание — тоже нельзя.
TB>И обратиться к объекту, который уничтожается — тоже нельзя, если программист понимает, что он делает. Если не понимает — то и жаба не поможет. В целом в С++ напортачить проще, из-за чего он и не стал популярнее жабы.

С++ не то что не стал популярнее Джавы, он лет 20 как утратил доминирование. В свое время С++ именно доминировал в разработке. С тех пор управляемые решения выдавили С++ в низкоуровневый функционал.
Re[22]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 08:17
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.


Главное помнить о том, что нативные и управляемые решения за последние 20 лет практически поменялись местами, если смотреть долю рынка.
Re[76]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 08:21
Оценка:
Здравствуйте, alex_public, Вы писали:



_>В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.


Какая разница какой. Он есть и в большинстве скорости хватает. Вот сравнение с C#
http://www.forum.mista.ru/topic.php?id=704876#4

Получается примерно такая картина:

1) Если делать вызов пустого метода 1С-веб-сервиса (содержит только возврат строкового параметра), первый вызов отрабатывает около 1-3 секунд, последующие вызовы отрабатывают примерно 25-60 раз в секунду (с самого сервера, что логично, быстрее, с других машин медленнее). Т.е. пул работает.
2) Если такие вызовы запустить параллельно, то скорость каждого вызова падает незначительно, т.е. опять таки, похоже пул работает.
3) Но вот если сравнивать с аналогичным веб-сервисом на С#, расположенном на том же железе, сравнение сильно не в пользу 1С. Разница составляет от 8-10 и более (минимальное количество вызовов у этого сервиса — 250).

Грустно как-то. Может есть идеи, где затык? Или безнадежно, и лучшего чем 25-60 вызовов от 1С не получить?


И это просто пустого метода. Правда в 1С к каждому подключению идет инициализация юзера, но в этом тесте на пустой конфигурации. В Net это решается через токены авторизации, кэшировании клиента на сервере итд.
То есть в самом простом случае это 8-10 раз без вызова кода.
При этом сложность написания кода на C# не намного выше. Правда и возможностей выше. А вот скорость написания может быть даже выше за счт интеллисенсе и статическая проверка кода. Например многие используют TS вместо голого JS.
и солнце б утром не вставало, когда бы не было меня
Re[14]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 08:27
Оценка:
Здравствуйте, PM, Вы писали:

PM>Да, да, "write once, run anywhere", Java завоюет мир... Когда-то читал про такое, лет 20 назад. По-моему ниша Java всё та же — корпоративные и банковские приложения. Может андроид слегка добавил, пока разработчики не выяснили, что писать мобильные приложения выгоднее с общим ядром на C++ и пользовательским интерфейсом под конкретную платформу.


Идея "write once, run anywhere" здохла. Тем не менее Джава с тех пор внятно пролезла и в микроконтроллеры, HPC, HFT, реалтайм, операционные системы, бортовая электроника и много куда еще.
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 09:12
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>>>Пусть просто поставит в очередь, делов-то

dot>>>>Поставит что? Сразу весь развесистый граф? А если надо только часть освободить? Ставить каждый самый мелкий объект? А очереди не поплохеет?
EP>>>Не каждый объект, а те которые не успеваем освободить.
dot>>А как мы будем выяснять — успеем или не успеем?
EP>Замерами — например смотрим максимальное/среднее/etc время очистки одного узла. Причём тот же finalize есть и Java.
EP>Если же речь идёт о hard real time — то там применяются совершенно другие приёмы.
Как эти замеры производить? Куда их вставлять? Как это повлияет на latency?

dot>>>>В low latency единственный ресурс обычно память.

EP>>>Сильное утверждение. Да и это проблема ко всему относится, а не только к low latency.
dot>>Что-то не понял. Которая проблема?
EP>Задача работы с ресурсами.
А почему ты эту задачу привёл? К чему всё это? Управление ресурсами (кроме памяти) ничем не отличается между C++ и Java.

dot>>>>>>А для ресурсов в общем случае — наследники java.lang.ref.Reference.

EP>>>>>Каким образом они обеспечат prompt finalization?
dot>>>>А надо?
EP>>>Надо, это задача.
dot>>Какая именно задача? Ты не путаешь задачу со способом решения?
EP>Задача — своевременное освобождение ресурсов.
Т.е. приходит к тебе клиент, кладёт на стол пачку денег и говорит: "Я бизнесмен, занимаюсь освобождением ресурсов. Напиши мне программу, которая это будет делать своевременно". А отдел маркетинга рисует очередной баннер: "Мы освобождаем ресурсы дёшево и своевременно!". Я правильно понимаю?

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

Ресурсы отдельно, логика отдельно. Зачем агрегировать? В С++ — да, никуда не денешься, т.к. память — ресурс.

EP>>>Ту же самую, с потоками, при завершении последнего нужно освободить ресурс.

dot>>Эээ.. Попробую сформулировать. Открыть файл, раздать открытый файл пачке тредов, которые могут так же кидаться файлами с другими тредами и закрыть, когда последний тред его обработает. Так? Собственно решение будет аналогично С++, взять какой-нибудь подходящий класс из java.lang.concurrent.* и реализовать контроль пользователей ресурса.
EP>Как именно? Как ресурс будет передаваться в потоки? Кто и как будет решать что нужно удалить?
Представь решение на С++ и, скорее всего, в Java получится примерно так же.

dot>>Ещё раз, в java есть только один специально обрабатываемый ресурс — память. Не надо натягивать gc на контроль любых ресурсов, он только для памяти.

EP>А я не натягиваю. Я предлагаю тебе решить, или хотя бы описать решение любым способом.
Дай конкретную задачу, дам конкретное решение.

dot>>Я понимаю откуда растёт это заблуждение. Деструктор в С++ может быть использован как для памяти, так и для любых других ресурсов. Не надо переносить это понимание в java. В java gc — только для памяти. Другие ресурсы — с помощью try-with-resources контролируются.

EP>Про заблуждение это ты придумал. Я прекрасно знаю об этих всех костылях а-ля with/using/try-with-resources.
А зачем вообще эти ресурсы приплёл? Вроде о памяти разговаривали, и вдруг ресурсы вылезли.

EP>>>Потому что lock'и это не lockfree, принципиально. Смотри определение. Lockfree это прежде всего некоторые гарантии, а не например скорость — скорость вообще может быть меньше.

EP>>>Да и кто сказал что время предсказуемо? Например GC заснул захватив lock, остальные ждут. Тут желательно хотя бы obstruction free
dot>>lockfree это гарантии на уровне кода, а что там делает окружение — не важно. Скажем, если операционка вытесняет твой поток — по сути она лочит его — исполнение приостанавливается. А ещё и CPU может заснуть, скажем для экономии энергии или для регуляции тепловыделения. И что? lockfree и на C++ невозможен?
EP>Прочитай определение lock-free.
Вооот. Хорошо, но уже лучше. А теперь перечисли, какие из гарантии lock-free нарушаются при наличии gc?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 09:51
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>И не в покер, а в преферанс. И не выиграл, а проиграл.

EP>>>И не ссылку, а сам объект. И не unique_ptr, а просто стэковый объект.
dot>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.
EP>То есть имелось в виду scoped_ptr — более ограниченная версия unique_ptr. Например unique_ptr можно возвращать из функции.
EA работает и с множеством функций. Сделай "byte[] func() {return new byte[100500];}"- ничего страшного.

EP> vector<Widget> values(N);

И молись что N не слишком большой и не получится stack overflow на пустом месте.

dot>>массив не убегает за пределы, то при выходе из стека объект грохнется

EP>Каким образом грохнется? Речь только про некомпактифицируемые кучи?
Самое тривиальное — копирующим GC.

EP>>>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика

EP>>>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.
dot>>Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются.
EP>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть.
Железом нам даны адреса, а не указатели.

EP>>>Упёрлись в потолок, GC начинает очень долго освобождать за O(N), отбирая ресурсы у других потоков, общая пропускная способность снижается (забиты каналы памяти, и аллокации происходят медленней), извне приходят всё новые задачи для которых в свою очередь нужна всё новая память, в конце концов либо OOM либо DoS.

dot>>Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java.
EP>Не грохнется — у него нет зависимости O(N) от количества живых объектов.
new/malloc и delete/free работают не за O(1) внезапно.
Если у тебя gc работает в режиме, что у него есть зависимость O(N) (т.е. худший случай), то ты делаешь что-то не то. Как известно, gc работает хорошо при короткоживущих и длинноживущих объектах. А проверяет он по грязным регионам, а не по всем живым.
Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.

EP>>>Такой Array и другие контейнеры нужно делать для каждого типа данных. У тебя будут FooArray, BarArray, FooPriorityQueue, BarPriorityQueue и т.д.

EP>>>Либо как вариант добавлять лишней динамичности, но от неё будут свои тормоза, причём как размеры заранее не известны.
dot>>В LL не так уж и много разных структур.
EP>Ты постоянно говоришь о каком-то одном use-case'ы.
EP>Даже если и мало — всё равно придётся опускаться на очень низкий уровень, исключительно из-за самого языка.
Я и не изобретаю общую теорию всего, а решаю практические задачи.

dot>>И, как и в С++, и, скорее, всего будут поверх array.

EP>Это ты о чём?
EP>Например на C++ есть выгода от структур (в смысле хранения по значению) даже для вещей типа сбалансированных деревьев — так как уменьшает количество индерекций — само значение хранится в узле, а не указатель на значение.
Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему. Данные и их хранение те же, а алгоритмы — варьируй в методах классов (хотя почему-то ты решил отменить классы).
Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.

dot>>>>Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет.

EP>>>Это одна из главных причин тормозов в языках с превалирующей pointer semantics. Положил класс с несколькими полями-объектами в массив — уже на ровном месте выросло целое дерево индерекций и аллокаций.
dot>>В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это.
EP>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры
by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.

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

EP>>>Да и это же Array of Structures, нужно не так часто. Речь же про то, что в Java же нет самых обычных структур — для быстрого кода это супер-критично, именно поэтому и нарезают вручную.
dot>>Критически быстрого кода не так много. А значит "нужно не так часто".
EP>Мы же быстрый код обсуждаем?
Быстрый hello world никому не нужен. Нужна большая и сложная система с быстрыми частями.

EP>>>Хуже, намного. Разве пример со структурами тебя не убедил? — это реально уровень ниже чем C, на ровном месте. Так это только один аспект.

EP>>>Быстрый код на C++ можно писать на высоком уровне абстракции — не нужно отказываться ни от замыканий, ни от классов, ни от ФВП и полиморфизма — и при этом он будет давать точно такое же (либо практически такое же) быстродействие как и такой же код написанный на низком уровне вручную — в этом одна из главных фишек C++.
dot>>Тут не фичи и уровни абстракции, а хранение и передача данных главное. И там и там об этом надо заботиться. В Яве — не создавать лишних индирекций, в плюса — не делать лишних копий и аккуратно заботиться о владении. Ведь тоже ничего хорошего в том, когда все эти уровни абстракции только и делают, что решают проблемы владения, тогда как в яве оно само, из коробки.
EP>Это уже передёргивание. Да, работу с памятью GC упрощают (при этом не гарантируя отсутствие утечек).
Зато гарантируется отсутствие битых ссыслок.

EP>Да, на C++ нужно думать/помнить о владении (это не означает что каждый new на Java превращается в *_ptr).

EP>Нет, уровни абстракции о которых я говорю решают далеко не только проблемы владения — они позволяют писать высокоуровневый И быстрый код.
Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.
Выразительность языка с другой стороны стреляет отстутсвием нормальной IDE.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 10:27
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Причём это происходит по вине самого GC.

dot>>Ну подкрути параметры чуток, не проблема.
EP>Это уберёт линейную сложность?
Да. Линейная сложность это худший случай, когда у тебя постоянно меняются указатели в большинтсве живых объектов и постоянно создаются новые. В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.

dot>>>>Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах?

EP>>>Нет линейной зависимости времени очистки от количества живых объектов. В случае же GC, на одной и той же скорости входящего потока он может либо успевать очищать, либо нет — и это сильно зависит от текущего количества живых объектов.
dot>>Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы.
EP>В очереди объекты которые уже готовы для очистки. А вот сколько там живых reachable объектов — не важно, пусть хоть десять миллиардов.
Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь, обрабатываемую одним несчастным потоком?

EP>>>Зачем?

dot>>Определить граф-остаток.
EP>Зачем его определять? Что это даст?
EP>Пока не превысим бюджет времени — удаляем сами, как только времени осталось меньше чем требует max объект — ставим остаток в очередь.
Так как мы конкретно будем этот бюджет считать?

EP>>>Очередь может быть thread local.

dot>>И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос.
EP>От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC.
Мы вроде рассматриваем случай, когда sharedPtr.release может начаться из разных тредов. Как ты собираешься использовать single writer структуру?

dot>>Это тоже подзадача GC — решать сразу или отложить.

EP>А ещё в подзадачах GC есть сложение целых.
Хорошо, не подзадача, а средство достижения заявленных характеристик.

EP>>>Разница в том, что написанная библиотека используется внутри самого host-языка. То есть эти gc_ptr — они используется не внутри какой-то виртуальной среды созданной библиотекой, а внутри вызывающего host-языка.

dot>>Так и деструкторы и прочие С++ фишки можно реализовать в java,
EP>Каким образом ты реализуешь деструкторы? Какое будет использование? Каким образом реализуешь например Expression Templates и прочие compile-time EDSL?
А зачем compile time? Я знаю, что C++ compile time — Turing Complete, но в общем-то и в Java можно сделать плугин для компилятора или load-time кодогенерацию.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 10:31
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Если применять CAS не по делу (исключительно в специально предназначенных для этого алгоритмах), а везде вместо локов, то результат будет только ещё намного хуже чем с локами, т.к. в таком случае всё равно будет нечто типа лока, только при этом с полной загрузкой процессора.

_>·>Полная загрузка процессора в low latency как раз частенько используется — для того, чтобы операционка не вздумала вытеснить критичный тред. Ещё этот тред к одному ядру привязывается.
_>Это подходит только для простенькой задачки, в которой она единственная на системе и при этом сами вычисления не тяжёлые. Для более сложных случаев (например обработке видео в реальном времени) такие фокусы только помешают.
Я говорил о low latency/finance, а ты тут "обработка видео" — вообще из другой области. Обрабатывать видео с явой я и не собирался. Такие софистические фокусы только мешают.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 10:34
Оценка:
Здравствуйте, alex_public, Вы писали:

EP>>>Понимать как работает железо обязательно нужно. Также нужно понимать как отображаются конструкции языка в железо — и вот с этим у Java проблемы, для быстрого кода приходится отказываться даже от элементарных абстракций и городить low-level код, который даже ниже уровень чем то что есть в языке C.

_>·>Да нет каких-то сверх-проблем. Да, нужно писать код определённым образом, реализовывать определённые решения, но это верно для любого оптимизируемого кода на любом языке. Java в этом плане ничуть ни лучше, ничуть не хуже, чем C++.
_>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.
Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.
В java есть JNI, unsafe режим — издевательство какое-то.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[15]: Java vs C# vs C++
От: PM  
Дата: 09.10.15 10:42
Оценка: +1
Здравствуйте, ·, Вы писали:

PM>>>>>> Короче, сплошной <троллейбус из буханки хлеба.jpeg>

PM>>·>Война была, да и до сих пор ведётся не с java, а с архитектурой и железом. 90% тех решений подходит и для С++.
PM>>Только цена усилий по улучшению быстродействия в проекте на C++ гораздо меньше.
·>Не правда.

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

PM>> Понадобилось попадание в кэш-линию и исключение false sharing — выровняли структуру. Не нужно переключение контекста — привязали поток к конкретному ядру.

PM>> SIMD, вычисления на GPU, сетевой стек в user space. В Java с этим будут трудности. И героически преодолевать их — см. выделенное.
·>И что из этого невозможно сделать ява?

Я разве где-то утверждал что это невозможно? Возможно, ведь в Java есть JNI, а в C# есть unsafe. Но если требуется писать unsafe class Program { static main() {...} } или значительная часть кода будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.

·>А какие именно трудности? Можно по пунктам?

·>SIMD инструкции генерятся JIT (хотя интересно услышать о их полезности в low latency/finance).
·>сетевой стек — это этот что-ли? http://docs.oracle.com/javase/tutorial/sdp/sockets/
·>GPU — тоже непонятна полезность, да и тоже куча всего http://stackoverflow.com/questions/22866901/using-java-with-nvidia-gpus-cuda
·>С остальным вообще не ясно что за проблемы, не рокет сайнс.

Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/

·>Я и не утверждало всём мире. Мир не завоевала, но LL нишу занимает прочно.


Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.
Re[15]: Java vs C# vs C++
От: PM  
Дата: 09.10.15 11:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PM>>Да, да, "write once, run anywhere", Java завоюет мир... Когда-то читал про такое, лет 20 назад. По-моему ниша Java всё та же — корпоративные и банковские приложения. Может андроид слегка добавил, пока разработчики не выяснили, что писать мобильные приложения выгоднее с общим ядром на C++ и пользовательским интерфейсом под конкретную платформу.


I>Идея "write once, run anywhere" здохла. Тем не менее Джава с тех пор внятно пролезла и в микроконтроллеры, HPC, HFT, реалтайм, операционные системы, бортовая электроника и много куда еще.


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

Так что вас конечно же не затруднит привести список реальных продуктов где еще кроме энтерпрайза сейчас используется Java. Только, пожалуйста, без JME, фантомОс, кофеварок со встроенным Oak.
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 11:15
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).

_>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?
Что иммутабельный объект после вызова деструктора меняет своё состояние.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 11:19
Оценка:
Здравствуйте, T4r4sB, Вы писали:

TB>·>Тут в топике мне предлагают использовать голые указатели. Это правильное использование? А cyclic references тоже правильное?

TB>Если ты знаешь хозяина (unique_ptr) и его время жизни — то да.
Как это знание выразить в коде?

TB>>>Как можно грохнуть объект, пока он ещё кем-то используется? По-моему, это косяк программиста куда более серьёзный, чем просто какой-то битый указатель.

TB>·>В С++ — запросто. В java — никак.
TB>Как страшно жить!
А кто обещал, что будет легко...

TB>>>(я хз, к чему это, просто разговор поддержать)

TB>·>Конечно нельзя. Но обратиться к объекту, попавшему ГЦ на растерзание — тоже нельзя.
TB>И обратиться к объекту, который уничтожается — тоже нельзя, если программист понимает, что он делает.
TB>Если не понимает — то и жаба не поможет.
В смысле не поможет? Язык не позволяет обращаться к объекту, который уничтожается, без всяких "если".

TB> В целом в С++ напортачить проще, из-за чего он и не стал популярнее жабы.

Точнее он стал менее популярным, чем жаба.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 11:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Есть куча проектов, которые загнулись из за того, что так и не смогли сбороть этот GC.

I>·>А конкретнее? Ни одного С++ проекта не загнулась из-за сложности кода?
I>Джава приходит в реалтайм, трейдинг и тд и тд с большим опозданием. Во многих областях джавы и близко нет.
I>Собтсвенно, пытаются писать много, но взлетает далеко не все. Там где не взлетела джава, как правило уже лет 10 и больше С++ в полный рост.
А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.

I>>> Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.

I>·>Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.
I>Это заблуждение. У тебя практически вся архитектура приложения нацелена на минимизацию проблем с GC. Ты или забыл про это, или еще не понял.
Заблуждаешься.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[35]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 09.10.15 11:24
Оценка:
Здравствуйте, ·, Вы писали:

·>Как это знание выразить в коде?

Ну типа тим-лид с линейкой чтоб ходил и по пальцам бил XD

·>А кто обещал, что будет легко...

Дык никто и не обещал, о чём спор-то?

·>В смысле не поможет? Язык не позволяет обращаться к объекту, который уничтожается, без всяких "если".

Ты упёрся лишь в одну проблему. В С++ она вполне решается при правильной организации. Вопрос лишь в цене этой организации. Из-за этого где-то один язык предпочтительнее, где-то другой.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[16]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 11:44
Оценка:
Здравствуйте, PM, Вы писали:

PM>>>Только цена усилий по улучшению быстродействия в проекте на C++ гораздо меньше.

PM>·>Не правда.
PM>Ваше утверждение не выглядит убедительно. В этой и похожих темах уже показывалось, как код на Java превращается в нечитаемую тыкву в попытках оптимизации. В то время как C++ код остается на том же уровне абстракции не теряя общности.
Дело вкуса, а не усилий. Простота языка Явы позволяет писать "нечитаемые тыквы" только там где надо. По сравнению с Явой, практически весь сишный код выглядит как нечитаемая тыква.

PM>>> Понадобилось попадание в кэш-линию и исключение false sharing — выровняли структуру. Не нужно переключение контекста — привязали поток к конкретному ядру.

PM>>> SIMD, вычисления на GPU, сетевой стек в user space. В Java с этим будут трудности. И героически преодолевать их — см. выделенное.
PM>·>И что из этого невозможно сделать ява?
PM>Я разве где-то утверждал что это невозможно? Возможно, ведь в Java есть JNI, а в C# есть unsafe. Но если требуется писать unsafe class Program { static main() {...} } или значительная часть кода будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.
Ты пишешь будут трудности больше, чем в плюсах. Это неверно, ибо большинство упомянутых трудностей к языку не относятся. Единственное существенное отличие — это наличие GC, да, в каких-то случаях он создаёт проблемы, но в других случаях он значительно упрощает решение других проблем.

PM>·>А какие именно трудности? Можно по пунктам?

PM>·>SIMD инструкции генерятся JIT (хотя интересно услышать о их полезности в low latency/finance).
PM>·>сетевой стек — это этот что-ли? http://docs.oracle.com/javase/tutorial/sdp/sockets/
PM>·>GPU — тоже непонятна полезность, да и тоже куча всего http://stackoverflow.com/questions/22866901/using-java-with-nvidia-gpus-cuda
PM>·>С остальным вообще не ясно что за проблемы, не рокет сайнс.
PM>Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/
Не понял. И причём тут java vs C++?

PM>·>Я и не утверждало всём мире. Мир не завоевала, но LL нишу занимает прочно.

PM>Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.
Там совсем другие требования, всё гораздо проще, какой же это LL. С играми вообще всё пофиг — сломалось, так сломалось, да и большинство там вообще сейчас 99% LUA и прочий скриптинг. Видео|аудио — фигня, не нужны миллисекунды отклика для 99.99% и потеря пакетов не смертельна. Это всё high throughput и параллелизация.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[77]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 11:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Эээээ, как вообще можно указывать подобные цифры без точного описания железа? ) Как бы Atom с 1 GB RAM и 18-и ядерный Xeon с 256 GB RAM дают очень разную производительность и стоят очень разные деньги...

S> Ну я озвучил стоимость сервера равной ЗП программиста. Так что выбирай из этих условий.

Что за зарплата? За неделю, за месяц или за год? )

И кстати говоря, в вебе чаще арендуют сервера в дата-центрах, а не покупают свои.

_>>А что, тут кто-то предлагал писать бухгалтерские отчёты на C++? Естественно такое пишут на скриптовых языках (где-то это свой язык, как в 1C или SAP, а где-то и обычный, типа Python/JS) соответствующей платформы. А вот саму платформу пишут уже на C++, ну если конечно хочется хоть какого-то быстродействия. )))

S> Мы говорим о производительности. Так производительности скриптовых языков хватает в большинстве задач. А скорость .Net намного выше при этом дает динамическую типизацию через dynamic. Очень удобно при работе с неопределенными типами.
S>http://habrahabr.ru/post/144330/

Что-то я не понял про что ты конкретно говоришь. Вот у тебя сейчас есть нормальная работающая система: быстродействующая платформа (написанная на C++) и скриптовой язык в ней, для кастомизации на месте. Куда конкретно в этой схеме ты хочешь всунуть .net? )
Re[23]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 11:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.

I>Главное помнить о том, что нативные и управляемые решения за последние 20 лет практически поменялись местами, если смотреть долю рынка.

Если под управляемыми ты имеешь в виду в том числе и все скриптовые, то да, есть такое дело. Просто вследствие развития ниши для этих языков. Ну и кстати говоря они в большинстве случаев не заменяют, а дополняют (работают кастомизаторами) нативный код.
Re[77]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 11:51
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.

S>Какая разница какой. Он есть и в большинстве скорости хватает. Вот сравнение с C#
S>http://www.forum.mista.ru/topic.php?id=704876#4
S> И это просто пустого метода. Правда в 1С к каждому подключению идет инициализация юзера, но в этом тесте на пустой конфигурации. В Net это решается через токены авторизации, кэшировании клиента на сервере итд.
S> То есть в самом простом случае это 8-10 раз без вызова кода.
S>При этом сложность написания кода на C# не намного выше. Правда и возможностей выше. А вот скорость написания может быть даже выше за счт интеллисенсе и статическая проверка кода. Например многие используют TS вместо голого JS.

Редкостная бредятина. Как можно сравнивать законченный продукт (типа 1C) и голый язык. Вот пускай такие сравниватели в начале напишут на C# полноценный аналог 1C со всеми его возможностями, а потом уже проводят сравнения быстродействия.
Re[25]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 11:58
Оценка: +1
Здравствуйте, ·, Вы писали:

EP>> vector<Widget> values(N);

·>И молись что N не слишком большой и не получится stack overflow на пустом месте.

Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
Re[78]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 12:00
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Эээээ, как вообще можно указывать подобные цифры без точного описания железа? ) Как бы Atom с 1 GB RAM и 18-и ядерный Xeon с 256 GB RAM дают очень разную производительность и стоят очень разные деньги...

S>> Ну я озвучил стоимость сервера равной ЗП программиста. Так что выбирай из этих условий.

_>Что за зарплата? За неделю, за месяц или за год? )

Месяц.
_>И кстати говоря, в вебе чаще арендуют сервера в дата-центрах, а не покупают свои.

_>>>А что, тут кто-то предлагал писать бухгалтерские отчёты на C++? Естественно такое пишут на скриптовых языках (где-то это свой язык, как в 1C или SAP, а где-то и обычный, типа Python/JS) соответствующей платформы. А вот саму платформу пишут уже на C++, ну если конечно хочется хоть какого-то быстродействия. )))

S>> Мы говорим о производительности. Так производительности скриптовых языков хватает в большинстве задач. А скорость .Net намного выше при этом дает динамическую типизацию через dynamic. Очень удобно при работе с неопределенными типами.
S>>http://habrahabr.ru/post/144330/

_>Что-то я не понял про что ты конкретно говоришь. Вот у тебя сейчас есть нормальная работающая система: быстродействующая платформа (написанная на C++) и скриптовой язык в ней, для кастомизации на месте. Куда конкретно в этой схеме ты хочешь всунуть .net? )

Быстродействующая система на С++ которая проигрывает в 100-1000 раз .Net рассмешил.

У меня они работают параллельно http://infostart.ru/public/238584/ когда нужна скорость или расширение возможностей.
Я показал на разницу в скорости 1С и C#. То есть сейчас скорости для большинства задач хватает и для 1С. Если нужно увеличить, то проще увеличить за счет применения Net. Например уже готовых microsoft dynamics.
Обычно проблема в учетных системах это уже готовые модули для ведения учета, которые состоят из миллиона кода плюс изменения расчетов при сильноизменяющемся нашем законодательстве. Поэтому 1С так просто не сдвинуть.

Кроме того использую прямой доступ через Linq http://infostart.ru/public/402038/
Очень удобно на asp.Net
Во многом проблема даже не в скорости и возможностях, а поддержке существующих решений и количестве специалистов.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 09.10.2015 12:11 Serginio1 . Предыдущая версия .
Re[78]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 12:01
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>В 1C у меня точно нет опыта и не предвидится. ) А вот про веб я как раз вполне в курсе. ))) Да, и наличие у 1C веб-клиента ещё не делает его похожим на полноценный веб.

S>>Какая разница какой. Он есть и в большинстве скорости хватает. Вот сравнение с C#
S>>http://www.forum.mista.ru/topic.php?id=704876#4
S>> И это просто пустого метода. Правда в 1С к каждому подключению идет инициализация юзера, но в этом тесте на пустой конфигурации. В Net это решается через токены авторизации, кэшировании клиента на сервере итд.
S>> То есть в самом простом случае это 8-10 раз без вызова кода.
S>>При этом сложность написания кода на C# не намного выше. Правда и возможностей выше. А вот скорость написания может быть даже выше за счт интеллисенсе и статическая проверка кода. Например многие используют TS вместо голого JS.

_>Редкостная бредятина. Как можно сравнивать законченный продукт (типа 1C) и голый язык. Вот пускай такие сравниватели в начале напишут на C# полноценный аналог 1C со всеми его возможностями, а потом уже проводят сравнения быстродействия.

Давай сравним с Microsoft Dynamics решающий аналогичную задачу
и солнце б утром не вставало, когда бы не было меня
Re[25]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 12:01
Оценка: +1
Здравствуйте, ·, Вы писали:

_>>Это подходит только для простенькой задачки, в которой она единственная на системе и при этом сами вычисления не тяжёлые. Для более сложных случаев (например обработке видео в реальном времени) такие фокусы только помешают.

·>Я говорил о low latency/finance, а ты тут "обработка видео" — вообще из другой области. Обрабатывать видео с явой я и не собирался. Такие софистические фокусы только мешают.

У тебя не было никаких уточнений, что речь только про финансы. Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.
Re[23]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 12:05
Оценка:
Здравствуйте, ·, Вы писали:

_>>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.

·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.
·>В java есть JNI, unsafe режим — издевательство какое-то.

Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. )))
Re[29]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 12:08
Оценка: +2
Здравствуйте, ·, Вы писали:

_>>·>Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).

_>>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?
·>Что иммутабельный объект после вызова деструктора меняет своё состояние.

Иммутабельные объект после вызова деструктора не имеет никакого состояние, потому как самого объекта после этого уже не существует.
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 12:09
Оценка:
Здравствуйте, alex_public, Вы писали:

EP>>> vector<Widget> values(N);

_>·>И молись что N не слишком большой и не получится stack overflow на пустом месте.

_>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )

Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 12:17
Оценка:
Здравствуйте, ·, Вы писали:

I>>Собтсвенно, пытаются писать много, но взлетает далеко не все. Там где не взлетела джава, как правило уже лет 10 и больше С++ в полный рост.

·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.

Назови такую область.

I>>>> Потому для LMAX это вполне реальный риск и именно по этому они лезут из кожи вон, что бы обеспечить нужное время отклика.

I>>·>Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.
I>>Это заблуждение. У тебя практически вся архитектура приложения нацелена на минимизацию проблем с GC. Ты или забыл про это, или еще не понял.
·>Заблуждаешься.

Разве не ты говорил про off-heap приседания ?
Re[24]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 12:19
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Если под управляемыми ты имеешь в виду в том числе и все скриптовые, то да, есть такое дело. Просто вследствие развития ниши для этих языков. Ну и кстати говоря они в большинстве случаев не заменяют, а дополняют (работают кастомизаторами) нативный код.


Заменяют. Раньше логику "взять сумму со счета и раскидать по другим счетам" писали на плюсах в полный рост. Сейчас на с++ остался всего лишь драйвер к БД и кишки управляемой платформы. Т.е. С++ ушел в системно-зависимые слои.
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 12:23
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Я говорил о low latency/finance, а ты тут "обработка видео" — вообще из другой области. Обрабатывать видео с явой я и не собирался. Такие софистические фокусы только мешают.


_>У тебя не было никаких уточнений, что речь только про финансы.

Тут вроде упоминались dxFeed и LMAX, и что типа они постоянно борятся с GC. А они вроде как именно финансы.

_> Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.

Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.
И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 12:26
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Намного хуже. Потому что платформа скрывает за собой значительную часть возможностей железа. Это касается в общем то всех языков, работающих в своей виртуальной машине. Хотя в том же C# с этим дела чуть лучше (правда только в unsafe режиме), но и то не сравнится с нативными языками. А в Java всё совсем печально.

_>·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.
_>·>В java есть JNI, unsafe режим — издевательство какое-то.
_>Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. )))
Не понял. Скажем, установка affinity для потока — делаешь через JNI-вызов ядерной функции. Реализовывать ничего не надо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 12:28
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>·>Вот поэтому и не нужно считать константным, а тупо использовать иммутабельный тип (что при наличии деструкторов в языке сделать невозможно).

_>>>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?
_>·>Что иммутабельный объект после вызова деструктора меняет своё состояние.
_>Иммутабельные объект после вызова деструктора не имеет никакого состояние, потому как самого объекта после этого уже не существует.
А запросить состояние — можно. И даже может что-то вернуться похожее на правду.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 12:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Собтсвенно, пытаются писать много, но взлетает далеко не все. Там где не взлетела джава, как правило уже лет 10 и больше С++ в полный рост.

I>·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.
I>Назови такую область.
Enterprise apps, web apps, finance, IDE в конце концов.

I>>>·>Ещё раз. GC составляет O(1) проблем LL, самая жуть это железо и ОС. Глючный сетевой кабель — и 300мс задержка только в путь, такое GC и не снилось.

I>>>Это заблуждение. У тебя практически вся архитектура приложения нацелена на минимизацию проблем с GC. Ты или забыл про это, или еще не понял.
I>·>Заблуждаешься.
I>Разве не ты говорил про off-heap приседания ?
Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[79]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 12:47
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Что-то я не понял про что ты конкретно говоришь. Вот у тебя сейчас есть нормальная работающая система: быстродействующая платформа (написанная на C++) и скриптовой язык в ней, для кастомизации на месте. Куда конкретно в этой схеме ты хочешь всунуть .net? )

S> Быстродействующая система на С++ которая проигрывает в 100-1000 раз .Net рассмешил.

Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? )

S> У меня они работают параллельно http://infostart.ru/public/238584/ когда нужна скорость или расширение возможностей.

S>Я показал на разницу в скорости 1С и C#. То есть сейчас скорости для большинства задач хватает и для 1С. Если нужно увеличить, то проще увеличить за счет применения Net. Например уже готовых microsoft dynamics.

Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

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


Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки.
Re[79]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 12:50
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Редкостная бредятина. Как можно сравнивать законченный продукт (типа 1C) и голый язык. Вот пускай такие сравниватели в начале напишут на C# полноценный аналог 1C со всеми его возможностями, а потом уже проводят сравнения быстродействия.

S> Давай сравним с Microsoft Dynamics решающий аналогичную задачу

Если ты про Microsoft Dynamics ERP, то причём тут .net? )
Re[17]: Java vs C# vs C++
От: PM  
Дата: 09.10.15 12:56
Оценка:
Здравствуйте, ·, Вы писали:

·>Дело вкуса, а не усилий. Простота языка Явы позволяет писать "нечитаемые тыквы" только там где надо. По сравнению с Явой, практически весь сишный код выглядит как нечитаемая тыква.


опять 25. и как же легко у вас тема сменилась на сравнение вкусов Явы и "сишного кода"

PM>>Я разве где-то утверждал что это невозможно? Возможно, ведь в Java есть JNI, а в C# есть unsafe. Но если требуется писать unsafe class Program { static main() {...} } или значительная часть кода будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.

·>Ты пишешь будут трудности больше, чем в плюсах. Это неверно, ибо большинство упомянутых трудностей к языку не относятся. Единственное существенное отличие — это наличие GC, да, в каких-то случаях он создаёт проблемы, но в других случаях он значительно упрощает решение других проблем.

Хорошо, признали GС помехой, с остальным можно мириться. Ну а вызов через unsafe или JNI вас нисколько не настораживает? Ооок.

PM>>Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/

·>Не понял. И причём тут java vs C++?

Я понимаю, что вас лень читать предыдущие 20 страниц темы, но мне так же лень еще раз повторять их.

PM>>Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.

·>Там совсем другие требования, всё гораздо проще, какой же это LL. С играми вообще всё пофиг — сломалось, так сломалось, да и большинство там вообще сейчас 99% LUA и прочий скриптинг. Видео|аудио — фигня, не нужны миллисекунды отклика для 99.99% и потеря пакетов не смертельна. Это всё high throughput и параллелизация.

Расскажите это игрокам каких-нибудь MMORPG, которые тратят там реальные деньги Думаю они, как и биржевые игроки, оценят ваш оптимизм.
Re[27]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 12:56
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>> vector<Widget> values(N);

_>>·>И молись что N не слишком большой и не получится stack overflow на пустом месте.
_>>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
·>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.

В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности.

В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора.

Да, и это ты там с Евгением беседовал, а не со мной. ))) Я просто влез, увидев вектор с данными на стеке.)))
Re[25]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 13:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Если под управляемыми ты имеешь в виду в том числе и все скриптовые, то да, есть такое дело. Просто вследствие развития ниши для этих языков. Ну и кстати говоря они в большинстве случаев не заменяют, а дополняют (работают кастомизаторами) нативный код.

I>Заменяют. Раньше логику "взять сумму со счета и раскидать по другим счетам" писали на плюсах в полный рост. Сейчас на с++ остался всего лишь драйвер к БД и кишки управляемой платформы. Т.е. С++ ушел в системно-зависимые слои.

Я лично не в курсе (никогда не занимался финансами), но сильно сомневаюсь. Насколько я знаю для этой специфической области и в те времена существовали свои решения. Типа всяких Коболов и т.п. ужастиков. )))
Re[31]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.15 13:01
Оценка:
Здравствуйте, ·, Вы писали:

I>>·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.

I>>Назови такую область.
·>Enterprise apps, web apps, finance, IDE в конце концов.

Кроме finance, С++ уже давно ушел из этих областей, там нет. IDE и по сей день пишутся на плюсах. finance — в HFT плюсы в полный рост.

I>>·>Заблуждаешься.

I>>Разве не ты говорил про off-heap приседания ?
·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.

Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
Re[27]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 13:13
Оценка:
Здравствуйте, ·, Вы писали:

_>>У тебя не было никаких уточнений, что речь только про финансы.

·>Тут вроде упоминались dxFeed и LMAX, и что типа они постоянно борятся с GC. А они вроде как именно финансы.

Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области.

_>> Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.

·>Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.

Всё правильно описано. Только я не понял что из этого следует. Да, между этими задачами есть разница, но они обе требуют low latency.

·>И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.


Это не я мешаю, а реальные задачи возникают такие, что требуют этого всего одновременно. )))
Re[80]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 13:13
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Что-то я не понял про что ты конкретно говоришь. Вот у тебя сейчас есть нормальная работающая система: быстродействующая платформа (написанная на C++) и скриптовой язык в ней, для кастомизации на месте. Куда конкретно в этой схеме ты хочешь всунуть .net? )

S>> Быстродействующая система на С++ которая проигрывает в 100-1000 раз .Net рассмешил.

_>Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? )


А зачем переписывать? Если можно сразу писать на C#? Мало того можно сравнить Питон на C++ и IronPython на C#

S>> У меня они работают параллельно http://infostart.ru/public/238584/ когда нужна скорость или расширение возможностей.

S>>Я показал на разницу в скорости 1С и C#. То есть сейчас скорости для большинства задач хватает и для 1С. Если нужно увеличить, то проще увеличить за счет применения Net. Например уже готовых microsoft dynamics.

_>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

Зато сравнивать C# и С++ это нормально. У них разная ниша. Если на C# написать код аля 1С это не далеко от оригинала. Приблизительно как TS от JC
то разница между 1С и С++ это уже разные миры.

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


_>Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки.

Я утвеждаю, что C# для решения подобных задач удобнее как TS vs JS. А я пишу на этих языках. Единственно, что нужно заменить англоязычные операторы на русские.
и солнце б утром не вставало, когда бы не было меня
Re[80]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 13:17
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Редкостная бредятина. Как можно сравнивать законченный продукт (типа 1C) и голый язык. Вот пускай такие сравниватели в начале напишут на C# полноценный аналог 1C со всеми его возможностями, а потом уже проводят сравнения быстродействия.

S>> Давай сравним с Microsoft Dynamics решающий аналогичную задачу

_>Если ты про Microsoft Dynamics ERP, то причём тут .net? )

Например https://msdn.microsoft.com/en-us/library/hh547453.aspx
и солнце б утром не вставало, когда бы не было меня
Re[80]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 13:59
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.


Казалось бы. Вот посмотри http://rsdn.ru/forum/dotnet/6185588.1
Автор: Serginio1
Дата: 17.09.15

С помощью этого можно делать Сайт, Вэб сервисы на Asp.Net но никому это не нужно. 1С ник не знает .Net, а писатели Вэб приложения не знают структуру 1С.
Поэтому проще написать вэб сервис на 1С, чем использовать быстрый доступ через Net.
А ты говоришь скорость. Никому она не нужна. Ни одного комментария.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 14:03
Оценка:
Здравствуйте, PM, Вы писали:

PM>·>Дело вкуса, а не усилий. Простота языка Явы позволяет писать "нечитаемые тыквы" только там где надо. По сравнению с Явой, практически весь сишный код выглядит как нечитаемая тыква.

PM>опять 25. и как же легко у вас тема сменилась на сравнение вкусов Явы и "сишного кода"
Это ты первый заговорил о нечитаемых тыквах. Да, признаюсь — я легко повёлся на смену темы.

будет содержать JNI, то это, на мой взгляд, повод задуматься о правильности выбора инструмента.
PM>·>Ты пишешь будут трудности больше, чем в плюсах. Это неверно, ибо большинство упомянутых трудностей к языку не относятся. Единственное существенное отличие — это наличие GC, да, в каких-то случаях он создаёт проблемы, но в других случаях он значительно упрощает решение других проблем.
PM>Хорошо, признали GС помехой, с остальным можно мириться.
Он не помеха, а инструмент, которым можно научиться пользоваться. Но тут ведь как... Можно научиться, а можно и не научиться, вот тогда он будет только помехой.

PM> Ну а вызов через unsafe или JNI вас нисколько не настораживает? Ооок.

А почему он должен настораживать как-то? Любое внешнее действие типа записи в файл или работа с сетью — jni.

PM>>>Раз вам не понятна полезность этого, значит вам этого пока не требовалось. Никаких проблем, не рокет сайнс. Некоторых вот не устраивала производительность сетевой подсистемы в Cassandra, они решили использовать user-space решение: http://www.scylladb.com/technology/network/

PM>·>Не понял. И причём тут java vs C++?
PM>Я понимаю, что вас лень читать предыдущие 20 страниц темы, но мне так же лень еще раз повторять их.
Как я понял, ты убеждаешь, что вот user-space какой-то настолько магический, что из явы почему-то не доступный. Хотя я вроде приводил тебе ссылку. Так причём тут java vs C++?

PM>>>Low Latency не ограничивается миром финансов. Многопользовательские игры, видео/аудио через интернет — я не знаю крупных проектов на управляемых языках, кроме Minecraft. В финансах Java оказалась популярной платформой благодаря удачному сочетанию обстоятельств в нужное время.

PM>·>Там совсем другие требования, всё гораздо проще, какой же это LL. С играми вообще всё пофиг — сломалось, так сломалось, да и большинство там вообще сейчас 99% LUA и прочий скриптинг. Видео|аудио — фигня, не нужны миллисекунды отклика для 99.99% и потеря пакетов не смертельна. Это всё high throughput и параллелизация.
PM>Расскажите это игрокам каких-нибудь MMORPG, которые тратят там реальные деньги Думаю они, как и биржевые игроки, оценят ваш оптимизм.
Пфф.. Реальные деньги — это какой объём? Хоть $1B в день наскребётся? Если чё, биржевой рынок порядка на три больше.
Но это всё не в тему. Т.е. ты хочешь сказать, раз Явы в MMORPG нет (кроме Minecraft), то значит она для LL не работает?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 14:18
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.

_>В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности.
_>В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора.
Если ты в коде сделаешь ArrayList<MyClass> то объект ArrayList может так же разместиться на стеке, ибо он маленький — содержит только ссылку на MyClass[] и пару примитивов. Мало того, если размер самого Object[] так же окажется маленьким, то EA тоже может решить разместить на стеке. И в итоге вместо тройной косвенности может получиться та же одинарная.
А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 14:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>·>А там где не взлетел С++, как правило лет 10 и больше джава в полный рост.

I>>>Назови такую область.
I>·>Enterprise apps, web apps, finance, IDE в конце концов.
I>Кроме finance, С++ уже давно ушел из этих областей, там нет
Не "ушел" а тупо не взлетел. Взлетали всякие бейсики, перлы, питоны, пхп, и прочее.

I>IDE и по сей день пишутся на плюсах.

Eclipse? IntelliJ? Да даже Студию уже на # переписывают.

I> finance — в HFT плюсы в полный рост.

Наравне с Java.

I>>>·>Заблуждаешься.

I>>>Разве не ты говорил про off-heap приседания ?
I>·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.
I>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 14:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>>>Это просто твоё мнение, ничем не аргументированое.

EP>>>>Это аргумент. Ты можешь быть согласен с ним или нет.
I>>>А противоположная формулировка, хочешь ты или нет, тоже аргумент или как ?
EP>>А смысл просто так повторять противоположную формулировку? Скажи что не согласен потому-то и тому-то, или хотя бы попроси разъяснения — зачем кирпичом прикидываться?
I>Начни с себя. Ты ведь начал голословно вещать, что всё де миф и тд и тд.

Так я сразу же пояснил почему

EP>>На C можно писать как с "контролем над временем", так и без него — это ортогональное свойство. Точно также и для C++. Поэтому контроль над временем ортогонален "как на Си".

EP>>Вот есть бы сказал что "как на блаб", при этом блаб бы использовался исключительно для задач контролем над временем — был бы другой разговор.
I>"Как на Си" это в первую очередь использования явных механизмов. Нет никаких скрытых фокусов, магии конструкторов-деструкторов-исключений и тд и тд и тд.
I>Контролировать легче именно потому, что все делается явно. Разумеется, при желании любую идею можно опаскудить.

Даже если отобрать деструкторы и исключения у C++ (и то, и то кстати в некоторой степени реализуется, и даже используется и на C) — то всё равно до "как на C" будет очень далеко.
При этом деструкторы даже не запрещены в Joint Strike Fighter C++ Coding Standards, а исключения запрещены только условно, то есть с условием выполнив которое их можно использовать.

I>>>У твоей подстраховки один побочный эффект — время выполнения может быть недетерминированым.

EP>>Эта подстраховка никак не влияет на порядок вызова деструкторов, он остаётся таким же как было бы и без неё.
I>Я про количество и глубину, а не порядок вызова.

Глубина тоже никак не меняется от введения этой подстраховки

I>>>Я же сказал, что каскадная очистка это один из возможных вариантов реализации. Тебе её удобно делать деструкторами. Отсюда ясно, что хрен его знает, какое будет время работы.

EP>>Нет, ты потерял контекст. Мы сейчас рассматриваем случай где использование ref-counting избыточно, то есть не продиктовано самой задачей, как в случае с разделяемым владением(а такие задачи сами по себе редки). В этом случае ref-counting никак не влияет на порядок вызова деструкторов.
I>Это ты хочешь понамекать, что якобы единтсвенная проблема это инкремент-декремент относительно общей массы. Я говорю совсем про другое.

В случае когда ref-counting используется исключительно для подстраховки, а не для решения проблемы разделяемого владения — да, единственная проблема это inc/dec, которых начиная с C++11 мало.
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 14:53
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>У тебя не было никаких уточнений, что речь только про финансы.

_>·>Тут вроде упоминались dxFeed и LMAX, и что типа они постоянно борятся с GC. А они вроде как именно финансы.
_>Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области.
Вот возьми что-нибудь из http://codedependents.com/2014/01/27/11-best-practices-for-low-latency-systems/ и подумай что именно тут java-specific? Все те же извраты будут и в плюсах.

_>>> Ты говорил про low latency в принципе, а реалтайм видео как раз и требуются фиксированные задержки миллисекундных порядков. Только вот за эти миллисекунды надо успевать обрабатывать мегабайты информации.

_>·>Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.
_>Всё правильно описано. Только я не понял что из этого следует. Да, между этими задачами есть разница, но они обе требуют low latency.
И они потребуют всех тех же извращений. За что яву-то опустили?

_>·>И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.

_>Это не я мешаю, а реальные задачи возникают такие, что требуют этого всего одновременно. )))
Но почему ты решил, что выход один единствтвенный — С++? Как видно из опыта тех компаний — java тоже подходит, и даже лучше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 15:16
Оценка:
Здравствуйте, ·, Вы писали:


I>>>>·>Заблуждаешься.

I>>>>Разве не ты говорил про off-heap приседания ?
I>>·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.
I>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
dot>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.

А вместо например MyObj[] что? И кто и как создаст эти newMyObj?
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 15:54
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>>>>Разве не ты говорил про off-heap приседания ?

I>>>·>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.
I>>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
dot>>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.
EP>А вместо например MyObj[] что?
ну например List<MyObj> или какие-нибудь буферы, Disruptor, пулы, етс.

EP>И кто и как создаст эти newMyObj?

Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[25]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 16:03
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.

_>>·>В java есть JNI, unsafe режим — издевательство какое-то.
_>>Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. )))
·>Не понял. Скажем, установка affinity для потока — делаешь через JNI-вызов ядерной функции. Реализовывать ничего не надо.

Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? )
Re[31]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 16:03
Оценка:
Здравствуйте, ·, Вы писали:

_>>>>А какая вообще связь между константностью/иммутабельностью и наличием деструкторов?

_>>·>Что иммутабельный объект после вызова деструктора меняет своё состояние.
_>>Иммутабельные объект после вызова деструктора не имеет никакого состояние, потому как самого объекта после этого уже не существует.
·>А запросить состояние — можно. И даже может что-то вернуться похожее на правду.

Ну и зачем обсуждать заведомо некорректный код? )
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 16:13
Оценка: -1
Здравствуйте, alex_public, Вы писали:

_>>>·>Ничего оно не скрывает. Если "скрыто" что-то нужное, то можно раскрыть.

_>>>·>В java есть JNI, unsafe режим — издевательство какое-то.
_>>>Это как же JNI интересно раскрывает? ) Он же не позволяет делать замену нативному коду, а как раз наоборот позволяет реализовывать часть функциональности нативным кодом. )))
_>·>Не понял. Скажем, установка affinity для потока — делаешь через JNI-вызов ядерной функции. Реализовывать ничего не надо.
_>Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? )
Я считаю, что ты фигню какую-то говоришь, что я перестал тебя понимать. Да, Джава не всемогутер, а хороший инструмент. Да, можно найти области, где этот инструмент не работает или работает плохо. Скажем, дравйвер видеокарты на Яве писать бессмысленно, если вообще возможно, а вот критичный LL код — вполне. Когда мы обсуждаем конкретные пункты, то можно уже сравнивать. Тут приводились какие-то пункты, по ним Джава, как выяснилось, не уступает и имеет некоторые преимущества.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 16:16
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>А запросить состояние — можно. И даже может что-то вернуться похожее на правду.

_>Ну и зачем обсуждать заведомо некорректный код? )
Затем что в Джаве эта проблема решена. Такого типа некорректный код — невозможен. Это является сильным преимуществом в некоторых ситуациях.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[81]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 16:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? )

S> А зачем переписывать? Если можно сразу писать на C#? Мало того можно сравнить Питон на C++ и IronPython на C#

Затем, что все тормоза 1C следуют из этого. Но и основные преимущества (DSL) тоже происходят из этого же.

_>>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

S> Зато сравнивать C# и С++ это нормально. У них разная ниша. Если на C# написать код аля 1С это не далеко от оригинала. Приблизительно как TS от JC
S>то разница между 1С и С++ это уже разные миры.

C++ и C# — это оба языка общего назначения, а не DSL. Конечно их целевые ниши различаются, но на фоне разницы со скриптовыми языками это не принципиально.

И я очень сомневаюсь, что какие-то профильные задачи решаются похоже на C# и 1C. Озвучь задачи тогда уж... Может это не профильные задачи 1C, а что-то Обычное? ) Тогда оно и на C++ будет выглядеть тривиально.

_>>Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки.

S> Я утвеждаю, что C# для решения подобных задач удобнее как TS vs JS. А я пишу на этих языках. Единственно, что нужно заменить англоязычные операторы на русские.

Сомнительно) Озвучь ка эти самые задачи...
Re[81]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 16:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Давай сравним с Microsoft Dynamics решающий аналогичную задачу

_>>Если ты про Microsoft Dynamics ERP, то причём тут .net? )
S>Например https://msdn.microsoft.com/en-us/library/hh547453.aspx

По ссылке у тебя Microsoft Dynamics CRM. Там да, .net, но какое отношение CRM имеет к 1C?
Re[81]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 16:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

S>Казалось бы. Вот посмотри http://rsdn.ru/forum/dotnet/6185588.1
Автор: Serginio1
Дата: 17.09.15

S>С помощью этого можно делать Сайт, Вэб сервисы на Asp.Net но никому это не нужно. 1С ник не знает .Net, а писатели Вэб приложения не знают структуру 1С.
S>Поэтому проще написать вэб сервис на 1С, чем использовать быстрый доступ через Net.
S>А ты говоришь скорость. Никому она не нужна. Ни одного комментария.

А где кто-то говорил, что в задачах 1C нужна скорость? )
Re[29]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 16:41
Оценка: :)
Здравствуйте, ·, Вы писали:

_>>В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности.

_>>В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора.
·>Если ты в коде сделаешь ArrayList<MyClass> то объект ArrayList может так же разместиться на стеке, ибо он маленький — содержит только ссылку на MyClass[] и пару примитивов. Мало того, если размер самого Object[] так же окажется маленьким, то EA тоже может решить разместить на стеке. И в итоге вместо тройной косвенности может получиться та же одинарная.

Может будет, а может нет — гарантий нет.

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

·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.


Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 17:05
Оценка:
Здравствуйте, ·, Вы писали:

I>>IDE и по сей день пишутся на плюсах.

·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают.

IDE на C++ достаточно много. Причём как специализированных для C++ (Qt Creator, Code::Blocks, CodeLite), так и универсальных (Anjuta, KDevelop, Geany). Это только то, что с ходу вспомнилось.
Re[25]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 17:12
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>И не в покер, а в преферанс. И не выиграл, а проиграл.

EP>>>>И не ссылку, а сам объект. И не unique_ptr, а просто стэковый объект.
dot>>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.
EP>>То есть имелось в виду scoped_ptr — более ограниченная версия unique_ptr. Например unique_ptr можно возвращать из функции.
dot>EA работает и с множеством функций. Сделай "byte[] func() {return new byte[100500];}"- ничего страшного.

Ближе, но всё равно не то — unique_ptr можно передавать хоть вверх, хоть вниз, хоть сохранить в массиве, и это всё работает даже без инлайнинга.
Да даже в одном scope EA далеко не всегда сможет доказать что нет escape — банально упрётся в halting problem.

EP>>>> vector<Widget> values(N);

dot>>>И молись что N не слишком большой и не получится stack overflow на пустом месте.
_>>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
dot>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.

Да нет никакого запутывания. Если бы ты знал язык, без всякого углубления в advanced фичи — ты бы никогда не запутался.
Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++. Ты его в очередной раз подтвердил.
Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984

Причём по сути это относится не только к *_ptr — а и в общем очень много мифов относительно C++. И в общем не так страшен чёртC++, как его малюют.

dot>>>массив не убегает за пределы, то при выходе из стека объект грохнется

EP>>Каким образом грохнется? Речь только про некомпактифицируемые кучи?
dot>Самое тривиальное — копирующим GC.

Каким образом? Положили в память эти non-escape данные, дальше вызвали какую-нибудь стороннюю функцию (не давая ей наши non-escape) — она сделала дальше какие-то аллокации, которые пошли следом за нашими non-escape данным.
Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?

EP>>>>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика

EP>>>>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.
dot>>>Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются.
EP>>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть.
dot>Железом нам даны адреса, а не указатели.

А указатель что по-твоему хранит?

EP>>>>Упёрлись в потолок, GC начинает очень долго освобождать за O(N), отбирая ресурсы у других потоков, общая пропускная способность снижается (забиты каналы памяти, и аллокации происходят медленней), извне приходят всё новые задачи для которых в свою очередь нужна всё новая память, в конце концов либо OOM либо DoS.

dot>>>Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java.
EP>>Не грохнется — у него нет зависимости O(N) от количества живых объектов.
dot>new/malloc и delete/free работают не за O(1) внезапно.

Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.

dot>Если у тебя gc работает в режиме, что у него есть зависимость O(N) (т.е. худший случай), то ты делаешь что-то не то.


Эта зависимость есть всегда.

dot>Как известно, gc работает хорошо при короткоживущих и длинноживущих объектах.


То есть при любых?

dot>А проверяет он по грязным регионам, а не по всем живым.


Да без разницы, пусть он даже при каждой проверке не будет бегать по OG — сложность это не меняет.

dot>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.


Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность

EP>>>>Такой Array и другие контейнеры нужно делать для каждого типа данных. У тебя будут FooArray, BarArray, FooPriorityQueue, BarPriorityQueue и т.д.

EP>>>>Либо как вариант добавлять лишней динамичности, но от неё будут свои тормоза, причём как размеры заранее не известны.
dot>>>В LL не так уж и много разных структур.
EP>>Ты постоянно говоришь о каком-то одном use-case'ы.
EP>>Даже если и мало — всё равно придётся опускаться на очень низкий уровень, исключительно из-за самого языка.
dot>Я и не изобретаю общую теорию всего, а решаю практические задачи.

А кто-то изобретает? В Java нет структур — это практический недостаток и факт

dot>>>И, как и в С++, и, скорее, всего будут поверх array.

EP>>Это ты о чём?
EP>>Например на C++ есть выгода от структур (в смысле хранения по значению) даже для вещей типа сбалансированных деревьев — так как уменьшает количество индерекций — само значение хранится в узле, а не указатель на значение.
dot>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.

Проблема в том для каждого типа элемента нужен будет отдельный Java код.

dot>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.


Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.

dot>>>>>Да, выглядит некрасиво, но обычно составляет <0.1% кода и сложностей никаких не доставляет.

EP>>>>Это одна из главных причин тормозов в языках с превалирующей pointer semantics. Положил класс с несколькими полями-объектами в массив — уже на ровном месте выросло целое дерево индерекций и аллокаций.
dot>>>В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это.
EP>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры
dot>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.

Далеко не всегда. Да и почему внезапно-то?

dot>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.


В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.

EP>>>>Хуже, намного. Разве пример со структурами тебя не убедил? — это реально уровень ниже чем C, на ровном месте. Так это только один аспект.

EP>>>>Быстрый код на C++ можно писать на высоком уровне абстракции — не нужно отказываться ни от замыканий, ни от классов, ни от ФВП и полиморфизма — и при этом он будет давать точно такое же (либо практически такое же) быстродействие как и такой же код написанный на низком уровне вручную — в этом одна из главных фишек C++.
dot>>>Тут не фичи и уровни абстракции, а хранение и передача данных главное. И там и там об этом надо заботиться. В Яве — не создавать лишних индирекций, в плюса — не делать лишних копий и аккуратно заботиться о владении. Ведь тоже ничего хорошего в том, когда все эти уровни абстракции только и делают, что решают проблемы владения, тогда как в яве оно само, из коробки.
EP>>Это уже передёргивание. Да, работу с памятью GC упрощают (при этом не гарантируя отсутствие утечек).
dot>Зато гарантируется отсутствие битых ссыслок.

Да, это плюс — с этим никто не спорил

EP>>Да, на C++ нужно думать/помнить о владении (это не означает что каждый new на Java превращается в *_ptr).

EP>>Нет, уровни абстракции о которых я говорю решают далеко не только проблемы владения — они позволяют писать высокоуровневый И быстрый код.
dot>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.

А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки

dot>и прочее, которые позволяют и многие твои любимые абстракции


Я говорю не просто про абстракции, а про бесплатные, либо крайне дешёвые.

dot>Выразительность языка с другой стороны стреляет отстутсвием нормальной IDE.


Это тоже передёргивание.
Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.
При этом аналогичную выразительность можно достичь не делая проблемы анализаторам. Те же структуры есть в C#.
Re[34]: Java vs C# vs C++
От: gardener  
Дата: 09.10.15 17:15
Оценка:
_>Каких ещё вендоров софта? ))) Там нет подобного рынка, т.к. нет никаких общих стандартов — прошивки не переносимы между разными железками. И да, там пока ещё чаще C, а не C++. В основном из-за инерции.

Смотря где. Прошивки чипов (например WiFi, BT или LTE) — дело не в инерции. С язык сильно проще. Легче контролировать результаты, меньше требований к программистам. А в этой области нужно очень много знания самой области. Люди которые могут на высоком уровне при этом программировать встречаются редко.
Re[29]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 17:16
Оценка:
Здравствуйте, ·, Вы писали:

_>>Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области.

·>Вот возьми что-нибудь из http://codedependents.com/2014/01/27/11-best-practices-for-low-latency-systems/ и подумай что именно тут java-specific? Все те же извраты будут и в плюсах.

Ну если смотреть на этот список с точки зрения C++, то там вообще нет никаких извращений. Вполне нормальные архитектурные элементы не приводящие ни к каким ужасам.

Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.

_>>·>Зато параллелится элементарно — SMID/GPU/etc. Притом — потерянный фрейм ни на что не влияет. В LL/finance — это задержки микросекундные, обработка в один поток и ничего терять нельзя. Ещё для видео обычно не нужна работа с памятью — выделил буфер под кадры один раз и пилишь.

_>>Всё правильно описано. Только я не понял что из этого следует. Да, между этими задачами есть разница, но они обе требуют low latency.
·>И они потребуют всех тех же извращений. За что яву-то опустили?

Если говорить про обработку видео, то из-за этого: http://rsdn.ru/forum/philosophy/6117201.1
Автор: alex_public
Дата: 18.07.15
И обрати внимание, что в случае C++ никаких специальных извращений для такого результата не потребовалось — это самый обычный код.

_>>·>И вообще, похоже ты мешаешь в кучу low latency, real time и high throughput.

_>>Это не я мешаю, а реальные задачи возникают такие, что требуют этого всего одновременно. )))
·>Но почему ты решил, что выход один единствтвенный — С++? Как видно из опыта тех компаний — java тоже подходит, и даже лучше.

Из опыта каких компаний? Где java системы реалтаймого видео? )
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 17:17
Оценка: -1
Здравствуйте, alex_public, Вы писали:

_>>>В данном случае на стеке расположен сам вектор. Далее, в куче выделяется блок, в котором располагается непрерывный массив с самими объектами. Т.е. имеем одинарный уровень косвенности.

_>>>В аналогичном случае на Java имеет ссылку на объект (коллекцию) в куче, в котором массив ссылок на объекты в куче (причём расположенные не факт что последовательно). В итоге имеем тройную косвенность, убивающую всякие намёки на работу кэша процессора.
_>·>Если ты в коде сделаешь ArrayList<MyClass> то объект ArrayList может так же разместиться на стеке, ибо он маленький — содержит только ссылку на MyClass[] и пару примитивов. Мало того, если размер самого Object[] так же окажется маленьким, то EA тоже может решить разместить на стеке. И в итоге вместо тройной косвенности может получиться та же одинарная.
_>Может будет, а может нет — гарантий нет.
Эти гарантии нужны далеко не всегда. Главная цель же не размещение на стеке, а чтобы работало с требуемыми характеристиками скорости и безопасности.

_>Да, ну и для кэша гораздо важнее последовательное расположение данных в памяти, а это у тебя тут никак не выходит.

Надо будет — выйдет. Но в 99% случаев — не надо.

_>·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.

_>Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.
Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.
А как же абстракция и прочие умные слова? Вместо простого "список объектов" начинаешь рассуждать как же оно будет в памяти, куча, стек, индирекции, индексы, указатели... И это чуть ли не для каждой строчки кода, а не для того 1% строчек где это действительно важно.

Аргумент похож на использование SQL. Да, можно написать свои структуры данных, размещать в файлах, писать запросы под свои нужны, т.к. видите ли, "я уверен, что во всех случаях сделаю это лучше чем SQL optimizer".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 17:20
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>>IDE и по сей день пишутся на плюсах.

_>·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают.
_>IDE на C++ достаточно много. Причём как специализированных для C++ (Qt Creator, Code::Blocks, CodeLite), так и универсальных (Anjuta, KDevelop, Geany). Это только то, что с ходу вспомнилось.
Много конечно, но по сложности они как notepad на фоне Eclipse/InteliJ (хотя мне доводилось видеть не всё вышеперечисленнное, может и ошибаюсь).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 17:25
Оценка: +1
Здравствуйте, ·, Вы писали:

_>>Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? )

·>Я считаю, что ты фигню какую-то говоришь, что я перестал тебя понимать. Да, Джава не всемогутер, а хороший инструмент. Да, можно найти области, где этот инструмент не работает или работает плохо. Скажем, дравйвер видеокарты на Яве писать бессмысленно, если вообще возможно, а вот критичный LL код — вполне. Когда мы обсуждаем конкретные пункты, то можно уже сравнивать. Тут приводились какие-то пункты, по ним Джава, как выяснилось, не уступает и имеет некоторые преимущества.

Лично я знаю ровно одно преимущество Java/C#. Это возможность достаточно безопасного использования низкоквалифицированных программистов. Возможно с точки зрения технологии это звучит и не очень. Но с точки зрения бизнеса это очень существенное преимущество, правда актуальное в основном для не IT компаний. Так что благодаря этому преимуществу Java/C# заслуженно занимают доминирующее положение во внутрикорпоративном энтерпрайзе. И если их там кто-то и подвинет, то разве что JS, если обретёт соответствующую инфраструктуру (кстати шаги к этому уже наблюдаются). ))) А вот использование Java/C# в других областях, особенно со сложным кодом или тяжёлыми условиями, мне кажется неразумным. Но в нашей индустрии вообще много всего неразумного встречается. )))
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 17:34
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>А запросить состояние — можно. И даже может что-то вернуться похожее на правду.

_>>Ну и зачем обсуждать заведомо некорректный код? )
·>Затем что в Джаве эта проблема решена. Такого типа некорректный код — невозможен. Это является сильным преимуществом в некоторых ситуациях.

И в Java и в C++ будет одинаковый расклад для таких ситуаций — исключение (правда в C++ системное, а не родное).
delete x; х=nullptr;
x->v=1;

x=null;
x.v=1;

Но это на самом деле не важно, т.к. подобные проблемы являются уделом разве что студентов.
Отредактировано 10.10.2015 9:38 alex_public . Предыдущая версия .
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 18:01
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Причём это происходит по вине самого GC.

dot>>>Ну подкрути параметры чуток, не проблема.
EP>>Это уберёт линейную сложность?
dot>Да. Линейная сложность это худший случай, когда у тебя постоянно меняются указатели в большинтсве живых объектов и постоянно создаются новые.

Не обязательно в большинстве живых, достаточно в относительно малом количестве.

dot>В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.


Алгоритмическая сложность не "растёт" — это характеристика алгоритма. Например если брать Buddy — то она логарифмическая.
Да, — чем больше N, тем будет дольше, но чтобы прикинуть как это "дольше" зависит от N — как раз и используют алгоритмическую сложность.

dot>>>>>Не понимаю каким образом ты избежишь ООМ в таком случае в плюсах?

EP>>>>Нет линейной зависимости времени очистки от количества живых объектов. В случае же GC, на одной и той же скорости входящего потока он может либо успевать очищать, либо нет — и это сильно зависит от текущего количества живых объектов.
dot>>>Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы.
EP>>В очереди объекты которые уже готовы для очистки. А вот сколько там живых reachable объектов — не важно, пусть хоть десять миллиардов.
dot>Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь,

Ещё раз, очередь у каждого потока своя, thread-local.

dot>обрабатываемую одним несчастным потоком?


Необязательно одним

EP>>>>Зачем?

dot>>>Определить граф-остаток.
EP>>Зачем его определять? Что это даст?
EP>>Пока не превысим бюджет времени — удаляем сами, как только времени осталось меньше чем требует max объект — ставим остаток в очередь.
dot>Так как мы конкретно будем этот бюджет считать?

Бюждет зависит от конкретной задачи.

EP>>>>Очередь может быть thread local.

dot>>>И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос.
EP>>От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC.
dot>Мы вроде рассматриваем случай, когда sharedPtr.release может начаться из разных тредов. Как ты собираешься использовать single writer структуру?

Объект управляемый shared_ptr всегда удаляется одним потоком, каким из них — определяется тем самым атомарным wait-free счётчиком. Это всё есть даже без отложенной очистки.

dot>>>Это тоже подзадача GC — решать сразу или отложить.

EP>>А ещё в подзадачах GC есть сложение целых.
dot>Хорошо, не подзадача, а средство достижения заявленных характеристик.

Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.

EP>>>>Разница в том, что написанная библиотека используется внутри самого host-языка. То есть эти gc_ptr — они используется не внутри какой-то виртуальной среды созданной библиотекой, а внутри вызывающего host-языка.

dot>>>Так и деструкторы и прочие С++ фишки можно реализовать в java,
EP>>Каким образом ты реализуешь деструкторы? Какое будет использование? Каким образом реализуешь например Expression Templates и прочие compile-time EDSL?
dot>А зачем compile time? Я знаю, что C++ compile time — Turing Complete, но в общем-то и в Java можно сделать плугин для компилятора или load-time кодогенерацию.

Так фишка EDSL (Embedded Domain Specific Language) именно в том что он embedded.
Re[31]: Java vs C# vs C++
От: alex_public  
Дата: 09.10.15 18:02
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.

_>>Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.
·>Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.

Фокус в том, что дефолтное в C++ как раз и есть самое быстрое для 99% задач. )

·>А как же абстракция и прочие умные слова? Вместо простого "список объектов" начинаешь рассуждать как же оно будет в памяти, куча, стек, индирекции, индексы, указатели... И это чуть ли не для каждой строчки кода, а не для того 1% строчек где это действительно важно.


А что, разве не все программисты такое обдумывают на автомате в процессе проектирования?
Re[35]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 19:15
Оценка:
Здравствуйте, ·, Вы писали:

I>>>>>>Разве не ты говорил про off-heap приседания ?

I>>>>dot>Off-heap не особо нужен в подавляющем большинстве случаев, да и на архитектуру никак не влияет.
I>>>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap
dot>>>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.
EP>>А вместо например MyObj[] что?
dot>ну например List<MyObj>

1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.
3. Лишние индерекции внутри List никуда не делись.


EP>>И кто и как создаст эти newMyObj?

dot>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.

"в общем-то и вся разница по факту." — да?
Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
Re[82]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 19:28
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ох, ты похоже не понимаешь... Если переписать тот же 1C или скажем Питон с C++ на C#, то получившийся скриптовой язык станет только медленнее. Так понятно? )

S>> А зачем переписывать? Если можно сразу писать на C#? Мало того можно сравнить Питон на C++ и IronPython на C#

_>Затем, что все тормоза 1C следуют из этого. Но и основные преимущества (DSL) тоже происходят из этого же.

Из чего? Из-за того, что интерпритатор медленнее компилятора.

_>>>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

S>> Зато сравнивать C# и С++ это нормально. У них разная ниша. Если на C# написать код аля 1С это не далеко от оригинала. Приблизительно как TS от JC
S>>то разница между 1С и С++ это уже разные миры.

_>C++ и C# — это оба языка общего назначения, а не DSL. Конечно их целевые ниши различаются, но на фоне разницы со скриптовыми языками это не принципиально.


_>И я очень сомневаюсь, что какие-то профильные задачи решаются похоже на C# и 1C. Озвучь задачи тогда уж... Может это не профильные задачи 1C, а что-то Обычное? ) Тогда оно и на C++ будет выглядеть тривиально.


Я тебе уже приводил Microsoft Dynamics CRM
_>>>Дело не только в этом, а ещё и в том, что 1C — это DSL. И соответственно в своей узкой области он в любом случае будет удобнее, чем любые универсальные языки.
S>> Я утвеждаю, что C# для решения подобных задач удобнее как TS vs JS. А я пишу на этих языках. Единственно, что нужно заменить англоязычные операторы на русские.

_>Сомнительно) Озвучь ка эти самые задачи...

Оооо ты не знаешь задачи 1С? Тогда сложно объяснять. На самом деле 1С и прочие системы имеют свой язык прежде всего, что бы на них зарабатывать. Когда они создавались C# был еще в так же как TS vs JS.
Как я тебе показывал ссылки есть некая иерархия классов Справочники,документы, регистры сведений,оборотов, остатков, Константы, Планы счетов итд
Я формирую аналогичные классы на C# только разумеется без модулей объектов.
Которые также можно написать. Некоторые люди даже переводят из одного языка в другой. https://infostart.ru/public/321282/
В свое время народ пытался сделать убийцу 1С.
и солнце б утром не вставало, когда бы не было меня
Re[82]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 19:28
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>>> Давай сравним с Microsoft Dynamics решающий аналогичную задачу

_>>>Если ты про Microsoft Dynamics ERP, то причём тут .net? )
S>>Например https://msdn.microsoft.com/en-us/library/hh547453.aspx

_>По ссылке у тебя Microsoft Dynamics CRM. Там да, .net, но какое отношение CRM имеет к 1C?

Это учетные системы.
и солнце б утром не вставало, когда бы не было меня
Re[82]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.10.15 19:32
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ещё раз повторяю. Сравнение скорости 1C и C# — это бред.

S>>Казалось бы. Вот посмотри http://rsdn.ru/forum/dotnet/6185588.1
Автор: Serginio1
Дата: 17.09.15

S>>С помощью этого можно делать Сайт, Вэб сервисы на Asp.Net но никому это не нужно. 1С ник не знает .Net, а писатели Вэб приложения не знают структуру 1С.
S>>Поэтому проще написать вэб сервис на 1С, чем использовать быстрый доступ через Net.
S>>А ты говоришь скорость. Никому она не нужна. Ни одного комментария.

_>А где кто-то говорил, что в задачах 1C нужна скорость? )

Она нужна и очень. Пока ниша 1С это мелкий и средний бизнес. А для выхода на компании от 1000 пользователей скорости уже не хватает.
А там несколько и суммы другие. Прежде всего поддержка
и солнце б утром не вставало, когда бы не было меня
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 19:47
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Т.е. ты считаешь, что ограничения виртуальной машины связаны исключительно с доступом к OS API? )

_>·>Я считаю, что ты фигню какую-то говоришь, что я перестал тебя понимать. Да, Джава не всемогутер, а хороший инструмент. Да, можно найти области, где этот инструмент не работает или работает плохо. Скажем, дравйвер видеокарты на Яве писать бессмысленно, если вообще возможно, а вот критичный LL код — вполне. Когда мы обсуждаем конкретные пункты, то можно уже сравнивать. Тут приводились какие-то пункты, по ним Джава, как выяснилось, не уступает и имеет некоторые преимущества.
_>Лично я знаю ровно одно преимущество Java/C#. Это возможность достаточно безопасного использования низкоквалифицированных программистов. Возможно с точки зрения технологии это звучит и не очень. Но с точки зрения бизнеса это очень существенное преимущество, правда актуальное в основном для не IT компаний. Так что благодаря этому преимуществу Java/C# заслуженно занимают доминирующее положение во внутрикорпоративном энтерпрайзе. И если их там кто-то и подвинет, то разве что JS, если обретёт соответствующую инфраструктуру (кстати шаги к этому уже наблюдаются). ))) А вот использование Java/C# в других областях, особенно со сложным кодом или тяжёлыми условиями, мне кажется неразумным. Но в нашей индустрии вообще много всего неразумного встречается. )))
Нет, это просто языки разного уровня. Ровно то же самое можно сказать заменив Java/C# -> C++, C++ -> ассемблер.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 19:54
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Затем что в Джаве эта проблема решена. Такого типа некорректный код — невозможен. Это является сильным преимуществом в некоторых ситуациях.

_>И в Java и в C++ будет одинаковый расклад для таких ситуаций — исключение (правда в C++ системное, а не родное).
_>
_>delete x;
x->>v=1;
_>

_>
_>x=null;
_>x.v=1;
_>

Неправда. Будет не исключение, а undefined behaviour, в дебаг-моде в лучшем случае может и грохнется. А если учесть всякие кастомные аллокаторы...
Помню натыкался на багу:
class X
{
   char *begin;
   char *end;
   int size() {return end - begin;}
}

Как думаешь что вернёт size() для удалённого объекта даже в дебаг моде?

Или что-то новое в стандарт ввели?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 20:20
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Это уберёт линейную сложность?

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

dot>>В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.

EP>Алгоритмическая сложность не "растёт" — это характеристика алгоритма. Например если брать Buddy — то она логарифмическая.
EP>Да, — чем больше N, тем будет дольше, но чтобы прикинуть как это "дольше" зависит от N — как раз и используют алгоритмическую сложность.
Хорошо, скорость падать, а не сложность расти.

dot>>>>Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы.

EP>>>В очереди объекты которые уже готовы для очистки. А вот сколько там живых reachable объектов — не важно, пусть хоть десять миллиардов.
dot>>Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь,
EP>Ещё раз, очередь у каждого потока своя, thread-local.
Если потоки не обмениваются объектами — это скучный случай, gc будет летать благодаря TLAB.

dot>>обрабатываемую одним несчастным потоком?

EP>Необязательно одним
А сколькими? И как будешь раздавать по потокам? Как contention разруливать?

dot>>>>И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос.

EP>>>От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC.
dot>>Мы вроде рассматриваем случай, когда sharedPtr.release может начаться из разных тредов. Как ты собираешься использовать single writer структуру?
EP>Объект управляемый shared_ptr всегда удаляется одним потоком, каким из них — определяется тем самым атомарным wait-free счётчиком. Это всё есть даже без отложенной очистки.
Я знаю что он удаляется одним потоком. Как сделать так, чтобы он не стал удаляться в критическом потоке?

dot>>>>Это тоже подзадача GC — решать сразу или отложить.

EP>>>А ещё в подзадачах GC есть сложение целых.
dot>>Хорошо, не подзадача, а средство достижения заявленных характеристик.
EP>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
Я говорю это к тому, что эти средства уже доступны при использовании GC.

EP>>>Каким образом ты реализуешь деструкторы? Какое будет использование? Каким образом реализуешь например Expression Templates и прочие compile-time EDSL?

dot>>А зачем compile time? Я знаю, что C++ compile time — Turing Complete, но в общем-то и в Java можно сделать плугин для компилятора или load-time кодогенерацию.
EP>Так фишка EDSL (Embedded Domain Specific Language) именно в том что он embedded.
Так он и будет Embedded, пишешь обычный код на java с аннотациями, а во время компиляции или загрузки классов — происходит магия.
Ну вот... рассуждали о управлении памятью, LL и внезапно слились до type system и EDSL.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 20:30
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>·>А в плюсах ты явно будешь писать "vector<MyClass>()", "new vector<MyClass>()", "vector<MyClass*>()" или "new vector<MyClass*>()" — принимать это решение каждый раз на основе кучи предположений, умолчаний, ещё на стадии разработки архитектуры приложения, хотя в большинтсве случаев такие решения может принять JIT на основе знаний полученных на стадии исполнения кода у конечного пользователя.

_>>>Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.
_>·>Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.
_>Фокус в том, что дефолтное в C++ как раз и есть самое быстрое для 99% задач. )
Это которое? Я ещё забыл варианты "MyClass[]", "MyClass*[]", все комбинации "xxx_ptr<vector<xxx_ptr<MyClass> >"

_>·>А как же абстракция и прочие умные слова? Вместо простого "список объектов" начинаешь рассуждать как же оно будет в памяти, куча, стек, индирекции, индексы, указатели... И это чуть ли не для каждой строчки кода, а не для того 1% строчек где это действительно важно.

_>А что, разве не все программисты такое обдумывают на автомате в процессе проектирования?
А ты часто обдумываешь в какие регистры процессора какая переменная попадёт?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 20:46
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>ну например List<MyObj>

EP>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
Ничего, и не такое жевал.

EP>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.

Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.

EP>3. Лишние индерекции внутри List никуда не делись.

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

EP>>>И кто и как создаст эти newMyObj?

dot>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>"в общем-то и вся разница по факту." — да?
EP>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
Берёт что? Код-то тривиальный.
Вместо
class BusinessData
{
  private int a;
  private int b;
  int getA() {return a}
  int getB() {return b}
}

пишем
class BusinessData
{
  private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
  private int pos;
  int getA() {return buf.getInt(pos)}
  int getB() {return buf.getInt(pos+4)}
}

List<> просто проставляет pos соответственно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 20:51
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Это уберёт линейную сложность?

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

Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.
И то — это отслеживание имеет свою цену, которая размазывается по всему коду.

dot>>>В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.

EP>>Алгоритмическая сложность не "растёт" — это характеристика алгоритма. Например если брать Buddy — то она логарифмическая.
EP>>Да, — чем больше N, тем будет дольше, но чтобы прикинуть как это "дольше" зависит от N — как раз и используют алгоритмическую сложность.
dot>Хорошо, скорость падать, а не сложность расти.

При логарифмической сложности между N=1000 и N=1000000 — разница примерно в два раза. А в случае же линейной сложности — примерно в тысячу раз
Feel the paindifference.

dot>>>>>Если ты в С++ заведёшь очередь для очистки — столкнёшься ровно с той же проблемой. Не вижу разницы.

EP>>>>В очереди объекты которые уже готовы для очистки. А вот сколько там живых reachable объектов — не важно, пусть хоть десять миллиардов.
dot>>>Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь,
EP>>Ещё раз, очередь у каждого потока своя, thread-local.
dot>Если потоки не обмениваются объектами — это скучный случай,

А зачем обмениваться практически мёртвыми объектами?

dot>>>обрабатываемую одним несчастным потоком?

EP>>Необязательно одним
dot>А сколькими? И как будешь раздавать по потокам? Как contention разруливать?

Так зависит от задачи — где-то просто достаточно thread pool. Где-то же будет один очищатель на один рабочий поток и т.п. И то, это только если такая проблема вообще возникнет.
Но это всё уже не важно — главное разгрузить рабочий поток

dot>>>>>И кто из этой очереди будет обрабатывать элементы? Сам thread — не может отвлекаться, он LL, в любую наносекунду может прийти новый запрос.

EP>>>>От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC.
dot>>>Мы вроде рассматриваем случай, когда sharedPtr.release может начаться из разных тредов. Как ты собираешься использовать single writer структуру?
EP>>Объект управляемый shared_ptr всегда удаляется одним потоком, каким из них — определяется тем самым атомарным wait-free счётчиком. Это всё есть даже без отложенной очистки.
dot>Я знаю что он удаляется одним потоком. Как сделать так, чтобы он не стал удаляться в критическом потоке?

Критический поток поставит его в очередь, а сам удалять не будет.

dot>>>>>Это тоже подзадача GC — решать сразу или отложить.

EP>>>>А ещё в подзадачах GC есть сложение целых.
dot>>>Хорошо, не подзадача, а средство достижения заявленных характеристик.
EP>>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
dot>Я говорю это к тому, что эти средства уже доступны при использовании GC.

Аналогия: "когда нарезаешь массив на структуру, переизобретаешь C++"

EP>>>>Каким образом ты реализуешь деструкторы? Какое будет использование? Каким образом реализуешь например Expression Templates и прочие compile-time EDSL?

dot>>>А зачем compile time? Я знаю, что C++ compile time — Turing Complete, но в общем-то и в Java можно сделать плугин для компилятора или load-time кодогенерацию.
EP>>Так фишка EDSL (Embedded Domain Specific Language) именно в том что он embedded.
dot>Так он и будет Embedded, пишешь обычный код на java с аннотациями, а во время компиляции или загрузки классов — происходит магия.

Как сделаешь например элементарный анализ размерностей? Чтобы вот такое выражение выдавало ошибку на этапе компиляции 20m/3s + 2kg?

dot>Ну вот... рассуждали о управлении памятью, LL и внезапно слились до type system и EDSL.


Так это ты же "внезапно" кидаешься громкими заявлениями "и прочие С++ фишки можно реализовать в java"
Re[37]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 21:06
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>ну например List<MyObj>

EP>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>Ничего, и не такое жевал.

Так в off-heap тогда смысла мало

EP>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.

dot>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.

В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
Круто — чё

EP>>3. Лишние индерекции внутри List никуда не делись.

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

Это один индерект на каждый элемент, а не просто один индерект. Разница может быть на порядки

EP>>>>И кто и как создаст эти newMyObj?

dot>>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>>"в общем-то и вся разница по факту." — да?
EP>>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
dot>Берёт что? Код-то тривиальный.

Берёт описание структур и генерирует все необходимые комбинации класс-контейнер/алгоритм.

dot>Вместо

dot>
dot>class BusinessData
dot>{
dot>  private int a;
dot>  private int b;
dot>  int getA() {return a}
dot>  int getB() {return b}
dot>}
dot>


Тут вообще достаточно:
struct BusinessData
{
    int a, b;
};

Зачем get/set?

dot>пишем


Та самая ручная нарезка на структуры:

dot>
dot>class BusinessData
dot>{
dot>  private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
dot>  private int pos;
dot>  int getA() {return buf.getInt(pos)}
dot>  int getB() {return buf.getInt(pos+4)}
dot>}
dot>


Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
Отредактировано 09.10.2015 21:10 Evgeny.Panasyuk . Предыдущая версия .
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 21:08
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Я ничего подобного не упоминал, т.к. это совсем не моя область. Да, и кстати, насколько я понял данные продукты упоминались в том контексте, что мол посмотрите как надо извратить Java, чтобы была возможность конкурировать в данной области.

_>·>Вот возьми что-нибудь из http://codedependents.com/2014/01/27/11-best-practices-for-low-latency-systems/ и подумай что именно тут java-specific? Все те же извраты будут и в плюсах.
_>Ну если смотреть на этот список с точки зрения C++, то там вообще нет никаких извращений. Вполне нормальные архитектурные элементы не приводящие ни к каким ужасам.
"Извращения" это непривычный код, не так как учат в букварях.
Почитай, кстати там комменты — о том же рассуждают. Хорошо сказано:

Java is a great platform none the less, but I think it’s biggest advantage is that ordinary business logic (90% of your code?) can still depend on GC and safety features and make use of highly tuned and tested libraries written with Unsafe. This is a great trade-off between getting the last 5% of perf and being productive. A trade-off that makes sense for a lot of people but a trade-off none the less. Writing complicated application code in C/C++ is a nightmare after all.


_>Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.

И это ВНЕЗАПНО нужно делать и в плюсах, банальный vector<MyClass> может работать плохо, если, например, в классе куча полей, а тебя нужно последовательно читать только одно, вылезет structure of arrays и т.п.


_>Из опыта каких компаний?

Упомянутых в топике.

_>Где java системы реалтаймого видео? )

"«Ага!!!» — укоризненно сказали суровые сибирские плюсовики!"
даже не знаю что на такое возразить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 21:38
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Не обязательно в большинстве живых, достаточно в относительно малом количестве.

dot>>Нет, поиск осуществляется по тронутым с предыдущего цикла сборки регионам объектов.
EP>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.
EP>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает. Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например) или даже изменением архитектуры приложения.

dot>>>>В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.

EP>>>Алгоритмическая сложность не "растёт" — это характеристика алгоритма. Например если брать Buddy — то она логарифмическая.
EP>>>Да, — чем больше N, тем будет дольше, но чтобы прикинуть как это "дольше" зависит от N — как раз и используют алгоритмическую сложность.
dot>>Хорошо, скорость падать, а не сложность расти.
EP>При логарифмической сложности между N=1000 и N=1000000 — разница примерно в два раза. А в случае же линейной сложности — примерно в тысячу раз
EP>Feel the paindifference.
Бывает. Лечится. Алгоритмы — сила.

dot>>>>Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь,

EP>>>Ещё раз, очередь у каждого потока своя, thread-local.
dot>>Если потоки не обмениваются объектами — это скучный случай,
EP>А зачем обмениваться практически мёртвыми объектами?
В смысле? Какие уж есть.

dot>>>>обрабатываемую одним несчастным потоком?

EP>>>Необязательно одним
dot>>А сколькими? И как будешь раздавать по потокам? Как contention разруливать?
EP>Так зависит от задачи — где-то просто достаточно thread pool. Где-то же будет один очищатель на один рабочий поток и т.п. И то, это только если такая проблема вообще возникнет.
EP>Но это всё уже не важно — главное разгрузить рабочий поток
Ну собственно и получается — gc солнца вручную. Понятно, что gc можно реализовать на С++, он и реализован на С++ в JVM.

EP>>>>>От задачи зависит, может и сам thread. А может и отдельный thread, при этом contention с другими потоками всё равно не будет — так как очередь SPSC.

dot>>>>Мы вроде рассматриваем случай, когда sharedPtr.release может начаться из разных тредов. Как ты собираешься использовать single writer структуру?
EP>>>Объект управляемый shared_ptr всегда удаляется одним потоком, каким из них — определяется тем самым атомарным wait-free счётчиком. Это всё есть даже без отложенной очистки.
dot>>Я знаю что он удаляется одним потоком. Как сделать так, чтобы он не стал удаляться в критическом потоке?
EP>Критический поток поставит его в очередь, а сам удалять не будет.
И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?

EP>>>>>А ещё в подзадачах GC есть сложение целых.

dot>>>>Хорошо, не подзадача, а средство достижения заявленных характеристик.
EP>>>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
dot>>Я говорю это к тому, что эти средства уже доступны при использовании GC.
EP>Аналогия: "когда нарезаешь массив на структуру, переизобретаешь C++"
Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер? Просто подгоняешь код к специфике железа.

EP>>>Так фишка EDSL (Embedded Domain Specific Language) именно в том что он embedded.

dot>>Так он и будет Embedded, пишешь обычный код на java с аннотациями, а во время компиляции или загрузки классов — происходит магия.
EP>Как сделаешь например элементарный анализ размерностей? Чтобы вот такое выражение выдавало ошибку на этапе компиляции 20m/3s + 2kg?
http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#units-checker

dot>>Ну вот... рассуждали о управлении памятью, LL и внезапно слились до type system и EDSL.

EP>Так это ты же "внезапно" кидаешься громкими заявлениями "и прочие С++ фишки можно реализовать в java"
Так можно же, turing complete же. Нужно ли — вопрос.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[35]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 09.10.15 22:12
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Не обязательно в большинстве живых, достаточно в относительно малом количестве.

dot>>>Нет, поиск осуществляется по тронутым с предыдущего цикла сборки регионам объектов.
EP>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.
EP>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.

А как ты называешь объекты которые живут долго, но не до конца работы приложения?

dot>Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например)


Причём тут flyweight? Объекты-то изменяются.

dot>или даже изменением архитектуры приложения.


Конечно, поэтому и появляются всякие GC-free и off-heap'ы

dot>>>>>В такой ситуации С++ тоже не поздоровится — и фрагментация кучи, и возрастающая сложность malloc/free.

EP>>>>Алгоритмическая сложность не "растёт" — это характеристика алгоритма. Например если брать Buddy — то она логарифмическая.
EP>>>>Да, — чем больше N, тем будет дольше, но чтобы прикинуть как это "дольше" зависит от N — как раз и используют алгоритмическую сложность.
dot>>>Хорошо, скорость падать, а не сложность расти.
EP>>При логарифмической сложности между N=1000 и N=1000000 — разница примерно в два раза. А в случае же линейной сложности — примерно в тысячу раз
EP>>Feel the paindifference.
dot>Бывает. Лечится. Алгоритмы — сила.

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

dot>>>>>Ты представляешь как поплохеет системе когда туча тредов будет пихать миллиарды объекты в одну единственную очередь,

EP>>>>Ещё раз, очередь у каждого потока своя, thread-local.
dot>>>Если потоки не обмениваются объектами — это скучный случай,
EP>>А зачем обмениваться практически мёртвыми объектами?
dot>В смысле? Какие уж есть.

Контекст потерял? Ещё раз.
У нас есть объект, счётчик ссылок которого ушёл в ноль. Так? Зачем обмениваться им с другими рабочими потоками?

EP>>Критический поток поставит его в очередь, а сам удалять не будет.

dot>И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?

Проблема вообще-то была в другом. Если по аналогии — в том что грубо говоря pop одного элемента очереди линейно зависит от её размера. Здесь же такой зависимости нет.

EP>>>>>>А ещё в подзадачах GC есть сложение целых.

dot>>>>>Хорошо, не подзадача, а средство достижения заявленных характеристик.
EP>>>>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
dot>>>Я говорю это к тому, что эти средства уже доступны при использовании GC.
EP>>Аналогия: "когда нарезаешь массив на структуру, переизобретаешь C++"
dot>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?

Аналогично — а почему тогда GC?

EP>>>>Так фишка EDSL (Embedded Domain Specific Language) именно в том что он embedded.

dot>>>Так он и будет Embedded, пишешь обычный код на java с аннотациями, а во время компиляции или загрузки классов — происходит магия.
EP>>Как сделаешь например элементарный анализ размерностей? Чтобы вот такое выражение выдавало ошибку на этапе компиляции 20m/3s + 2kg?
dot>http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#units-checker

Какой объем реализации? На C++ — меньше ста строк.
Да и не сравнится ведь:
@m int meters = 5 * UnitsTools.m;

vs
auto length = 5m;

Да и нет интеграции в систему типов — например перегрузка не работает

dot>>>Ну вот... рассуждали о управлении памятью, LL и внезапно слились до type system и EDSL.

EP>>Так это ты же "внезапно" кидаешься громкими заявлениями "и прочие С++ фишки можно реализовать в java"
dot>Так можно же, turing complete же. Нужно ли — вопрос.

Полнота по Тьюрингу вообще о другом — о тех программах которые можно реализовать. Разговор же про языковые фичи, с помощью которых происходит реализация
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 22:33
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

EP>>>То есть имелось в виду scoped_ptr — более ограниченная версия unique_ptr. Например unique_ptr можно возвращать из функции.
dot>>EA работает и с множеством функций. Сделай "byte[] func() {return new byte[100500];}"- ничего страшного.
EP>Ближе, но всё равно не то — unique_ptr можно передавать хоть вверх, хоть вниз, хоть сохранить в массиве, и это всё работает даже без инлайнинга.
EP>Да даже в одном scope EA далеко не всегда сможет доказать что нет escape — банально упрётся в halting problem.
Не сможет — чуть тормозить начнёт. А если человек не сможет доказать передачу указателей — всё круто и непредсказуемо навернётся.

dot>>>>И молись что N не слишком большой и не получится stack overflow на пустом месте.

_>>>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
dot>>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.
EP>Да нет никакого запутывания. Если бы ты знал язык, без всякого углубления в advanced фичи — ты бы никогда не запутался.
Да знаю я язык прекрасно, опыта 5+ лет, просто уже несколько лет не использовал на работе.

EP>Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++.

... либо битый указатель.

EP>Этот феномен даже Страуструп высмеивал — https://youtu.be/OB-bdWKwXsU?t=1984

EP>Причём по сути это относится не только к *_ptr — а и в общем очень много мифов относительно C++. И в общем не так страшен чёртC++, как его малюют.
Вот и говорит, что нужен протокол для каждого объекта, решать кто что делает с объектами.
Тут ведь как:
было
void showDialog()
{
  Widget g;
  ...
  doer.doSomething(g);
  ...
}

//и вдруг мы решили поменять имплементацию doSomething чтобы что-то делалось в другом треде, и мы знаем, что он завершится до закрытия диалога. А потом вдруг тред стормозил или появился другой способ закрытия диалога...

dot>>>>массив не убегает за пределы, то при выходе из стека объект грохнется

EP>>>Каким образом грохнется? Речь только про некомпактифицируемые кучи?
dot>>Самое тривиальное — копирующим GC.

EP>Каким образом? Положили в память эти non-escape данные, дальше вызвали какую-нибудь стороннюю функцию (не давая ей наши non-escape) — она сделала дальше какие-то аллокации, которые пошли следом за нашими non-escape данным.

EP>Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?
Тем что объект пойдёт на стек или в регистры. Какие аллокации?

EP>>>>>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика

EP>>>>>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.
dot>>>>Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются.
EP>>>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть.
dot>>Железом нам даны адреса, а не указатели.
EP>А указатель что по-твоему хранит?
Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.

dot>>>>Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java.

EP>>>Не грохнется — у него нет зависимости O(N) от количества живых объектов.
dot>>new/malloc и delete/free работают не за O(1) внезапно.
EP>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.
Так и разные алгоритмы GC есть. И столько всего можно крутить... И я уверен, что вариантов даже больше, ибо ссылка в jvm более абстрактна чем указатели в плюсах, а значит больше простора для оптимизаций.


dot>>Как известно, gc работает хорошо при короткоживущих и длинноживущих объектах.

EP>То есть при любых?
Нет, среднеживущие ещё есть.

dot>>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.

EP>Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность
Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.

EP>>>Ты постоянно говоришь о каком-то одном use-case'ы.

EP>>>Даже если и мало — всё равно придётся опускаться на очень низкий уровень, исключительно из-за самого языка.
dot>>Я и не изобретаю общую теорию всего, а решаю практические задачи.
EP>А кто-то изобретает? В Java нет структур — это практический недостаток и факт
Зато он даёт больший простор для JVM/JIT/etc.
Ну вот есть структуры в C# — а толку? Где LL?

EP>>>Это ты о чём?

EP>>>Например на C++ есть выгода от структур (в смысле хранения по значению) даже для вещей типа сбалансированных деревьев — так как уменьшает количество индерекций — само значение хранится в узле, а не указатель на значение.
dot>>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.
EP>Проблема в том для каждого типа элемента нужен будет отдельный Java код.
Не смертельно.

dot>>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.

EP>Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.
Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.

dot>>>>В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это.

EP>>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры
dot>>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
EP>Далеко не всегда. Да и почему внезапно-то?
Настолько же ВНЕЗАПНО как и в случае с GC.

dot>>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.

EP>В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.
Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).

dot>>Зато гарантируется отсутствие битых ссыслок.

EP>Да, это плюс — с этим никто не спорил
Притом очень ценный плюс, что он перевешивает весь колбасокод с оффхипами и т.д.

EP>>>Да, на C++ нужно думать/помнить о владении (это не означает что каждый new на Java превращается в *_ptr).

EP>>>Нет, уровни абстракции о которых я говорю решают далеко не только проблемы владения — они позволяют писать высокоуровневый И быстрый код.
dot>>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.
EP>А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки
Не положит, к сожалению. Иначе бы уже давно компилировали.
Вся эта указательная магия и арифметика, юнионы, и прочий low level не может быть покрыт GC и JVM ссылками, поэтому при компиляции С/C++ память будет внутри byte[].

dot>>и прочее, которые позволяют и многие твои любимые абстракции

EP>Я говорю не просто про абстракции, а про бесплатные, либо крайне дешёвые.
Ценой других абстракций.

dot>>Выразительность языка с другой стороны стреляет отстутсвием нормальной IDE.


EP>Это тоже передёргивание.

EP>Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.
EP>При этом аналогичную выразительность можно достичь не делая проблемы анализаторам.
Может и можно... Я сходу не могу сделать такое заявление.

EP>Те же структуры есть в C#.

А толку-то от них...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 22:50
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>ну например List<MyObj>

EP>>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>>Ничего, и не такое жевал.
EP>Так в off-heap тогда смысла мало
Когда как. Очень зависит от юзкейсов. Невозможно сказать: "делай так и будет быстро".

EP>>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.

dot>>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
EP>В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
EP>Круто — чё
Если очень надо и до машкодов дойдёшь. Но это очень экзотические случаи.

EP>>>3. Лишние индерекции внутри List никуда не делись.

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

dot>>
dot>>class BusinessData
dot>>{
dot>>  private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
dot>>  private int pos;
dot>>  int getA() {return buf.getInt(pos)}
dot>>  int getB() {return buf.getInt(pos+4)}
dot>>}
dot>>


EP>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>

Двигаешь pos и получаешь элемент. Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 09.10.15 23:12
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.

EP>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.

dot>>Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например)

EP>Причём тут flyweight? Объекты-то изменяются.
Смотря как изменяются.

dot>>или даже изменением архитектуры приложения.

EP>Конечно, поэтому и появляются всякие GC-free и off-heap'ы
Пусть появляются там где действительно надо.

EP>>>При логарифмической сложности между N=1000 и N=1000000 — разница примерно в два раза. А в случае же линейной сложности — примерно в тысячу раз

EP>>>Feel the paindifference.
dot>>Бывает. Лечится. Алгоритмы — сила.
EP>Конечно сила, о чём я тебе и говорю.
EP>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.

EP>>>А зачем обмениваться практически мёртвыми объектами?

dot>>В смысле? Какие уж есть.
EP>Контекст потерял? Ещё раз.
EP>У нас есть объект, счётчик ссылок которого ушёл в ноль. Так? Зачем обмениваться им с другими рабочими потоками?
Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.

EP>>>Критический поток поставит его в очередь, а сам удалять не будет.

dot>>И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?
EP>Проблема вообще-то была в другом. Если по аналогии — в том что грубо говоря pop одного элемента очереди линейно зависит от её размера. Здесь же такой зависимости нет.
Не одного элемента, а всей очереди. GC за цикл собирает не один объект.

dot>>>>>>Хорошо, не подзадача, а средство достижения заявленных характеристик.

EP>>>>>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
dot>>>>Я говорю это к тому, что эти средства уже доступны при использовании GC.
EP>>>Аналогия: "когда нарезаешь массив на структуру, переизобретаешь C++"
dot>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?
EP>Аналогично — а почему тогда GC?
Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.

EP>Какой объем реализации? На C++ — меньше ста строк.

Ну вот... сейчас ещё начнём строки считать... увольте.

EP>Да и не сравнится ведь:

EP>
EP>@m int meters = 5 * UnitsTools.m;
EP>

EP>vs
EP>
EP>auto length = 5m;
EP>

EP>Да и нет интеграции в систему типов — например перегрузка не работает
Перегрузка чего? Это же примитивы.
И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.

dot>>>>Ну вот... рассуждали о управлении памятью, LL и внезапно слились до type system и EDSL.

EP>>>Так это ты же "внезапно" кидаешься громкими заявлениями "и прочие С++ фишки можно реализовать в java"
dot>>Так можно же, turing complete же. Нужно ли — вопрос.
EP>Полнота по Тьюрингу вообще о другом — о тех программах которые можно реализовать. Разговор же про языковые фичи, с помощью которых происходит реализация
GC это не совсем языковая фича. Возьми Скалу, если так нужны фичи.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 10.10.15 00:01
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

EP>>>>То есть имелось в виду scoped_ptr — более ограниченная версия unique_ptr. Например unique_ptr можно возвращать из функции.
dot>>>EA работает и с множеством функций. Сделай "byte[] func() {return new byte[100500];}"- ничего страшного.
EP>>Ближе, но всё равно не то — unique_ptr можно передавать хоть вверх, хоть вниз, хоть сохранить в массиве, и это всё работает даже без инлайнинга.
EP>>Да даже в одном scope EA далеко не всегда сможет доказать что нет escape — банально упрётся в halting problem.
dot>Не сможет — чуть тормозить начнёт. А если человек не сможет доказать передачу указателей — всё круто и непредсказуемо навернётся.

А зачем человеку доказывать? Например:
auto foo()
{
    return calc(make_unique<Something>());
}
Результат может содержать ссылку на этот unique, а может не содержать. Человек может например просто знать из документации что в результирующем объекте нет этого unique. Анализатору же придётся это доказывать проинлайнив весь код.

dot>>>>>И молись что N не слишком большой и не получится stack overflow на пустом месте.

_>>>>Вектор не выделяет память на стеке. Ну во всяком случае со стандартным аллокатором. ))) Ты уверен, что ты реально знаком с C++? )
dot>>>Ах, да, не заметил. Да ты меня запутал. Говорил о размещении объектов на стеке, и внезапно опять куча.
EP>>Да нет никакого запутывания. Если бы ты знал язык, без всякого углубления в advanced фичи — ты бы никогда не запутался.
dot>Да знаю я язык прекрасно, опыта 5+ лет, просто уже несколько лет не использовал на работе.

Так ведь по-разному используют. Есть действительно много когда где лепят *_ptr на каждый чих. Виной тому отчасти например некоторые книги — есть авторы которые пишут сразу по трём языкам C++/C#/Java, просто копируя примеры с небольшими изменениями из книги в книгу. И отчасти те кто застрял в начале 90-х.

EP>>Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++.

dot>... либо битый указатель.

*_ptr не спасают от битых указателей, их основанная цель это выражение семантики владения в коде, отсюда и имена shared/unique/scoped.

dot>Тут ведь как:

dot>было
dot>
dot>void showDialog()
dot>{
dot>  Widget g;
dot>  ...
dot>  doer.doSomething(g);
dot>  ...
dot>}
dot>

dot>//и вдруг мы решили поменять имплементацию doSomething чтобы что-то делалось в другом треде, и мы знаем, что он завершится до закрытия диалога. А потом вдруг тред стормозил или появился другой способ закрытия диалога...

Это изменение контракта, которое прекрасно выражается в системе типов — у doSomething поменяется тип параметра и приведённый код не скомпилируется

dot>>>>>

массив не убегает за пределы, то при выходе из стека объект грохнется


EP>>>>Каким образом грохнется? Речь только про некомпактифицируемые кучи?
dot>>>Самое тривиальное — копирующим GC.
EP>>Каким образом? Положили в память эти non-escape данные, дальше вызвали какую-нибудь стороннюю функцию (не давая ей наши non-escape) — она сделала дальше какие-то аллокации, которые пошли следом за нашими non-escape данным.
EP>>Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?
dot>Тем что объект пойдёт на стек или в регистры. Какие аллокации?

Ещё раз. Прочитай свои слова выше (выделено), и ниже:

dot>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

Теперь скажи каким образом здесь поможет EA.

EP>>>>>>Именно голые не владеющие указатели — владелец то переживёт всех. Вполне обычная/нормальная/стандартная практика

EP>>>>>>Smart-pointer'ы прежде всего помогают избавиться от голых владеющих указателей, а не от того что ты подумал.
dot>>>>>Бррр... Я уж надеялся, что голые указатели постепенно изничтожаются.
EP>>>>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть.
dot>>>Железом нам даны адреса, а не указатели.
EP>>А указатель что по-твоему хранит?
dot>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.

Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет.

dot>>>>>Это же сценарий high throughput, а не low latency. В такой ситуации и C++ грохнется — он будет делать ту же работу, просто в рабочих тредах, а на в отдельных gc-тредах как java.

EP>>>>Не грохнется — у него нет зависимости O(N) от количества живых объектов.
dot>>>new/malloc и delete/free работают не за O(1) внезапно.
EP>>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.
dot>Так и разные алгоритмы GC есть. И столько всего можно крутить... И я уверен, что вариантов даже больше, ибо ссылка в jvm более абстрактна чем указатели в плюсах, а значит больше простора для оптимизаций.

Так вот покажи GC не с сублинейной сложностью, желательно ещё чтобы был более-менее популярен.

dot>>>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.

EP>>Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность
dot>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.

Штуки типа cuckoo hashing не на ровном месте появились.
Для hashtable есть альтернативы с гарантированной сублинейной сложностью, и там где гарантия нужна — их и используют. Причём можно комбинировать — снаружи hashtable, а внутри узлов при превышении лимита что-то логарифмическое — тогда будет суб-линейная гарантия.

EP>>>>Ты постоянно говоришь о каком-то одном use-case'ы.

EP>>>>Даже если и мало — всё равно придётся опускаться на очень низкий уровень, исключительно из-за самого языка.
dot>>>Я и не изобретаю общую теорию всего, а решаю практические задачи.
EP>>А кто-то изобретает? В Java нет структур — это практический недостаток и факт
dot>Зато он даёт больший простор для JVM/JIT/etc.

Какой простор? Всё равно есть те же int/double, с семантикой как у структур

dot>Ну вот есть структуры в C# — а толку? Где LL?


В C# свои проблемы. У тех же структур есть много ограничений. Но тем не менее они есть, и не нужно их эмулировать руками.

EP>>>>Это ты о чём?

EP>>>>Например на C++ есть выгода от структур (в смысле хранения по значению) даже для вещей типа сбалансированных деревьев — так как уменьшает количество индерекций — само значение хранится в узле, а не указатель на значение.
dot>>>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.
EP>>Проблема в том для каждого типа элемента нужен будет отдельный Java код.
dot>Не смертельно.

Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код.

dot>>>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.

EP>>Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.
dot>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.

А например в хэш-таблице?

dot>>>>>В C++ можно тоже кучу главных причин тормозов придумать. Скажем, передача by-value. Непонятно только к чему это.

EP>>>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры
dot>>>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
EP>>Далеко не всегда. Да и почему внезапно-то?
dot>Настолько же ВНЕЗАПНО как и в случае с GC.

Ок, допустим, в случае чего by-value заменим, не проблема — пара закорючек.
В случае с GC что будешь делать?

dot>>>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.

EP>>В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.
dot>Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).

Нет же, случаи принципиально разные. Где-то наверху callstack делаем:
{
    vector<Foo> many_values(N);
    // ...
    pass_by_reference(many_values);
}
ничего не "засучивая".
Этот массив, по терминам GC, спокойно может попасть под классификацию OG

dot>>>Зато гарантируется отсутствие битых ссыслок.

EP>>Да, это плюс — с этим никто не спорил
dot>Притом очень ценный плюс, что он перевешивает весь колбасокод с оффхипами и т.д.

Этот же плюс есть в C#, в котором "колбасокод" нужен реже, как раз за счёт структур

EP>>>>Да, на C++ нужно думать/помнить о владении (это не означает что каждый new на Java превращается в *_ptr).

EP>>>>Нет, уровни абстракции о которых я говорю решают далеко не только проблемы владения — они позволяют писать высокоуровневый И быстрый код.
dot>>>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.
EP>>А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки
dot>Не положит, к сожалению. Иначе бы уже давно компилировали.
dot>Вся эта указательная магия и арифметика, юнионы, и прочий low level не может быть покрыт GC и JVM ссылками, поэтому при компиляции С/C++ память будет внутри byte[].

Конечно будет, и это одна из причин почему положит на лопатки.
Именно так и происходит
Автор: Evgeny.Panasyuk
Дата: 06.06.15
в Emscripten, который компилирует C++ в JS.
И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить.

dot>>>Выразительность языка с другой стороны стреляет отстутсвием нормальной IDE.

EP>>Это тоже передёргивание.
EP>>Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.
EP>>При этом аналогичную выразительность можно достичь не делая проблемы анализаторам.
dot>Может и можно... Я сходу не могу сделать такое заявление.
EP>>Те же структуры есть в C#.
dot>А толку-то от них...

Не нужно вручную нарезать массивы на структуры
Re[39]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 10.10.15 00:12
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.

dot>>>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
EP>>В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
EP>>Круто — чё
dot>Если очень надо и до машкодов дойдёшь. Но это очень экзотические случаи.

Так дело даже не сложности создания, а в том что это всё может тормозить. То есть получается взяли самое плохое от обхода живых и мёртвых объектов — обходим все.

EP>>>>3. Лишние индерекции внутри List никуда не делись.

dot>>>List будет с большим числом элементов, иначе смысла извращаться нет. А на фоне этого большого числа данных один индирект не будет заметен в микроскоп.
EP>>Это один индерект на каждый элемент, а не просто один индерект. Разница может быть на порядки
dot>>>
dot>>>class BusinessData
dot>>>{
dot>>>  private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
dot>>>  private int pos;
dot>>>  int getA() {return buf.getInt(pos)}
dot>>>  int getB() {return buf.getInt(pos+4)}
dot>>>}
dot>>>

EP>>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
dot>Двигаешь pos и получаешь элемент.

То есть предлагаешь не использовать List? Или писать свой?

dot>Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?


Убрать лишние индерекции из random access — например элементарный бинарный поиск.
Та же сортировка или например min/max heap на основе массива, а-ля std::pop_heap.
Re[37]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 10.10.15 00:28
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.

EP>>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
dot>Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.

Так они долгоживущие по твоей терминологии или нет?

dot>>>Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например)

EP>>Причём тут flyweight? Объекты-то изменяются.
dot>Смотря как изменяются.

flyweight-ы обычно неизменяемые.

EP>>>>При логарифмической сложности между N=1000 и N=1000000 — разница примерно в два раза. А в случае же линейной сложности — примерно в тысячу раз

EP>>>>Feel the paindifference.
dot>>>Бывает. Лечится. Алгоритмы — сила.
EP>>Конечно сила, о чём я тебе и говорю.
EP>>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
dot>Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.

Например?

EP>>>>А зачем обмениваться практически мёртвыми объектами?

dot>>>В смысле? Какие уж есть.
EP>>Контекст потерял? Ещё раз.
EP>>У нас есть объект, счётчик ссылок которого ушёл в ноль. Так? Зачем обмениваться им с другими рабочими потоками?
dot>Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.

Ещё раз, зачем обмениваться практически мёртвыми объектами между рабочими потоками?

EP>>>>Критический поток поставит его в очередь, а сам удалять не будет.

dot>>>И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?
EP>>Проблема вообще-то была в другом. Если по аналогии — в том что грубо говоря pop одного элемента очереди линейно зависит от её размера. Здесь же такой зависимости нет.
dot>Не одного элемента, а всей очереди. GC за цикл собирает не один объект.

Чтобы убрать малое колличество мусорных объектов, GC приходится обходить большое количество живых. И скорость сбора мусорных объектов зависит от количества живых. В этом и аналогия.

dot>>>>>>>Хорошо, не подзадача, а средство достижения заявленных характеристик.

EP>>>>>>Короче, не нужно сами эти средства называть GC. Другой пример — копирующий аллокатор может быть без GC.
dot>>>>>Я говорю это к тому, что эти средства уже доступны при использовании GC.
EP>>>>Аналогия: "когда нарезаешь массив на структуру, переизобретаешь C++"
dot>>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?
EP>>Аналогично — а почему тогда GC?
dot>Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.
EP>>Какой объем реализации? На C++ — меньше ста строк.
dot>Ну вот... сейчас ещё начнём строки считать... увольте.

Достаточно грубой прикидки. Если объём отличается на порядки — то с тем же успехом можно и компилятор модифицировать.

EP>>Да и не сравнится ведь:

EP>>
EP>>@m int meters = 5 * UnitsTools.m;
EP>>

EP>>vs
EP>>
EP>>auto length = 5m;
EP>>

EP>>Да и нет интеграции в систему типов — например перегрузка не работает
dot>Перегрузка чего? Это же примитивы.

На C++ это отдельные типы. И по разным типам можно сделать разные перегрузки.

dot>И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.


Ты же сказал что "и прочие С++ фишки можно реализовать в java" — мы в этой ветке сейчас и находимся.
Re[83]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 08:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Затем, что все тормоза 1C следуют из этого. Но и основные преимущества (DSL) тоже происходят из этого же.

S> Из чего? Из-за того, что интерпритатор медленнее компилятора.

Нуу что-то в этом роде. Кстати, я уже говорил, что тот же JS не так уж сильно уступает в скорости Java/C# благодаря его JIT'у и при этом внешне это не отличается от работы интерпретатора (нет никакой компиляции в промежуточный байт-код). Так что теоретически это поправимо (для того же Питона существует PyPy), но для это авторам надо основательно поработать... )

_>>И я очень сомневаюсь, что какие-то профильные задачи решаются похоже на C# и 1C. Озвучь задачи тогда уж... Может это не профильные задачи 1C, а что-то Обычное? ) Тогда оно и на C++ будет выглядеть тривиально.

S> Я тебе уже приводил Microsoft Dynamics CRM

Ну во-первых CRM — это по сути просто БД для маркетинга. Причём тут 1C или вообще ERP?

_>>Сомнительно) Озвучь ка эти самые задачи...

S> Оооо ты не знаешь задачи 1С? Тогда сложно объяснять. На самом деле 1С и прочие системы имеют свой язык прежде всего, что бы на них зарабатывать. Когда они создавались C# был еще в так же как TS vs JS.
S>Как я тебе показывал ссылки есть некая иерархия классов Справочники,документы, регистры сведений,оборотов, остатков, Константы, Планы счетов итд
S>Я формирую аналогичные классы на C# только разумеется без модулей объектов.
S>Которые также можно написать. Некоторые люди даже переводят из одного языка в другой. https://infostart.ru/public/321282/
S>В свое время народ пытался сделать убийцу 1С.

По сути ты говоришь, что теоретически можно написать новый 1C, причём такой, чтобы C# служил и базовым и скриптовым языком. Осталось "всего лишь" реализовать всю эту функциональность... Я правильно понял? )
Re[83]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 09:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>А где кто-то говорил, что в задачах 1C нужна скорость? )

S> Она нужна и очень. Пока ниша 1С это мелкий и средний бизнес. А для выхода на компании от 1000 пользователей скорости уже не хватает.
S>А там несколько и суммы другие. Прежде всего поддержка

Насколько я знаю для больших компаний полно своих продуктов. Причём как иностранных, так и наших. )
Re[29]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 09:04
Оценка:
Здравствуйте, ·, Вы писали:

·>Нет, это просто языки разного уровня. Ровно то же самое можно сказать заменив Java/C# -> C++, C++ -> ассемблер.


При увеличение уровня обычно увеличивается уровень абстракции. А в случае перехода C++ -> Java/C# мы наоборот видим упрощение. Так что ничего подобного. Другой уровень — это например Пролог или какие-нибудь DSL'и. )
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 09:49
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>Затем что в Джаве эта проблема решена. Такого типа некорректный код — невозможен. Это является сильным преимуществом в некоторых ситуациях.

_>>И в Java и в C++ будет одинаковый расклад для таких ситуаций — исключение (правда в C++ системное, а не родное).
_>>
delete x; x=nullptr;
x->v=1;

_>>
x=null;
x.v=1;

·>Неправда. Будет не исключение, а undefined behaviour, в дебаг-моде в лучшем случае может и грохнется. А если учесть всякие кастомные аллокаторы...

Undefined behaviour это по стандарту языка, без учёта работы ОС. Ну т.е. да, для каких-нибудь микроконтроллеров там действительно будет порча памяти, но на этих МК такие вещи как Java/C# вообще не живут. А в любой современной ОС мы получим соответствующее исключение.

P.S. Ну и да, не забываем, что это мы тут развлекаемся обсуждением заведомо некорректного кода. ))) Типа а вот если мы специально подставим компилятор вот так, то в каком языке какие ошибки будут... ))) В реальном коде такое естественно не встречается.

P.P.S. Я там в предыдущем сообщение опечатку сделал (типа из-за симметрии 2 строки на 2 строки) — сейчас исправил. )
Re[84]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.10.15 10:18
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Затем, что все тормоза 1C следуют из этого. Но и основные преимущества (DSL) тоже происходят из этого же.

S>> Из чего? Из-за того, что интерпритатор медленнее компилятора.

_>Нуу что-то в этом роде. Кстати, я уже говорил, что тот же JS не так уж сильно уступает в скорости Java/C# благодаря его JIT'у и при этом внешне это не отличается от работы интерпретатора (нет никакой компиляции в промежуточный байт-код). Так что теоретически это поправимо (для того же Питона существует PyPy), но для это авторам надо основательно поработать... )


_>>>И я очень сомневаюсь, что какие-то профильные задачи решаются похоже на C# и 1C. Озвучь задачи тогда уж... Может это не профильные задачи 1C, а что-то Обычное? ) Тогда оно и на C++ будет выглядеть тривиально.

S>> Я тебе уже приводил Microsoft Dynamics CRM

_>Ну во-первых CRM — это по сути просто БД для маркетинга. Причём тут 1C или вообще ERP?

БД этдельно, система отдельно.



Что такое Microsoft Dynamics CRM?



Microsoft Dynamics CRM — это наше бизнес-решение для управления отношениями с клиентами (CRM), которое помогает компаниям лучше продвигать и продавать свои продукты и услуги. Мы предоставляет извлекаемые из социальных сетей ценные сведения, бизнес-аналитику обеспечиваем производительность работы с помощью решений One Microsoft. Кроме того, мы предоставляем Microsoft Dynamics CRM в облаке, в локальной среде, а также в виде гибридной системы.


_>>>Сомнительно) Озвучь ка эти самые задачи...

S>> Оооо ты не знаешь задачи 1С? Тогда сложно объяснять. На самом деле 1С и прочие системы имеют свой язык прежде всего, что бы на них зарабатывать. Когда они создавались C# был еще в так же как TS vs JS.
S>>Как я тебе показывал ссылки есть некая иерархия классов Справочники,документы, регистры сведений,оборотов, остатков, Константы, Планы счетов итд
S>>Я формирую аналогичные классы на C# только разумеется без модулей объектов.
S>>Которые также можно написать. Некоторые люди даже переводят из одного языка в другой. https://infostart.ru/public/321282/
S>>В свое время народ пытался сделать убийцу 1С.

_>По сути ты говоришь, что теоретически можно написать новый 1C, причём такой, чтобы C# служил и базовым и скриптовым языком. Осталось "всего лишь" реализовать всю эту функциональность... Я правильно понял? )

Я говорю, о том, что на данном этапе можно использовать данные 1С с той же легкостью, с какой оно сделано на 1С.
Даже еще проще используя типизированный LInq. Еще раз C# vc 1C это так же как TS vs JS.
Вот например пример использования Net в 1С
Процедура OnGetMessageImage(Данные)
    Попытка
    HttpClient=Врап.СоздатьОбъект("System.Net.Http.HttpClient, System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
preview=HttpClient.GetByteArrayAsync(Данные.url).Result;


//File.WriteAllBytes(ИмяФайла,preview);

ДД=Base64Значение(Convert.ToBase64String(preview));
Картинка=Новый Картинка(ДД);
фрм=получитьФорму("ФормаОтчета1");
фрм.Открыть();

Исключение
    Сообщить(ОписаниеОшибки())
    КонецПопытки
КонецПроцедуры


C# код мало отличается
и солнце б утром не вставало, когда бы не было меня
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 10:26
Оценка:
Здравствуйте, ·, Вы писали:

_>>>>Да, всё верно. И я уверен что во всех случаях сделаю это лучше чем JIT.

_>>·>Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.
_>>Фокус в том, что дефолтное в C++ как раз и есть самое быстрое для 99% задач. )
·>Это которое? Я ещё забыл варианты "MyClass[]", "MyClass*[]", все комбинации "xxx_ptr<vector<xxx_ptr<MyClass> >"

Дефолтное — это value type и контейнеры stl. Есть парочка редких случаев, когда применение этих инструментов приводит к не самому оптимальному кода (и тогда как раз делают всяческие кастомные аллокаторы и т.п.), но лично я на них натыкался исключительно в обсуждениях на форумах и т.п., а не в личной практике.

_>>·>А как же абстракция и прочие умные слова? Вместо простого "список объектов" начинаешь рассуждать как же оно будет в памяти, куча, стек, индирекции, индексы, указатели... И это чуть ли не для каждой строчки кода, а не для того 1% строчек где это действительно важно.

_>>А что, разве не все программисты такое обдумывают на автомате в процессе проектирования?
·>А ты часто обдумываешь в какие регистры процессора какая переменная попадёт?

Совершенно не обдумываю, причём по разным причинам в двух разных случаях. В случае отсутствия необходимости в быстродействие (кстати в этом случае у меня скорее Питон в руках будет) понятно что не обдумываю потому что безразлично. А в случае необходимости высокого быстродействия и использования C++ тоже не обдумываю, потому как знаю, что оптимизатор современных компиляторов C++ создаст код лучше любого эксперта в ассемблере.
Re[84]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.10.15 10:27
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>А где кто-то говорил, что в задачах 1C нужна скорость? )

S>> Она нужна и очень. Пока ниша 1С это мелкий и средний бизнес. А для выхода на компании от 1000 пользователей скорости уже не хватает.
S>>А там несколько и суммы другие. Прежде всего поддержка

_>Насколько я знаю для больших компаний полно своих продуктов. Причём как иностранных, так и наших. )

И сколько они стоят? Сколько стоит поддержка итд. Я говорю о том, что на Net легко делать такие системы. Ничем не сложнее чем на скриптовых языках. Но скорость при этом будет приближаться к скорости C++. Или некий аналог TS на Net.
Дело в том, что в 1С клиентский код переводится в JS. Можно создать язык и систему классов для обеспечения кода как в Net так и его трансляция в JS.
Это уже существует DuoCode http://habrahabr.ru/company/enterra/blog/252079/
Я являюсь сторонником TS.
и солнце б утром не вставало, когда бы не было меня
Re[31]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 11:25
Оценка:
Здравствуйте, ·, Вы писали:

_>>Ну если смотреть на этот список с точки зрения C++, то там вообще нет никаких извращений. Вполне нормальные архитектурные элементы не приводящие ни к каким ужасам.

·>"Извращения" это непривычный код, не так как учат в букварях.

Лично я не увидел в этом списке чего-то необычного, заставившего писать непривычный код.

·>Почитай, кстати там комменты — о том же рассуждают. Хорошо сказано:

·>

Java is a great platform none the less, but I think it’s biggest advantage is that ordinary business logic (90% of your code?) can still depend on GC and safety features and make use of highly tuned and tested libraries written with Unsafe. This is a great trade-off between getting the last 5% of perf and being productive. A trade-off that makes sense for a lot of people but a trade-off none the less. Writing complicated application code in C/C++ is a nightmare after all.


Рассуждения без аргументов не интересны. А если попробовать взглянуть на реальность, то "неожиданно" обнаруживается, что почти все самые сложные современные приложения написаны на C/C++. Причём не только системные, типа ОС, но самые пользовательские, типа браузеров.

_>>Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.

·>И это ВНЕЗАПНО нужно делать и в плюсах, банальный vector<MyClass> может работать плохо, если, например, в классе куча полей, а тебя нужно последовательно читать только одно, вылезет structure of arrays и т.п.

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

_>>Из опыта каких компаний?

·>Упомянутых в топике.
_>>Где java системы реалтаймого видео? )
·>"«Ага!!!» — укоризненно сказали суровые сибирские плюсовики!"
·>даже не знаю что на такое возразить.

Ты похоже потерял контекст дискуссии — перечитай сообщения выше. )
Re[85]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 11:43
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Я тебе уже приводил Microsoft Dynamics CRM

_>>Ну во-первых CRM — это по сути просто БД для маркетинга. Причём тут 1C или вообще ERP?
S> БД этдельно, система отдельно.
S>...

Я в курсе что такое CRM))) И пока непонятно какое это имеет отношение к ERP.

_>>По сути ты говоришь, что теоретически можно написать новый 1C, причём такой, чтобы C# служил и базовым и скриптовым языком. Осталось "всего лишь" реализовать всю эту функциональность... Я правильно понял? )

S> Я говорю, о том, что на данном этапе можно использовать данные 1С с той же легкостью, с какой оно сделано на 1С.
S>Даже еще проще используя типизированный LInq. Еще раз C# vc 1C это так же как TS vs JS.
S>Вот например пример использования Net в 1С
S>..
S>C# код мало отличается

Ты в этом примере демонстрируешь вообще другое. Возможность вызова .net кода из 1C. Ну так понятно что с этим нет проблем, если в 1C это специально предусмотрели. И с другими языками/платформами может быть аналогично. Непонятно что ты этим хотел показать.
Re[85]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 11:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Насколько я знаю для больших компаний полно своих продуктов. Причём как иностранных, так и наших. )

S> И сколько они стоят? Сколько стоит поддержка итд. Я говорю о том, что на Net легко делать такие системы. Ничем не сложнее чем на скриптовых языках. Но скорость при этом будет приближаться к скорости C++. Или некий аналог TS на Net.

В принципе это верное утверждение. Осталось только два нюанса:

1. Собственно сделать такую систему (т.е. переписать эти тонны скучного кода из 1C).
2. Убедиться что это кому-то надо. Т.е. проверить, что есть ещё много народа, который считает, что программировать эти дела на C# удобнее чем на языке 1C.

S>Дело в том, что в 1С клиентский код переводится в JS. Можно создать язык и систему классов для обеспечения кода как в Net так и его трансляция в JS.

S>Это уже существует DuoCode http://habrahabr.ru/company/enterra/blog/252079/
S>Я являюсь сторонником TS.

А откуда в данном обсуждение взялся JS? ) Его ты куда хочешь тут воткнуть? )
Re[86]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.10.15 11:56
Оценка:
Здравствуйте, alex_public, Вы писали:

_>S>>Вот например пример использования Net в 1С

S>>..
S>>C# код мало отличается

_>Ты в этом примере демонстрируешь вообще другое. Возможность вызова .net кода из 1C. Ну так понятно что с этим нет проблем, если в 1C это специально предусмотрели. И с другими языками/платформами может быть аналогично. Непонятно что ты этим хотел показать.

Нет это не в 1С предусмотрели, а в Net. http://infostart.ru/public/238584/
А вот теперь покажи как можно использовать классы С++ раз это можно сделать аналогично.
Я к тому, что написать код аналогично 1С на C# нет проблем.
и солнце б утром не вставало, когда бы не было меня
Re[86]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.10.15 12:04
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Насколько я знаю для больших компаний полно своих продуктов. Причём как иностранных, так и наших. )

S>> И сколько они стоят? Сколько стоит поддержка итд. Я говорю о том, что на Net легко делать такие системы. Ничем не сложнее чем на скриптовых языках. Но скорость при этом будет приближаться к скорости C++. Или некий аналог TS на Net.

_>В принципе это верное утверждение. Осталось только два нюанса:


_>1. Собственно сделать такую систему (т.е. переписать эти тонны скучного кода из 1C).

_>2. Убедиться что это кому-то надо. Т.е. проверить, что есть ещё много народа, который считает, что программировать эти дела на C# удобнее чем на языке 1C.
Ну там полно говногода, который тянется от версии к версии. По сути 1С переходя на Управляемые Формы переписывало заново практически весь функционал.
В этом нет ничего страшного. А вот дивиденды можно нехилые срубить.

S>>Дело в том, что в 1С клиентский код переводится в JS. Можно создать язык и систему классов для обеспечения кода как в Net так и его трансляция в JS.

S>>Это уже существует DuoCode http://habrahabr.ru/company/enterra/blog/252079/
S>>Я являюсь сторонником TS.

_>А откуда в данном обсуждение взялся JS? ) Его ты куда хочешь тут воткнуть? )

В вэб клиента. Например в 1С в одном модуле ты можешь писать одновременно клиентский и серверный код. При этом клиентский код сильно ограничен.
и солнце б утром не вставало, когда бы не было меня
Re[87]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 12:52
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ты в этом примере демонстрируешь вообще другое. Возможность вызова .net кода из 1C. Ну так понятно что с этим нет проблем, если в 1C это специально предусмотрели. И с другими языками/платформами может быть аналогично. Непонятно что ты этим хотел показать.

S> Нет это не в 1С предусмотрели, а в Net. http://infostart.ru/public/238584/
S>А вот теперь покажи как можно использовать классы С++ раз это можно сделать аналогично.
S>Я к тому, что написать код аналогично 1С на C# нет проблем.

Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. )))
Re[87]: Java vs C# vs C++
От: alex_public  
Дата: 10.10.15 12:58
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>В принципе это верное утверждение. Осталось только два нюанса:

_>>1. Собственно сделать такую систему (т.е. переписать эти тонны скучного кода из 1C).
_>>2. Убедиться что это кому-то надо. Т.е. проверить, что есть ещё много народа, который считает, что программировать эти дела на C# удобнее чем на языке 1C.
S> Ну там полно говногода, который тянется от версии к версии. По сути 1С переходя на Управляемые Формы переписывало заново практически весь функционал.
S>В этом нет ничего страшного. А вот дивиденды можно нехилые срубить.

Нуу так вперёд.

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

А вот жирные продукты для больших корпорации пока в безопасности — там вряд ли кто настроен переходить на онлайн-сервисы. )))

_>>А откуда в данном обсуждение взялся JS? ) Его ты куда хочешь тут воткнуть? )

S> В вэб клиента. Например в 1С в одном модуле ты можешь писать одновременно клиентский и серверный код. При этом клиентский код сильно ограничен.

А ну да, если для веб-интерфейса, то это понятно. Это неизбежно во всех решениях на всех языках из-за текущей ситуации в браузерах. )
Re[88]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.10.15 13:44
Оценка:
Здравствуйте, alex_public, Вы писали:

S>>В этом нет ничего страшного. А вот дивиденды можно нехилые срубить.


_>Нуу так вперёд.

Я делаю все, что могу. Во всяком случае пытаюсь плыть против течения.
_>Кстати, пока что активно завоёвывают рынок всяческие онлайн бухгалтерии (со сдачей отчётности в налоговую онлайн) и т.п. Так что 1C угрожают скорее отсюда. И да, та, которой пользуюсь я, написана как раз на C#. Только это совсем другое решение, без всяких там скриптов и прочей кастомизации. Т.е. это полностью готовое решение в виде онлайн-сервиса, где только кликают мышкой.
Так везде тыкают мышкой. Что ты имеешь под понятием скрипты? А в 1С есть некоторый набор конфигураций. А бухгалтерия практически одна с небольшими изменения ми для упрощенки. Обычно делают обмен между заточенной по производство программой и бухгалтерией которая соответствует текущему законодательству. Кстати 1С больше зарабатывает не на 1С самой а на поддержке в виде дисков ИТС.
В 1С очень продвинутая генерация отчетов СКД http://infostart.ru/public/181176/
Кстати это в тему динамических запросов, где клиент может сам менять группировки, ограничения итд.

_>А вот жирные продукты для больших корпорации пока в безопасности — там вряд ли кто настроен переходить на онлайн-сервисы. )))


_>>>А откуда в данном обсуждение взялся JS? ) Его ты куда хочешь тут воткнуть? )

S>> В вэб клиента. Например в 1С в одном модуле ты можешь писать одновременно клиентский и серверный код. При этом клиентский код сильно ограничен.

_>А ну да, если для веб-интерфейса, то это понятно. Это неизбежно во всех решениях на всех языках из-за текущей ситуации в браузерах. )

Посмотрим куда рынок двинется. В любом случае на хлебушек с маслом заработать не проблема
А хочется, чего то прорывного, и его применение.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 10.10.2015 14:14 Serginio1 . Предыдущая версия .
Re[32]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 10.10.15 15:19
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.

_>·>И это ВНЕЗАПНО нужно делать и в плюсах, банальный vector<MyClass> может работать плохо, если, например, в классе куча полей, а тебя нужно последовательно читать только одно, вылезет structure of arrays и т.п.
_>Так а зачем я тогда буду делать такой MaClass? )))

1. Для группировки связанных по смыслу полей в одну сущность.
2. В других местах может быть оптимальнее именно vector<MyClass>

_>Кстати, куча полей — это сколько? ) Ты в курсе размера линии кэша современных процессоров? )


Смысл как раз в том, чтобы грузить в сумме меньше кэш линий при линейном обходе. И при применении structure of arrays это получится в тех случаях, когда размер интересующего поля (+alignment) не кратен размеру кэш линии — то есть очень часто (правда с разной эффективностью).
На C++ я делал такую трансформацию с помощью Boost.Fusion: на входе тип структуры — на выходе специальный контейнер, внутри которого несколько векторов, а снаружи он подражает vector<MyStruct>. Например при доступе по индексу возвращается структура с ссылками на поля (то есть внешне выглядит как объект исходной структуры), и если при линейном обходе используются только некоторые из всех полей из этой структуры со ссылками, то это факту выраждается в обход соответствующих внутренних массивов, не затрагивая массивы неиспользуемых полей.
Re[37]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.10.15 20:14
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Я про количество и глубину, а не порядок вызова.


EP>Глубина тоже никак не меняется от введения этой подстраховки


Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.

Вобщем, мне стало скучно.
Re[33]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.10.15 20:18
Оценка:
Здравствуйте, ·, Вы писали:

I>>·>Enterprise apps, web apps, finance, IDE в конце концов.

I>>Кроме finance, С++ уже давно ушел из этих областей, там нет
·>Не "ушел" а тупо не взлетел. Взлетали всякие бейсики, перлы, питоны, пхп, и прочее.

Все эти вещи когда то писали на Си/С++. Питон, перл, пхп — все это выстрелило уже после того, как С++ оттуда ушел.

I>>IDE и по сей день пишутся на плюсах.

·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают.

Это единственные IDE что ли ?

I>> finance — в HFT плюсы в полный рост.

·>Наравне с Java.

Джава в роли догоняющего.

I>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap

·>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.

По факту запрещено многие вещи вызывать именно из за этого ограничения.
Re[38]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 10.10.15 20:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Я про количество и глубину, а не порядок вызова.

EP>>Глубина тоже никак не меняется от введения этой подстраховки
I>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.

Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил

I>Вобщем, мне стало скучно.


Удачи
Отредактировано 10.10.2015 20:47 Evgeny.Panasyuk . Предыдущая версия .
Re[26]: Java vs C# vs C++
От: · Великобритания  
Дата: 10.10.15 20:53
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Не понял. Скажем, установка affinity для потока — делаешь через JNI-вызов ядерной функции. Реализовывать ничего не надо.

Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели
https://www.youtube.com/watch?v=-6nrhSdu--s
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 00:13
Оценка:
Здравствуйте, ·, Вы писали:

dot>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели


Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.

dot>https://www.youtube.com/watch?v=-6nrhSdu--s


К чему это видео? Там сорок минут рассказывается об affinity
Re[39]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.15 10:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.


EP>Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил


Алё, я эти издержки вообще не считаю. На кой ляд ты доказываешь мне, что они ничтожны ?
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 11:46
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>·>Enterprise apps, web apps, finance, IDE в конце концов.

I>>>Кроме finance, С++ уже давно ушел из этих областей, там нет
I>·>Не "ушел" а тупо не взлетел. Взлетали всякие бейсики, перлы, питоны, пхп, и прочее.
I>Все эти вещи когда то писали на Си/С++. Питон, перл, пхп — все это выстрелило уже после того, как С++ оттуда ушел.
Что-то сомневаюсь. C ещё может быть, С++ — очень вряд ли. Но С просто старше. А уж LAMP всегда был классикой. Веб на С — это либо экзотика, либо старьё.

I>>>IDE и по сей день пишутся на плюсах.

I>·>Eclipse? IntelliJ? Да даже Студию уже на # переписывают.
I>Это единственные IDE что ли ?
Из наиболее развитых. Сравнивать QT Creator с MSVS... Даже Delphi и то были мощнее чисто-С++ IDE (по крайней мере мне известных). А так я и на бейсике IDE напишу.

I>>> finance — в HFT плюсы в полный рост.

I>·>Наравне с Java.
I>Джава в роли догоняющего.
Примерно как С++ догоняет Кобол.

I>>>Off-heap и есть архитектура. Все что ты выделяешь теперь, надо делать через этот off-heap

I>·>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.
I>По факту запрещено многие вещи вызывать именно из за этого ограничения.
Что запрещено? Не понял мысль.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[40]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 11:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.

EP>>Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил
I> Алё, я эти издержки вообще не считаю. На кой ляд ты доказываешь мне, что они ничтожны ?

В этом случае других издержек нет
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 11:58
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели

EP>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
И что GC-free? На плюсах так же будешь писать allocation free.
И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого. А в плюсах выбора нет.
Да и GC-free не так страшен, как его малюют.

dot>>https://www.youtube.com/watch?v=-6nrhSdu--s

EP>К чему это видео?
К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL, и java позволяет делать ровно то же что и С++, может быть синтаксис не очень, и код непривычен, но помехой не является.

EP>Там сорок минут рассказывается об affinity

Не только об аффинити, но ещё о тулзах разных. Да и, как оказывается, просто поставить affinity — станет только медленнее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 12:16
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели

EP>>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
dot>И что GC-free?

И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.

dot>На плюсах так же будешь писать allocation free.


Отдельный/специальный аллокатор это не allocation free.

dot>И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого.


Zing например не решит проблему индерекций/структур.

dot>А в плюсах выбора нет.


GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
Причём реализации возможны как библиотечные, так и runtime.

dot>>>https://www.youtube.com/watch?v=-6nrhSdu--s

EP>>К чему это видео?
dot>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,

Из этого видео никак не следует что "большинство выкрутасов это не извращения java".

dot>и java позволяет делать ровно то же что и С++,


Всё же не то же, но допустим.

dot>может быть синтаксис не очень, и код непривычен, но помехой не является.


И уровень кода ниже чем C, и больше его во много раз.
Re[30]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 11.10.15 12:24
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.

EP>Причём реализации возможны как библиотечные, так и runtime.

И как эти ГЦ делают обход указателей в структуре? По-моему, без рефлексии времени компиляции это трудновато.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 12:30
Оценка:
Здравствуйте, T4r4sB, Вы писали:

EP>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.

EP>>Причём реализации возможны как библиотечные, так и runtime.
TB>И как эти ГЦ делают обход указателей в структуре? По-моему, без рефлексии времени компиляции это трудновато.

Да, но есть варианты. В библиотечных GC например рефлексия на макросах (а-ля BOOST_FUSION_*), либо gc_ptr<T> в конструкторе взводит флаг в битовом массиве. Runtime GC обычно консервативные.
Отредактировано 11.10.2015 12:32 Evgeny.Panasyuk . Предыдущая версия .
Re[32]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 11.10.15 12:41
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Да, но есть варианты. В библиотечных GC например рефлексия на макросах (а-ля BOOST_FUSION_*), либо gc_ptr<T> в конструкторе взводит флаг в битовом массиве. Runtime GC обычно консервативные.


Рефлексия на макросах — это когда поля объявляются не через Type name, а через BOOST_FUSION_FIELD(Type, name)?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 12:43
Оценка:
Здравствуйте, T4r4sB, Вы писали:

EP>>Да, но есть варианты. В библиотечных GC например рефлексия на макросах (а-ля BOOST_FUSION_*), либо gc_ptr<T> в конструкторе взводит флаг в битовом массиве. Runtime GC обычно консервативные.

TB>Рефлексия на макросах — это когда поля объявляются не через Type name, а через BOOST_FUSION_FIELD(Type, name)?

Почти, например BOOST_FUSION_DEFINE_STRUCT.
Re[28]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 14:49
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Не сможет — чуть тормозить начнёт. А если человек не сможет доказать передачу указателей — всё круто и непредсказуемо навернётся.

EP>А зачем человеку доказывать? Например:
EP>Результат может содержать ссылку на этот unique, а может не содержать. Человек может например просто знать из документации что в результирующем объекте нет этого unique.
Тут мне кто-то рассказывал, что надо голые указатели использовать при передаче между потоками.

EP>Анализатору же придётся это доказывать проинлайнив весь код.

Да пусть доказывает, он железный, зарплату не просит.

dot>>Да знаю я язык прекрасно, опыта 5+ лет, просто уже несколько лет не использовал на работе.

EP>Так ведь по-разному используют. Есть действительно много когда где лепят *_ptr на каждый чих. Виной тому отчасти например некоторые книги — есть авторы которые пишут сразу по трём языкам C++/C#/Java, просто копируя примеры с небольшими изменениями из книги в книгу. И отчасти те кто застрял в начале 90-х.
К сожалению официального кода нет. Каждый пишет по разному.

EP>>>Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++.

dot>>... либо битый указатель.
EP>*_ptr не спасают от битых указателей, их основанная цель это выражение семантики владения в коде, отсюда и имена shared/unique/scoped.
Как более безопасный подход — оно вроде работает. Если ты будешь использовать в коде _ptr а не * и &, то нарваться на битый указатель практически невозможно.

EP>Это изменение контракта, которое прекрасно выражается в системе типов — у doSomething поменяется тип параметра и приведённый код не скомпилируется

Поменяется с чего на что? как было (Widget &w) так и останется, если не лепить _ptr на каждый чих.

EP>>>Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?

dot>>Тем что объект пойдёт на стек или в регистры. Какие аллокации?
EP>Ещё раз. Прочитай свои слова выше (выделено), и ниже:
EP>

dot>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

EP>Теперь скажи каким образом здесь поможет EA.
Что-то я тут фигню какую-то написал. Ссылка на стеке, конечно, как и unique_ptr, а сам массив в куче, как и unique_ptr, при выходе из стека — пропадёт ссылка. При сборке Eden Space оно и грохнется, не совсем при выходе из стека, но очень близко.
А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.

EP>>>>>Ты что, они же есть в реальности данной нам в ощущениях железом. Это же например самый быстрый способ указать на конкретный элемент массива, или передать куда-нибудь его часть.

dot>>>>Железом нам даны адреса, а не указатели.
EP>>>А указатель что по-твоему хранит?
dot>>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.
EP>Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет.
Ты так говоришь, как будто это что-то плохое.

EP>>>>>Не грохнется — у него нет зависимости O(N) от количества живых объектов.

dot>>>>new/malloc и delete/free работают не за O(1) внезапно.
EP>>>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.
dot>>Так и разные алгоритмы GC есть. И столько всего можно крутить... И я уверен, что вариантов даже больше, ибо ссылка в jvm более абстрактна чем указатели в плюсах, а значит больше простора для оптимизаций.
EP>Так вот покажи GC не с сублинейной сложностью, желательно ещё чтобы был более-менее популярен.
Если вдруг GC начинает работать в режиме, что его сложность становится O(N) — ты делаешь что-то не то, тебе надо крутить настройки или даже изменять код.

dot>>>>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.

EP>>>Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность
dot>>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.
EP>Штуки типа cuckoo hashing не на ровном месте появились.
Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).

EP>Для hashtable есть альтернативы с гарантированной сублинейной сложностью, и там где гарантия нужна — их и используют. Причём можно комбинировать — снаружи hashtable, а внутри узлов при превышении лимита что-то логарифмическое — тогда будет суб-линейная гарантия.

Так и gc не лыком шиты.

dot>>>>Я и не изобретаю общую теорию всего, а решаю практические задачи.

EP>>>А кто-то изобретает? В Java нет структур — это практический недостаток и факт
dot>>Зато он даёт больший простор для JVM/JIT/etc.
EP>Какой простор? Всё равно есть те же int/double, с семантикой как у структур
Примитивы — значения фиксированного размера, структуры — произвольного.

dot>>Ну вот есть структуры в C# — а толку? Где LL?

EP>В C# свои проблемы. У тех же структур есть много ограничений. Но тем не менее они есть, и не нужно их эмулировать руками.
Они есть, конечно, но какой от них смысл?

dot>>>>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.

EP>>>Проблема в том для каждого типа элемента нужен будет отдельный Java код.
dot>>Не смертельно.
EP>Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код.
Комбинации чего? Сколько их? (только практику плз, а не теоретические рассуждения) Если можно было бы — писали бы и на асме, в LL все средства идут в ход.

dot>>>>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.

EP>>>Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.
dot>>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.
EP>А например в хэш-таблице?
Если значение большое, то индирекция нужна, иначе сам массив хеш-таблицы будет слишком большим и не помещаться в кеш.
Если значение маленькое, то это скорее всего будет примитив.

EP>>>>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры

dot>>>>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
EP>>>Далеко не всегда. Да и почему внезапно-то?
dot>>Настолько же ВНЕЗАПНО как и в случае с GC.
EP>Ок, допустим, в случае чего by-value заменим, не проблема — пара закорючек.
И поимеем битые указатели.

EP>В случае с GC что будешь делать?

Подстрою GC.

dot>>>>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.

EP>>>В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.
dot>>Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).
EP>Нет же, случаи принципиально разные. Где-то наверху callstack делаем:
EP>
EP>{
EP>    vector<Foo> many_values(N);
EP>    // ...
EP>    pass_by_reference(many_values);
EP>}
EP>
ничего не "засучивая".

EP>Этот массив, по терминам GC, спокойно может попасть под классификацию OG
Сам массив это ровно одна ссылка. Элементы — пусть лежат, если ты не создаёшь|удаляешь их постоянно, а просто меняешь их поля — GC вообще не парится. GC ведёт себя плохо если постоянно меняется граф объектов долго лежащих в памяти. Собственно это соответствует сложному жонглированию владением в C++, где это запросто приведёт к битым указателям, если у вас в команде не Александреску с Страуструпом под руководством Кнута.

dot>>>>Зато гарантируется отсутствие битых ссыслок.

EP>>>Да, это плюс — с этим никто не спорил
dot>>Притом очень ценный плюс, что он перевешивает весь колбасокод с оффхипами и т.д.
EP>Этот же плюс есть в C#, в котором "колбасокод" нужен реже, как раз за счёт структур
Он нужен реже, ибо LL на нём никто не пишет, поколбасятся, да выкинут и дальше пилят веб-сайтики с формочками.

dot>>>>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.

EP>>>А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки
dot>>Не положит, к сожалению. Иначе бы уже давно компилировали.
dot>>Вся эта указательная магия и арифметика, юнионы, и прочий low level не может быть покрыт GC и JVM ссылками, поэтому при компиляции С/C++ память будет внутри byte[].
EP>Конечно будет, и это одна из причин почему положит на лопатки.
EP>Именно так и происходит
Автор: Evgeny.Panasyuk
Дата: 06.06.15
в Emscripten, который компилирует C++ в JS.

EP>И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить.
Ну и кому эти микробенчмарки нужны? Ты давай пример системы на плюсах, компилированных под jvm.
Это же полная лажа. Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.
На Скале, кстати, вроде что-то есть.

Кстати, это, конечно, очень субъективно, но когда я искал работу (London), я всегда писал Java/C++ и выбирал finance. И из ~сотни интерьвю не было ни одного С++. Выводы, конечно, можно сделать разные... но всё же.

EP>>>Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.

EP>>>При этом аналогичную выразительность можно достичь не делая проблемы анализаторам.
dot>>Может и можно... Я сходу не могу сделать такое заявление.
EP>>>Те же структуры есть в C#.
dot>>А толку-то от них...
EP>Не нужно вручную нарезать массивы на структуры
И что это даёт? Что позволяет добиться?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[40]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 14:54
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.

EP>>>В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
EP>>>Круто — чё
dot>>Если очень надо и до машкодов дойдёшь. Но это очень экзотические случаи.
EP>Так дело даже не сложности создания, а в том что это всё может тормозить. То есть получается взяли самое плохое от обхода живых и мёртвых объектов — обходим все.
Тут ведь как... может тормозить, а может и не тормозить! На практике — не тормозит.

EP>>>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>

dot>>Двигаешь pos и получаешь элемент.
EP>То есть предлагаешь не использовать List? Или писать свой?
List это интерфейс.

dot>>Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?

EP>Убрать лишние индерекции из random access — например элементарный бинарный поиск.
EP>Та же сортировка или например min/max heap на основе массива, а-ля std::pop_heap.
В этом случае массив в котором ты делаешь бинарный поиск должен быть компактным, содержащим минимум по которому осуществляется поиск, чтобы в кеш поместился. А если у тебя каждый элемент большой, то всё становится бессмысленно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 15:13
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.

EP>>>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>>>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
dot>>Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.
EP>Так они долгоживущие по твоей терминологии или нет?
Долгоживущие. Они живут и если граф объектов не модифицировать, то gc их трогать не будет.

dot>>>>Это можно лечить настройкой GC, испоьзованием разных приёмов (flyweight или пулов например)

EP>>>Причём тут flyweight? Объекты-то изменяются.
dot>>Смотря как изменяются.
EP>flyweight-ы обычно неизменяемые.
Всяко можно наворотить. Берём flyweight A и "измнеяем" его свойство X, т.е. находим другой flyweight B.
Или flyweight может иметь часть неизменную, а часть изменяемую. В общем нафантазировать можно много. Приёмов — масса.

dot>>>>Бывает. Лечится. Алгоритмы — сила.

EP>>>Конечно сила, о чём я тебе и говорю.
EP>>>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
dot>>Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.
EP>Например?
Ну один из очевидных — перемещение данных, из одной области памяти (eden) в другую (tenured) или дефрагметация. Или решать где размещать объекты — на стеке, в регистрах или куче — в процессе исполнения программы.

dot>>Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.

EP>Ещё раз, зачем обмениваться практически мёртвыми объектами между рабочими потоками?
Потому что эти потоки могут захотеть использовать те же данные.

EP>>>>>Критический поток поставит его в очередь, а сам удалять не будет.

dot>>>>И возникнет та же проблема, которой ты меня мучил — а что если он будет ставить в очередь быстрее, чем эта очередь разгребаться?
EP>>>Проблема вообще-то была в другом. Если по аналогии — в том что грубо говоря pop одного элемента очереди линейно зависит от её размера. Здесь же такой зависимости нет.
dot>>Не одного элемента, а всей очереди. GC за цикл собирает не один объект.
EP>Чтобы убрать малое колличество мусорных объектов, GC приходится обходить большое количество живых. И скорость сбора мусорных объектов зависит от количества живых. В этом и аналогия.
От количества активных и живых.

dot>>>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?

EP>>>Аналогично — а почему тогда GC?
dot>>Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.
EP>>>Какой объем реализации? На C++ — меньше ста строк.
dot>>Ну вот... сейчас ещё начнём строки считать... увольте.
EP>Достаточно грубой прикидки. Если объём отличается на порядки — то с тем же успехом можно и компилятор модифицировать.
Не с тем же. Который из? Не надо путать изобретение своего языка с использованием предоставленных платформой документированных средств.

dot>>Перегрузка чего? Это же примитивы.

EP>На C++ это отдельные типы. И по разным типам можно сделать разные перегрузки.
Ну да, подходы другие, средства другие. Бывает.

dot>>И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.

EP>Ты же сказал что "и прочие С++ фишки можно реализовать в java" — мы в этой ветке сейчас и находимся.
Я не обещал реализацию синтаксиса С++ в Яве. Но, скажем, явное управление памятью сделать можно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 15:27
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Неправда. Будет не исключение, а undefined behaviour, в дебаг-моде в лучшем случае может и грохнется. А если учесть всякие кастомные аллокаторы...


_>Undefined behaviour это по стандарту языка, без учёта работы ОС. Ну т.е. да, для каких-нибудь микроконтроллеров там действительно будет порча памяти, но на этих МК такие вещи как Java/C# вообще не живут. А в любой современной ОС мы получим соответствующее исключение.

Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.

_>P.S. Ну и да, не забываем, что это мы тут развлекаемся обсуждением заведомо некорректного кода. ))) Типа а вот если мы специально подставим компилятор вот так, то в каком языке какие ошибки будут... ))) В реальном коде такое естественно не встречается.

И ты правда не видел битых указателях в реальных проектах? Укажи, плиз, номер твоей планеты в тентуре.

_>P.P.S. Я там в предыдущем сообщение опечатку сделал (типа из-за симметрии 2 строки на 2 строки) — сейчас исправил. )

Гы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 15:33
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>·>Про все случаи я уверен, что нет. Просто устанешь и начнёшь лепить что-то дефолтное, забивая на эффективность.

_>>>Фокус в том, что дефолтное в C++ как раз и есть самое быстрое для 99% задач. )
_>·>Это которое? Я ещё забыл варианты "MyClass[]", "MyClass*[]", все комбинации "xxx_ptr<vector<xxx_ptr<MyClass> >"
_>Дефолтное — это value type и контейнеры stl. Есть парочка редких случаев, когда применение этих инструментов приводит к не самому оптимальному кода (и тогда как раз делают всяческие кастомные аллокаторы и т.п.), но лично я на них натыкался исключительно в обсуждениях на форумах и т.п., а не в личной практике.
В дефолтном случае и GC замечательно работает. А вот эти обсуждаемые извращения в Яве это и есть те самые редкие случаи.

_>>>А что, разве не все программисты такое обдумывают на автомате в процессе проектирования?

_>·>А ты часто обдумываешь в какие регистры процессора какая переменная попадёт?
_>Совершенно не обдумываю, причём по разным причинам в двух разных случаях. В случае отсутствия необходимости в быстродействие (кстати в этом случае у меня скорее Питон в руках будет) понятно что не обдумываю потому что безразлично. А в случае необходимости высокого быстродействия и использования C++ тоже не обдумываю, потому как знаю, что оптимизатор современных компиляторов C++ создаст код лучше любого эксперта в ассемблере.
Собственно та же ситуация и с GC.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 15:50
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Ну если смотреть на этот список с точки зрения C++, то там вообще нет никаких извращений. Вполне нормальные архитектурные элементы не приводящие ни к каким ужасам.

_>·>"Извращения" это непривычный код, не так как учат в букварях.
_>Лично я не увидел в этом списке чего-то необычного, заставившего писать непривычный код.
А тебе вообще доводилось писать LL код?

_>·>Почитай, кстати там комменты — о том же рассуждают. Хорошо сказано:

_>·>

Java is a great platform none the less, but I think it’s biggest advantage is that ordinary business logic (90% of your code?) can still depend on GC and safety features and make use of highly tuned and tested libraries written with Unsafe. This is a great trade-off between getting the last 5% of perf and being productive. A trade-off that makes sense for a lot of people but a trade-off none the less. Writing complicated application code in C/C++ is a nightmare after all.

_>Рассуждения без аргументов не интересны. А если попробовать взглянуть на реальность, то "неожиданно" обнаруживается, что почти все самые сложные современные приложения написаны на C/C++. Причём не только системные, типа ОС, но самые пользовательские, типа браузеров.
В ФФ бОльшая пользовательская часть это js, xul и прочее. А вообще браузер системная вещь — основное назначение — взаимодействие с железом и ОС. Не путай с прикладными приложениями, типа очередной бухгалтерии или склада.

_>>>Если же взглянуть с точки зрения Java, то один пункт действительно становится извратом, реализация которого будет требовать страшного кода. Это пункт "Keep your reads sequential". Кстати как раз это мы обсуждали в соседнем сообщение.

_>·>И это ВНЕЗАПНО нужно делать и в плюсах, банальный vector<MyClass> может работать плохо, если, например, в классе куча полей, а тебя нужно последовательно читать только одно, вылезет structure of arrays и т.п.
_>Так а зачем я тогда буду делать такой MaClass? ))) Кстати, куча полей — это сколько? ) Ты в курсе размера линии кэша современных процессоров? )
"Дефолтное — это value type и контейнеры stl" и даст тебе тот самый жирный MyClass.
Кеш в районе всего лишь нескольких мегабайт — копейки же, миллиончик элементов — и упс, кончилось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 16:04
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели

EP>>>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
dot>>И что GC-free?
EP>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.
На плюсах были бы те же извращения.

dot>>На плюсах так же будешь писать allocation free.

EP>Отдельный/специальный аллокатор это не allocation free.
Хотелось бы посмотреть. Особенно когда дело дойдёт до многопоточности, фрагментации, эффективности по памяти... И в итоге выйдет что никакого чуда-то и нет.

dot>>И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого.

EP>Zing например не решит проблему индерекций/структур.
Конечно не решит... решать ибо нечего.

dot>>А в плюсах выбора нет.

EP>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>Причём реализации возможны как библиотечные, так и runtime.
Ой, да не прикалывайся.

there is no currently practical usage of C++11 GC interface as there is no compiler which fully supports this API in the meantime

http://stackoverflow.com/questions/18005430/are-there-practical-uses-of-c11s-garbage-collection-abi

А всякие conservative gc как были игрушками, так и остались.
Единственный более менее нормальный gc на С++ это jvm.

dot>>>>https://www.youtube.com/watch?v=-6nrhSdu--s

EP>>>К чему это видео?
dot>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,
EP>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".
Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".

dot>>может быть синтаксис не очень, и код непривычен, но помехой не является.

EP>И уровень кода ниже чем C, и больше его во много раз.
Не знаю что тут значит "уровень кода", но это не важно. Все преимущества java никуда не деваются.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 16:25
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>>>Кстати, если интересно, можете посмотреть какие "извращения java" сейчас популярны в LMAX. А то всякие offheap и байт-буферы уже устарели

EP>>>>Там конкретно упоминается GC-free — то есть один из вариантов как раз байт-буферы.
dot>>>И что GC-free?
EP>>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.
dot>На плюсах были бы те же извращения.

Это демагогия чистой воды, непонятно на кого рассчитанная
В ролике действительно есть описание тех аспектов которые были бы на C++, их даже извращением трудно назвать — банальное affinity.
Помимо этого есть извращения с GC-free, off-heap — их выступающий упомянул только вскользь, мол да — надо как-то решать. Вот этих извращений на C++ бы не было

dot>>>И то, там вроде упомянули, что либо GC-free либо Zing-за-дорого.

EP>>Zing например не решит проблему индерекций/структур.
dot>Конечно не решит... решать ибо нечего.

Никто вручную не нарезает массивы на структуры? Сам же даже предложил.

dot>>>А в плюсах выбора нет.

EP>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>>Причём реализации возможны как библиотечные, так и runtime.
dot>Ой, да не прикалывайся.

Не прикалываюсь

dot>

there is no currently practical usage of C++11 GC interface as there is no compiler which fully supports this API in the meantime

dot>http://stackoverflow.com/questions/18005430/are-there-practical-uses-of-c11s-garbage-collection-abi
dot>А всякие conservative gc как были игрушками, так и остались.
dot>Единственный более менее нормальный gc на С++ это jvm.

Например Boehm GC есть очень давно, и используется в реальных проектах

dot>>>>>https://www.youtube.com/watch?v=-6nrhSdu--s

EP>>>>К чему это видео?
dot>>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,
EP>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".
dot>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".

От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул.

dot>>>может быть синтаксис не очень, и код непривычен, но помехой не является.

EP>>И уровень кода ниже чем C, и больше его во много раз.
dot>Не знаю что тут значит "уровень кода", но это не важно.

На C есть структуры — это выше уровнем чем ручное нарезание буферов.

dot>Все преимущества java никуда не деваются.


Конечно теряются — например появляются те самые расстрелы памяти
Re[39]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 16:43
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>>>Об этом и речь — что по регионам, а не отдельным затронутым объектам. Поэтому я и сказал "малом количестве", а не в одном.

EP>>>>>>И то — это отслеживание имеет свою цену, которая размазывается по всему коду.
dot>>>>>Я уже упоминал, что gc плохо работает в случае большого числа короткоживущих и толпы долгоживущих. При наличии среднеживущих — производительность падает.
EP>>>>А как ты называешь объекты которые живут долго, но не до конца работы приложения?
dot>>>Old Gen. Данные этих объектов можно менять свободно, но не трогать сильно указатели.
EP>>Так они долгоживущие по твоей терминологии или нет?
dot>Долгоживущие. Они живут и если граф объектов не модифицировать, то gc их трогать не будет.

А если менять — то будет

dot>>>>>Бывает. Лечится. Алгоритмы — сила.

EP>>>>Конечно сила, о чём я тебе и говорю.
EP>>>>И при логарифмической сложности, и при линейной, чем больше N тем медленнее — но разница между ними колоссальная. И в результате ситуации совершенно разные, а ты говоришь "тоже не поздоровится"
dot>>>Так вот строгость ссылок явы позволяет применять гораздо более хитрые алгоритмы.
EP>>Например?
dot>Ну один из очевидных — перемещение данных, из одной области памяти (eden) в другую (tenured) или дефрагметация.

Дефрагментация реализуется и без GC.

dot>Или решать где размещать объекты — на стеке, в регистрах или куче — в процессе исполнения программы.


Такой выбор и в C++ реализуется. Причём например помимо стэка можно размещать ещё и внутри самих структур — Small Size Optimization.

dot>>>Так ты не знаешь в каком именно потоке и когда он уйдёт в ноль и что именно произойдёт в момент ухода в ноль. В этом и суть GC. Да, узнать можно, но это очень трудоёмко. Компьютер с этим справляется в подавляющем большинстве случаев лучше и надёжнее.

EP>>Ещё раз, зачем обмениваться практически мёртвыми объектами между рабочими потоками?
dot>Потому что эти потоки могут захотеть использовать те же данные.

Каким образом? У них нет на них ссылки. Ты контекст потерял? Мы обсуждаем случай когда счётчик ссылок ушёл в ноль

dot>>>>>Не С++. Почему именно С++, а не С, не Алгол, не Фортран, не Паскаль, не ассемблер?

EP>>>>Аналогично — а почему тогда GC?
dot>>>Потому что управление памятью — трудоёмкий процесс в прикладных приложениях. Автоматизировать его — дело святое.
EP>>>>Какой объем реализации? На C++ — меньше ста строк.
dot>>>Ну вот... сейчас ещё начнём строки считать... увольте.
EP>>Достаточно грубой прикидки. Если объём отличается на порядки — то с тем же успехом можно и компилятор модифицировать.
dot>Не с тем же. Который из?

Clang.

dot>Не надо путать изобретение своего языка


Это изменение существующего компилятора, а не изобретение языка.

dot>>>И вообще, чего опять о языке, мы же о GC вроде? Ну возьми Скалу, там есть перегрузка.

EP>>Ты же сказал что "и прочие С++ фишки можно реализовать в java" — мы в этой ветке сейчас и находимся.
dot>Я не обещал реализацию синтаксиса С++ в Яве.

Автоматическая перегрузка по типам которые генерируются в зависимости от состава выражения — вполне себе НЕ синтаксическая фича.

dot>Но, скажем, явное управление памятью сделать можно.


Явное в каком смысле?
Re[41]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 16:52
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>>>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.

EP>>>>В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
EP>>>>Круто — чё
dot>>>Если очень надо и до машкодов дойдёшь. Но это очень экзотические случаи.
EP>>Так дело даже не сложности создания, а в том что это всё может тормозить. То есть получается взяли самое плохое от обхода живых и мёртвых объектов — обходим все.
dot>Тут ведь как... может тормозить, а может и не тормозить! На практике — не тормозит.

А ты проверял? Или имеешь в виду не то что "не тормозит", а то что "тормозит для нас приемлемо"?

EP>>>>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>

dot>>>Двигаешь pos и получаешь элемент.
EP>>То есть предлагаешь не использовать List? Или писать свой?
dot>List это интерфейс.

Точно, это в C# List. ОК, писать свои ArrayList и т.п.?

dot>>>Притом чтобы это всё имело смысл — pos должен двигаться строго вперёд, до следующего элемента, это и будет оптимизация sequencial access, а какие всякие другие алгоритмы ты тут хочешь воротить?

EP>>Убрать лишние индерекции из random access — например элементарный бинарный поиск.
EP>>Та же сортировка или например min/max heap на основе массива, а-ля std::pop_heap.
dot>В этом случае массив в котором ты делаешь бинарный поиск должен быть компактным, содержащим минимум по которому осуществляется поиск, чтобы в кеш поместился.

Никому он ничего не должен, применим в том числе и для больших массивов.

dot>А если у тебя каждый элемент большой, то всё становится бессмысленно.


Да даже для больших элементов имеет смысл снижать индерекции. Например массив строк: на Java у каждой строки будет две индерекции, в то время как на C++ будет одна либо ноль, что даже чаще.
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 11.10.15 18:10
Оценка:
Здравствуйте, ·, Вы писали:

·>Из наиболее развитых. Сравнивать QT Creator с MSVS... Даже Delphi и то были мощнее чисто-С++ IDE (по крайней мере мне известных). А так я и на бейсике IDE напишу.


А ты их сам сравнивал? ) Я вот сравнивал и MSVS и Eclipse и Netbeans и QtCreator. MSVC кстати весьма слабенький для C++, если не пользоваться VisualAssist'ом (отдельная платная штука). Eclipse и Netbeans весьма похожи между собой по возможностям и при этом существенно отличаются от того же QtCreator. У них используется модель полного анализа кода, которая позволяет такую возможность как подчёркивать невалидный код до компиляции и т.п.. Но цена у этого жуткие тормоза. Ну точнее если работать только с ними, то постепенно привыкаешь к тормознутости IDE... Но если вдруг при этом включить QtCreator, то такое впечатление что он просто мгновенный. Но при этом он делает не полный анализ кода... В принципе выбор между этими продуктами является делом вкуса. Но говорить о явном преимуществ какой-то из них странно.

Кстати, недавно одному моему товарищу, работающему в основном в мире Java, потребовалось сделать приложение с GUI на C++. Он взял библиотеку Qt (по моему совету) и соответственно QtCreator в качестве IDE (ради удобного встроенного редактора форм/сигналов и т.п.). Так вот он был в полном восторге (особенно от всяческих автоматических компоновщиков и их поддержке в редакторе, управлением сигналами и т.п.) от этого инструмента (накидал довольно сложный GUI за несколько дней), причём во многом он удивлялся что так вообще можно (в своём java мире он такого не встречал).
Re[37]: Java vs C# vs C++
От: alex_public  
Дата: 11.10.15 18:24
Оценка:
Здравствуйте, ·, Вы писали:

_>>Undefined behaviour это по стандарту языка, без учёта работы ОС. Ну т.е. да, для каких-нибудь микроконтроллеров там действительно будет порча памяти, но на этих МК такие вещи как Java/C# вообще не живут. А в любой современной ОС мы получим соответствующее исключение.

·>Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.

Ну так у меня же мало практики в написание заведомо некорректного кода. Я вообще сам delete раз год вижу, даже с корректным кодом. А тут такое... )))

_>>P.S. Ну и да, не забываем, что это мы тут развлекаемся обсуждением заведомо некорректного кода. ))) Типа а вот если мы специально подставим компилятор вот так, то в каком языке какие ошибки будут... ))) В реальном коде такое естественно не встречается.

·>И ты правда не видел битых указателях в реальных проектах? Укажи, плиз, номер твоей планеты в тентуре.

В своих, ушедших в продакшен, — не видел. )
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 11.10.15 18:50
Оценка:
Здравствуйте, ·, Вы писали:

_>>Дефолтное — это value type и контейнеры stl. Есть парочка редких случаев, когда применение этих инструментов приводит к не самому оптимальному кода (и тогда как раз делают всяческие кастомные аллокаторы и т.п.), но лично я на них натыкался исключительно в обсуждениях на форумах и т.п., а не в личной практике.

·>В дефолтном случае и GC замечательно работает. А вот эти обсуждаемые извращения в Яве это и есть те самые редкие случаи.

Нет, это как раз совсем разные случаи. Единственный сценарий, на котором GC начинает конкурировать с обычной работой с памятью в C++ — это режим создания/удаления множества мелких объектов в куче. Так вот этот режим в C++ встречается на очень редком классе задач (и для них уже есть смысл рассматривать спец. аллокаторы и т.п.). И задачи типа реалтайма или высокой нагрузки точно не относятся к этому исключению — там как раз эффективны стандартные техники C++.

В то же время в Java режим создания/удаления множества мелких объектов в куче — это норма. И хотя GC не так плохо справляется тут, но он намного отстаёт от C++ на большинстве задач, т.к. в C++ в этих случаях используется другой режим (который априори быстрее). И только в том случае, когда и в C++ необходимо плодить сущности типа shared_ptr, быстродействие может сравниться (при условие, что в C++ не будем вводить кастомные извращения).

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

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

_>>·>А ты часто обдумываешь в какие регистры процессора какая переменная попадёт?

_>>Совершенно не обдумываю, причём по разным причинам в двух разных случаях. В случае отсутствия необходимости в быстродействие (кстати в этом случае у меня скорее Питон в руках будет) понятно что не обдумываю потому что безразлично. А в случае необходимости высокого быстродействия и использования C++ тоже не обдумываю, потому как знаю, что оптимизатор современных компиляторов C++ создаст код лучше любого эксперта в ассемблере.
·>Собственно та же ситуация и с GC.

Абсолютно не такая же. Напомню, что мы здесь обсуждали возможности JIT выбрать расположение и типы данных (куча/стек, ссылка/значение и т.д.) наиболее оптимальным способом. И в отличие от качества генерирования ассемблерного кода оптимизаторами C++, тут ситуация даже не приблизилась к идеалу. И я сомневаюсь что приблизится когда-нибудь, т.к. тут задача намного сложнее.
Re[88]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 18:51
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ты в этом примере демонстрируешь вообще другое. Возможность вызова .net кода из 1C. Ну так понятно что с этим нет проблем, если в 1C это специально предусмотрели. И с другими языками/платформами может быть аналогично. Непонятно что ты этим хотел показать.

S>> Нет это не в 1С предусмотрели, а в Net. http://infostart.ru/public/238584/
S>>А вот теперь покажи как можно использовать классы С++ раз это можно сделать аналогично.
S>>Я к тому, что написать код аналогично 1С на C# нет проблем.

_>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. )))

Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту
Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов.
Давай прямо сейчас.
Это еще раз подтверждение того, что ты невнимательно читаешь ссылки

Что было понятно то основной метод такой обертки для вызова свойства метода реального объекта.
 public object InvokeMember(string name, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, object target, object[] argsOrig, System.Reflection.ParameterModifier[] modifiers, System.Globalization.CultureInfo culture, string[] namedParameters)
        {        // Unwrap any AutoWrap'd objects (they need to be raw if a paramater)

            if (name == "[DISPID=-4]")
            {
                return new EnumVariantImpl(((IEnumerable)O).GetEnumerator());
            }


            object[] args = ПолучитьМассивРеальныхОбъектов(argsOrig);

            culture = CultureInfo.InvariantCulture;



            // Invoke whatever needs be invoked!
            object obj;

            try
            {

                if (T.IsEnum && !((invokeAttr & BindingFlags.InvokeMethod) == BindingFlags.InvokeMethod))
                    return ОбернутьОбъект(Enum.Parse(T, name));


                //           if (ЭтоСемерка)
                ПроверитьНаДоступКПолям(ref invokeAttr, args.Length);


                if (ЭтоТип)
                    obj = T.InvokeMember(name, invokeAttr, binder, null, args, modifiers, culture, namedParameters);
                else
                    obj = T.InvokeMember(name, invokeAttr, binder, O, args, modifiers, culture, namedParameters);

            }
            catch (Exception e)
            {
                ПоследняяОшибка = e;
                string Ошибка = "Ошибка в методе " + name + " " + e.Message + " " + e.Source;
  
                if (e.InnerException != null)
                    Ошибка = Ошибка + "\r\n" + e.InnerException.ToString();

                if (ВыводитьСообщениеОбОшибке)
                { 
                MessageBox.Show(Ошибка);
                MessageBox.Show(e.StackTrace);
                MessageBox.Show(invokeAttr.ToString());
                }
                throw new COMException(Ошибка);
            }

            // Так как параметры могут изменяться (OUT) и передаются по ссылке
            // нужно обратно обернуть параметры
            УстановитьИзмененияВМассиве(argsOrig, args);

            return ОбернутьОбъект(obj);
        }
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 19:05 Serginio1 . Предыдущая версия . Еще …
Отредактировано 11.10.2015 19:00 Serginio1 . Предыдущая версия .
Отредактировано 11.10.2015 18:55 Serginio1 . Предыдущая версия .
Re[33]: Java vs C# vs C++
От: alex_public  
Дата: 11.10.15 18:59
Оценка:
Здравствуйте, ·, Вы писали:

_>>Лично я не увидел в этом списке чего-то необычного, заставившего писать непривычный код.

·>А тебе вообще доводилось писать LL код?

Я же тебе уже даже примеры приводил. ) И да, оно не из области финансов. )))

_>>Рассуждения без аргументов не интересны. А если попробовать взглянуть на реальность, то "неожиданно" обнаруживается, что почти все самые сложные современные приложения написаны на C/C++. Причём не только системные, типа ОС, но самые пользовательские, типа браузеров.

·>В ФФ бОльшая пользовательская часть это js, xul и прочее. А вообще браузер системная вещь — основное назначение — взаимодействие с железом и ОС. Не путай с прикладными приложениями, типа очередной бухгалтерии или склада.

Да, написание приложения на C++ со встроенным скриптовым языком — это стандартная техника написания сложных и эффективных приложений. Это не только браузеры, но и тяжёлые игры и всякий профессиональный софт (CAD'ы, редакторы/рендереры и т.п.)и ещё много где. Проще вспомнить где такого нет. ))) Кстати, мы такое тоже используем.

Да, и браузер — это совсем не системный софт (с каких это пор взаимодействие с ОС стало признаком системного софта?), т.к. работает на обычном пользовательском уровне. Системный софт — это всяческие драйверы, сервисы и т.п. )

_>>Так а зачем я тогда буду делать такой MaClass? ))) Кстати, куча полей — это сколько? ) Ты в курсе размера линии кэша современных процессоров? )

·>"Дефолтное — это value type и контейнеры stl" и даст тебе тот самый жирный MyClass.
·>Кеш в районе всего лишь нескольких мегабайт — копейки же, миллиончик элементов — и упс, кончилось.

Хыхы, в данном случае важнее размер не всего кэша, а именно его линий (в соотношение с размером самого объекта). А так же очевидная для предсказателя последовательность выборки.
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 19:11
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Не сможет — чуть тормозить начнёт. А если человек не сможет доказать передачу указателей — всё круто и непредсказуемо навернётся.

EP>>А зачем человеку доказывать? Например:
EP>>Результат может содержать ссылку на этот unique, а может не содержать. Человек может например просто знать из документации что в результирующем объекте нет этого unique.
dot>Тут мне кто-то рассказывал, что надо голые указатели использовать при передаче между потоками.

Для не владеющих указателей — да. Здесь речь идёт про владеющий. Да и к чему ты тему переводишь?

EP>>Анализатору же придётся это доказывать проинлайнив весь код.

dot>Да пусть доказывает, он железный, зарплату не просит.

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

EP>>>>Это типичный миф обитающий в среде Java/C# — мол на каждый наш new, будет какой-нибудь *_ptr в C++.

dot>>>... либо битый указатель.
EP>>*_ptr не спасают от битых указателей, их основанная цель это выражение семантики владения в коде, отсюда и имена shared/unique/scoped.
dot>Как более безопасный подход — оно вроде работает. Если ты будешь использовать в коде _ptr а не * и &, то нарваться на битый указатель практически невозможно.

Никто не использует *_ptr везде, даже в самых запущенных случаях.

EP>>Это изменение контракта, которое прекрасно выражается в системе типов — у doSomething поменяется тип параметра и приведённый код не скомпилируется

dot>Поменяется с чего на что? как было (Widget &w) так и останется, если не лепить _ptr на каждый чих.

Теперь ей требуется владение — так как есть передача куда-то что может жить дольше caller'а. Вот тут как раз будет либо *_ptr, либо например rv ref — и то и другое приведёт к ошибке компиляции в старом клиентском коде

EP>>>>Выходим из scope — дальше какие действия? Какое преимущество даст EA в этом случае?

dot>>>Тем что объект пойдёт на стек или в регистры. Какие аллокации?
EP>>Ещё раз. Прочитай свои слова выше (выделено), и ниже:
EP>>

dot>>>Перенос объекта на стек это другая оптимизация. Может делаться только для маленьких оъбектов. Если у тебя выделяется 100мб массив и EA покажет, что ссылка на массив не убегает за пределы, то при выходе из стека объект грохнется. Т.е. по сути тот же unique_ptr.

EP>>Теперь скажи каким образом здесь поможет EA.
dot>Что-то я тут фигню какую-то написал. Ссылка на стеке, конечно, как и unique_ptr, а сам массив в куче, как и unique_ptr, при выходе из стека — пропадёт ссылка.

При выходе из стека корневая ссылка пропала бы и без EA.

dot>При сборке Eden Space оно и грохнется,


Оно бы грохнулось в тот же самый момент и без EA.

dot>не совсем при выходе из стека, но очень близко.


То есть совсем не при выходе из стэка.

dot>А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.


У него тоже ничего не поломается. Даже если бы это был просто vector<T>, без unique_ptr — то тоже ничего бы не поломалось

dot>>>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.

EP>>Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет.
dot>Ты так говоришь, как будто это что-то плохое.

Это очевидный недостаток. Например есть текст, нужно передать куда-то отдельный абзац — на C++ достаточно например либо двух указателей, либо указателя и числа символов, либо просто указателя на начало абзаца. На Java же придётся ещё таскать ссылку на сам текст.

EP>>>>>>Не грохнется — у него нет зависимости O(N) от количества живых объектов.

dot>>>>>new/malloc и delete/free работают не за O(1) внезапно.
EP>>>>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.
dot>>>Так и разные алгоритмы GC есть. И столько всего можно крутить... И я уверен, что вариантов даже больше, ибо ссылка в jvm более абстрактна чем указатели в плюсах, а значит больше простора для оптимизаций.
EP>>Так вот покажи GC не с сублинейной сложностью, желательно ещё чтобы был более-менее популярен.
dot>Если вдруг GC начинает работать в режиме, что его сложность становится O(N) — ты делаешь что-то не то, тебе надо крутить настройки или даже изменять код.

Нет гарантии что она завтра вдруг не выстрелит

dot>>>>>Quick-sort имеет сложность O(N*N), как и пузырьковая... но это ещё ничего не значит.

EP>>>>Конечно значит, именно поэтому в реализациях std::sort используется introsort, которая хоть и основана на quicksort, но выдаёт линеаритмическую сложность
dot>>>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.
EP>>Штуки типа cuckoo hashing не на ровном месте появились.
dot>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).

Меняет — поиск и удаление константы в худшем случае.

EP>>Для hashtable есть альтернативы с гарантированной сублинейной сложностью, и там где гарантия нужна — их и используют. Причём можно комбинировать — снаружи hashtable, а внутри узлов при превышении лимита что-то логарифмическое — тогда будет суб-линейная гарантия.

dot>Так и gc не лыком шиты.

И что? Это меняет их сложность?

dot>>>>>Так храни так же и в Java, т.е. приведённый выше array, не вижу проблему.

EP>>>>Проблема в том для каждого типа элемента нужен будет отдельный Java код.
dot>>>Не смертельно.
EP>>Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код.
dot>Комбинации чего?

Структура данных * контейнер * алгоритм * etc. ЕМНИП даже в C# для разных структур generic даёт разные воплощения.

dot>Сколько их? (только практику плз, а не теоретические рассуждения)


Очень много, это практика, реальный код.
Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.

dot>Если можно было бы — писали бы и на асме, в LL все средства идут в ход.


Вряд ли получится ASM лучше того что даст C++, за какое-нибудь разумное время. Интринсинки — да, полезны, но это не ASM.

dot>>>>>Если ты про ссылочное дерево — то уже всё плохо, ибо оно не будет в памяти последовательно.

EP>>>>Деревья используются на практике. Хранение данных в самом узле позволяет избавится от лишней индерекции.
dot>>>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.
EP>>А например в хэш-таблице?
dot>Если значение большое, то индирекция нужна, иначе сам массив хеш-таблицы будет слишком большим и не помещаться в кеш.

1. Если малое — то уж точно не нужна, тут разногласия нет.
2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме
3. Ключ может хранится отдельно от значения, причём без индерекции.

dot>Если значение маленькое, то это скорее всего будет примитив.


С чего бы это?

EP>>>>>>Так тут есть простой выбор — by-value или by-reference. Это совершенно не тоже самое что и засучив рукава нарезать байт-буфера на структуры

dot>>>>>by-value — и тут ВНЕЗАПНО появляется O(N) от числа живых объектов.
EP>>>>Далеко не всегда. Да и почему внезапно-то?
dot>>>Настолько же ВНЕЗАПНО как и в случае с GC.
EP>>Ок, допустим, в случае чего by-value заменим, не проблема — пара закорючек.
dot>И поимеем битые указатели.

Слушай, я уже не в одном сообщении признавал, что в этом смысле у GC реальный и очевидный плюс. Я же не говорю что битые указатели невозможны, что есть гарантия (хотя при желании и её можно получить).
К чему ты опять повторяешься?

EP>>В случае с GC что будешь делать?

dot>Подстрою GC.

Подстройка называется GC-free/off-heap , да?

dot>>>>>by-reference — и тут начинаются проблемы с временем жизни, засучив рукава начинаешь решать проблемы владения.

EP>>>>В 99.999% случаях ничего "засучивать" не нужно, и никакие *_ptr не нужны.
dot>>>Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).
EP>>Нет же, случаи принципиально разные. Где-то наверху callstack делаем:
EP>>
...
EP>>
ничего не "засучивая".

EP>>Этот массив, по терминам GC, спокойно может попасть под классификацию OG
dot>Сам массив это ровно одна ссылка.

И в элементах тоже ссылки.

dot>Элементы — пусть лежат, если ты не создаёшь|удаляешь их постоянно, а просто меняешь их поля — GC вообще не парится. GC ведёт себя плохо если постоянно меняется граф объектов долго лежащих в памяти.


Если короче, то вот это утверждение неверное:

dot>Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).


dot>Собственно это соответствует сложному жонглированию владением в C++,


Не сложному, и не соответствует. Большинство случаев владения (и "жонглирования" им) C++ это простейший by-value.

dot>где это запросто приведёт к битым указателям, если у вас в команде не Александреску с Страуструпом под руководством Кнута.


"Запросто" не приведёт. А вот valgrind запросто отловит.

dot>>>>>Это мы переходим в другую плоскость — выразительность языка, а не собственно JVM/GC. Для JVM есть и другие языки — Scala, Ceylon, Kotlin и прочее, которые позволяют и многие твои любимые абстракции.

EP>>>>А мы ВНЕЗАПНО не JVM обсуждаем, а вполне конкретную Java. Если брать JVM — то например если в неё скомпилировать C++ — то он там положит всех на лопатки
dot>>>Не положит, к сожалению. Иначе бы уже давно компилировали.
dot>>>Вся эта указательная магия и арифметика, юнионы, и прочий low level не может быть покрыт GC и JVM ссылками, поэтому при компиляции С/C++ память будет внутри byte[].
EP>>Конечно будет, и это одна из причин почему положит на лопатки.
EP>>Именно так и происходит
Автор: Evgeny.Panasyuk
Дата: 06.06.15
в Emscripten, который компилирует C++ в JS.

EP>>И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить.
dot>Ну и кому эти микробенчмарки нужны?

Тем кого интересует скорость

dot>Ты давай пример системы на плюсах, компилированных под jvm.


Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.

dot>Это же полная лажа.


Что конкретно "лажа"?

dot>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.


Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.

dot>Кстати, это, конечно, очень субъективно, но когда я искал работу (London), я всегда писал Java/C++ и выбирал finance. И из ~сотни интерьвю не было ни одного С++. Выводы, конечно, можно сделать разные... но всё же.


Конечно субъективно — мне как раз оттуда приходили варианты C++, правда не finance, и я вообще не искал. И что характерно не было ни одной Java.

EP>>>>Нормальные IDE есть. Да автоматический анализ кода сложнее, но сложнее не из-за выразительности, а из-за внутренних особенностей сложившихся исторически. Языку больше тридцати лет, а если брать с базу C (из которой многие недостатки и произрастают) — то больше сорока.

EP>>>>При этом аналогичную выразительность можно достичь не делая проблемы анализаторам.
dot>>>Может и можно... Я сходу не могу сделать такое заявление.
EP>>>>Те же структуры есть в C#.
dot>>>А толку-то от них...
EP>>Не нужно вручную нарезать массивы на структуры
dot>И что это даёт? Что позволяет добиться?

Добиться меньшего количества низкоуровневого error-prone кода.
Re[89]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 19:38
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. )))

S> Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту
S>Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов.
S>Давай прямо сейчас.
S> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки

S>Что было понятно то основной метод такой обертки для вызова свойства метода реального объекта.


Вот конкретный пример, правда там обвёртка к Python, а не IDispatch, но тем не менее:
struct World
{
    void set(std::string msg) { this->msg = msg; }
    std::string greet() { return msg; }
    std::string msg;
    // ...
}
// указываем те методы которые хотим экспортировать:
BOOST_PYTHON_MODULE(hello)
{
    class_<World>("World")
        .def("greet", &World::greet)
        .def("set", &World::set)
    ;
}
// можно сократить до вот такого варианта:
PYTHON_CLASS_SIMPLIFIED
(
    hello,
    World,
    greet, set
)
Использование:
>>> import hello
>>> planet = hello.World()
>>> planet.set('howdy')
>>> planet.greet()
'howdy'

Помимо этого есть автоматические генераторы клея между языками типа SWIG — там даже ничего перечислять не нужно.
Отредактировано 11.10.2015 19:41 Evgeny.Panasyuk . Предыдущая версия . Еще …
Отредактировано 11.10.2015 19:40 Evgeny.Panasyuk . Предыдущая версия .
Re[90]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 19:48
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


_>>>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. )))

S>> Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту
S>>Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов.
S>>Давай прямо сейчас.
S>> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки

S>>Что было понятно то основной метод такой обертки для вызова свойства метода реального объекта.


EP>Вот конкретный пример, правда там обвёртка к Python, а не IDispatch, но тем не менее:

EP>
EP>// наш класс:
EP>struct World
EP>{
EP>    void set(std::string msg) { this->msg = msg; }
EP>    std::string greet() { return msg; }
EP>    std::string msg;
EP>};
EP>// указываем те методы которых хотим экспортировать:
EP>BOOST_PYTHON_MODULE(hello)
EP>{
EP>    class_<World>("World")
EP>        .def("greet", &World::greet)
EP>        .def("set", &World::set)
EP>    ;
EP>}
EP>// можно сократить до вот такого варианта:
EP>PYTHON_MODULE_SIMPLIFIED
EP>(
EP>    hello,
EP>    World,
EP>    greet, set
EP>)
EP>
Использование:

EP>
>>>> import hello
>>>> planet = hello.World()
>>>> planet.set('howdy')
>>>> planet.greet()
EP>'howdy'
EP>

EP>Помимо этого есть автоматические генераторы клея между языками типа SWIG — там даже методы перечислять не нужно.
Ну вы совсем, что ли не читаете? Автоматически любой тип, объект. Или для всех возможных классов будете клей городить?
И как правило свойства класса это не простые типы, а другие классы. Методы тоже принимают параметры в виде объектов. Вызов статических методов класса итд.
Удосужтесь хоть прочитать код. Там совсем другая песня.

Еще раз любой класс или объект оборачивается вокруг
public class AutoWrap : IReflect
    {
// Два основных поля Объект и его тип
        protected internal object O = null;
        protected internal Type T = null;



Конструкторы
 public AutoWrap(object obj)
        {
            O = obj;
            if (O is Type)
            {
                T = O as Type;
                ЭтоТип = true;
            }
            else
            {
                T = O.GetType();
                ЭтоТип = false;
            }



        }

// Бывает нужно обратиться не к статическим методам, а к методат типа
        public AutoWrap(object obj, Type type)
        {
            O = obj;
            T = type;
            ЭтоТип = false;


        }



 public object ТипКакОбъект(object Тип)
        {
            if (Тип is AutoWrap)
                Тип = ((AutoWrap)Тип).T;
            Type T = ((Type)Тип);

            return new AutoWrap(T, T.GetType());
        }



Все мы имеем доступ к любому объекту ил типу

   public object СоздатьОбъект(object Тип, params object[] argOrig)
        {
            //   MessageBox.Show(Тип.ToString() + " параметров=" + args.Length.ToString());

            var res = ТипДляСоздатьОбъект(Тип);

            object[] args = AutoWrap.ПолучитьМассивРеальныхОбъектов(argOrig);
            return AutoWrap.ОбернутьОбъект(System.Activator.CreateInstance(res, args));

        }
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 19:58 Serginio1 . Предыдущая версия .
Re[91]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 19:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Помимо этого есть автоматические генераторы клея между языками типа SWIG — там даже методы перечислять не нужно.

S> Ну вы совсем, что ли не читаете? Автоматически любой тип, объект. Или для всех возможных классов будете клей городить?

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

S>И как правило свойства класса это не простые типы, а другие классы.


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

S>Методы тоже принимают параметры в виде объектов.


Не проблема, список параметров с их типами автоматически выводится. В примере не указанны параметры у метода set, причём там параметр это std::string.

S>Вызов статических методов класса итд.


Там в одном из примеров показывается даже как внешнюю функцию добавить в класс как метод
Re[92]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 20:02
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Помимо этого есть автоматические генераторы клея между языками типа SWIG — там даже методы перечислять не нужно.

S>> Ну вы совсем, что ли не читаете? Автоматически любой тип, объект. Или для всех возможных классов будете клей городить?

EP>SWIG автоматически делает для любого типа, без ручного перечисления (хотя можно и вручную перечислить — там это опционально).


S>>И как правило свойства класса это не простые типы, а другие классы.


EP>Тоже не проблема — главное указать что для какого класса экспортируется.

Угу так надо все возможные классы указывать.

S>>Методы тоже принимают параметры в виде объектов.


EP>Не проблема, список параметров с их типами автоматически выводится. В примере не указанны параметры у метода set, причём там параметр это std::string.


S>>Вызов статических методов класса итд.


EP>Там в одном из примеров показывается даже как внешнюю функцию добавить в класс как метод

Еще раз. Я не знаю, вообще какие классы буду использовать. Твои обертки статические, а мои во время исполнения. Разница есть?
За подсчетом ссылок кстати следит прокси Net. А как там у вас?
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 20:04 Serginio1 . Предыдущая версия .
Re[93]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 20:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Помимо этого есть автоматические генераторы клея между языками типа SWIG — там даже методы перечислять не нужно.

S>>> Ну вы совсем, что ли не читаете? Автоматически любой тип, объект. Или для всех возможных классов будете клей городить?
EP>>SWIG автоматически делает для любого типа, без ручного перечисления (хотя можно и вручную перечислить — там это опционально).
S>>>И как правило свойства класса это не простые типы, а другие классы.
EP>>Тоже не проблема — главное указать что для какого класса экспортируется.
S> Угу так надо все возможные классы указывать.

Это полуавтоматический вариант. Если нужен автоматический — бери например SWIG

S>>>Вызов статических методов класса итд.

EP>>Там в одном из примеров показывается даже как внешнюю функцию добавить в класс как метод
S> Еще раз. Я не знаю, вообще какие классы буду использовать. Твои обертки статические, а мои во время исполнения. Разница есть?

Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S>За подсчетом ссылок кстати следит прокси Net. А как там у вас?


Wrapper вестимо, а в чём проблема?
Отредактировано 11.10.2015 20:20 Evgeny.Panasyuk . Предыдущая версия .
Re[94]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 20:20
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:



EP>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

Я беру любую нетовскую сборку и использую её. Есть свои сборки. То есть любую без предварительного описания.
Могу сгенерить на лету. Кроме того, сборки имеют свойство меняться.
Нету у вас рефлекшина.


S>>За подсчетом ссылок кстати следит прокси Net. А как там у вас?


EP>Wrapper вестимо, а в чём проблема?

Наверное проблема в зоопарке менеджеров памяти.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 20:29 Serginio1 . Предыдущая версия . Еще …
Отредактировано 11.10.2015 20:24 Serginio1 . Предыдущая версия .
Отредактировано 11.10.2015 20:21 Serginio1 . Предыдущая версия .
Re[94]: Java vs C# vs C++
От: -MyXa- Россия  
Дата: 11.10.15 20:29
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

S>> Еще раз. Я не знаю, вообще какие классы буду использовать. Твои обертки статические, а мои во время исполнения. Разница есть?


EP>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии


Это нельзя, если у тебя не IDispatchEx.

The primary limitation of IDispatch is that it assumes that objects are static. In other words, since objects do not change during run time, type information can fully describe them at compile time.


Так что то, что у него там что-то "в runtime" — это, скорее недостаток, чем достоинство.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[95]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 20:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S> Я беру любую нетовскую сборку и использую её.

От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper?

S>Есть свои сборки. То есть любую без предварительного описания.


Ещё раз, SWIG не требует предварительного описания.

S>Нету у вас рефлекшина.


Нету, это недостаток, сейчас кое-как эмулируется. При этом reflection не обязательно должен быть runtime — он может быть compile-time, и такой скорей всего и введут.

S>>>За подсчетом ссылок кстати следит прокси Net. А как там у вас?

EP>>Wrapper вестимо, а в чём проблема?
S> Особенно на стеке

Ты о чём?

S>В Net value тип боксится


В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного размера
Re[96]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 20:40
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S>> Я беру любую нетовскую сборку и использую её.

EP>От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper?

Мой врапер работает с любой DLL без предварительного описания. В рефлекшине все есть.

S>>Есть свои сборки. То есть любую без предварительного описания.


EP>Ещё раз, SWIG не требует предварительного описания.

А что делает SWIG? Ты должен получить врапер причем статически. Или он компилирует на лету по исходникам?
То есть я могу обратиться к любой C++ DLL и SWIG на лету по информации о типе сгенерирует врапер?
Ну вот, а говорите, что рефлекшина нет.
S>>Нету у вас рефлекшина.

EP>Нету, это недостаток, сейчас кое-как эмулируется. При этом reflection не обязательно должен быть runtime — он может быть compile-time, и такой скорей всего и введут.

А зачем рефлекшн в compile-time? Он нужен как раз в runtime.

S>>>>За подсчетом ссылок кстати следит прокси Net. А как там у вас?

EP>>>Wrapper вестимо, а в чём проблема?
S>> Особенно на стеке

EP>Ты о чём?


S>>В Net value тип боксится


EP>В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного

размера
Кстати в примерах только value типы. Нет там примеров с объектами, типами итд.
Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 20:59 Serginio1 . Предыдущая версия . Еще …
Отредактировано 11.10.2015 20:51 Serginio1 . Предыдущая версия .
Отредактировано 11.10.2015 20:47 Serginio1 . Предыдущая версия .
Отредактировано 11.10.2015 20:44 Serginio1 . Предыдущая версия .
Re[89]: Java vs C# vs C++
От: -MyXa- Россия  
Дата: 11.10.15 20:52
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>
S> public object InvokeMember(string name, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, object target, object[] argsOrig, System.Reflection.ParameterModifier[] modifiers, System.Globalization.CultureInfo culture, string[] namedParameters)
S>        {        // Unwrap any AutoWrap'd objects (they need to be raw if a paramater)

S>            if (name == "[DISPID=-4]")
S>            {
S>                return new EnumVariantImpl(((IEnumerable)O).GetEnumerator());
S>            }
        [поскипана куча]
S>


Дай угадаю, "[DISPID=-4]" — это С-шный
#define    DISPID_NEWENUM    ( -4 )

Это ты придумал со строкой сравнивать, или это работа мастера?

Но, вообще, это не код, это... короче, C# — ассемблер современности.

Ты уверен, что как ты написал — так это и должно делаться?

На Visual C++ ты напишешь типа того:

[
    object,
    dual // Это разрешает поддержку IDispatch
]
interface MyInterface
{
    // твои методы
};

[
    coclass,
    default(MyInterface)
]
class MyClass
{
    // реализации методов
};

А при твоём подходе события поддерживаются? События — такая же стандартная фича, как и IDispatch (см. IConnectionPoint и атрибут event_source).

И если ты всё руками делаешь — tlb откуда возьмётся?
Если не поможет, будем действовать током... 600 Вольт (C)
Re[97]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 20:55
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S>>> Я беру любую нетовскую сборку и использую её.
EP>>От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper?
S> Мой врапер работает с любой DLL без предварительного описания. В рефлекшине все есть.

Нет, не с любой

S>>>Есть свои сборки. То есть любую без предварительного описания.

EP>>Ещё раз, SWIG не требует предварительного описания.
S> А что делает SWIG? Ты должен получить врапер причем статически. Или он компилирует на лету по исходникам?

Он делает весь glue code по исходникам.

S>>>Нету у вас рефлекшина.

EP>>Нету, это недостаток, сейчас кое-как эмулируется. При этом reflection не обязательно должен быть runtime — он может быть compile-time, и такой скорей всего и введут.
S> А зачем рефлекшн в compile-time? Он нужен как раз в runtime.

Нет, нам-то как раз нужен в compile-time. Из compile-time reflection нетрудно перейти в runtime, а вот обратно уже нет.
По факту же большинство случаев использования refleciton прекрасно укладываются в compile-time.

S>>>В Net value тип боксится

EP>>В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного размера
S>Кстати в примерах только value типы. Нет там примеров с объектами, типами итд.
S>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?

Каким зоопарком? Ты о чём?
Re[90]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 21:08
Оценка:
Здравствуйте, -MyXa-, Вы писали:

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


S>>
S>> public object InvokeMember(string name, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, object target, object[] argsOrig, System.Reflection.ParameterModifier[] modifiers, System.Globalization.CultureInfo culture, string[] namedParameters)
S>>        {        // Unwrap any AutoWrap'd objects (they need to be raw if a paramater)

S>>            if (name == "[DISPID=-4]")
S>>            {
S>>                return new EnumVariantImpl(((IEnumerable)O).GetEnumerator());
S>>            }
MX>        [поскипана куча]
S>>


MX>Дай угадаю, "[DISPID=-4]" — это С-шный

MX>
MX>#define    DISPID_NEWENUM    ( -4 )
MX>

Это запрос комовского Энумератора.
MX>Это ты придумал со строкой сравнивать, или это работа мастера?
Это нетовская работа с диспинтерфейсами. Обычно Кроме инвоке идут GetIDsOfNames

MX>Но, вообще, это не код, это... короче, C# — ассемблер современности.


MX>Ты уверен, что как ты написал — так это и должно делаться?

Это используется уже кучу лет.

MX>На Visual C++ ты напишешь типа того:


MX>
MX>[
MX>    object,
MX>    dual // Это разрешает поддержку IDispatch
MX>]
MX>interface MyInterface
MX>{
MX>    // твои методы
MX>};

MX>[
MX>    coclass,
MX>    default(MyInterface)
MX>]
MX>class MyClass
MX>{
MX>    // реализации методов
MX>};
MX>

MX>А при твоём подходе события поддерживаются? События — такая же стандартная фича, как и IDispatch (см. IConnectionPoint и атрибут event_source).

MX>И если ты всё руками делаешь — tlb откуда возьмётся?

А зачем tlb? Есть ITypeInfo котрый и реализуется во врапере методы IReflect. Да и Idispatch и он не нужен. 1С прекрасно без него обходится

Со свойствами проблема, но их можно динамически обернуть. То есть сделать обертку над классом для описания свойв.
Для простых случаев можно так.
 [ComVisible(true)]
    [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
  //  [Guid("33B45C9D-1AED-41F9-8880-36AB6AE84749")]
    public interface IEventFor1C
    {
        [DispId(0x60020000)]
        void Событие();

        [DispId(0x60020001)]
        void СобытиеСПараметром(object value);
    }

   

    [ComVisible(true)]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    [Guid("62F8156C-13B9-4484-B152-82023243E1D3")]
    [ComSourceInterfaces(typeof(IEventFor1C))]
    public class ClassForEvent1C
    {
        [ComVisible(false)]
        public delegate void Событие_Delgate();
        public delegate void СобытиеСПараметром_Delgate(object value);
        public object Объект;
        private SynchronizationContext Sc;

        public ClassForEvent1C(object Объект,String СобытиеОбъекта,bool ЕстьПараметр=false)
        {
            this.Объект = Объект;
            BindingFlags bf = BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance;
            EventInfo ei = Объект.GetType().GetEvent(СобытиеОбъекта, bf);
              if (!ЕстьПараметр)
            ei.AddEventHandler(Объект, new System.Action(ВнешнееСобытие));
             else
            ei.AddEventHandler(Объект, new System.Action<object>(ВнешнееСобытиеСПараметром));

            SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());
            Sc = SynchronizationContext.Current;

        }
        public event Событие_Delgate Событие;
        public event СобытиеСПараметром_Delgate СобытиеСПараметром;
       
        private void ВнешнееСобытие()
        {
          if (this.Событие != null) //Событие();
              Sc.Send(d => Событие(), null);

        
        }

        
        private void ВнешнееСобытиеСПараметром(object value)
        {
            if (this.СобытиеСПараметром != null) //Событие();
                Sc.Send(d => СобытиеСПараметром(AutoWrap.ОбернутьОбъект(value)), null);


        }

    }



Либо пишу ручками используя анонимные типы. И подписка
 void OnGetMessageImage(object value);




 wa.OnGetMessageImage += (mediaNode, from, id, fileName, fileSize, url, preview) =>
            {
                ОтослатьСобытиеСПараметром(OnGetMessageImage, new { mediaNode = mediaNode, from = from, id = id, fileName = fileName, fileSize = fileSize, url = url, preview = preview }, "OnGetMessageImage");
            };


Да и приходится для Событий работать с реальным объектом


whatsappFor1C=Сборка.GetType("whatsappFor1C.whatsappFor1C");
    ВАОбертка=врап.СоздатьОбъект(whatsappFor1C,врап,Телефон,Пароль,Ник);
    СтатусСоединения=Врап.ПолучитьТип("WhatsAppApi.ApiBase+CONNECTION_STATUS");

    wa=ВАОбертка.wa;
    ВА=Врап.ПолучитьРеальныйОбъект(ВАОбертка);
    
    ДобавитьОбработчик Ва.OnConnectFailed, ПриОшибкеСоединения;
    ДобавитьОбработчик Ва.OnConnectSuccess, ПриУспешномСоединении;
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 21:33 Serginio1 . Предыдущая версия . Еще …
Отредактировано 11.10.2015 21:21 Serginio1 . Предыдущая версия .
Отредактировано 11.10.2015 21:19 Serginio1 . Предыдущая версия .
Отредактировано 11.10.2015 21:12 Serginio1 . Предыдущая версия .
Re[98]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 21:11
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S>>>> Я беру любую нетовскую сборку и использую её.
EP>>>От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper?
S>> Мой врапер работает с любой DLL без предварительного описания. В рефлекшине все есть.

EP>Нет, не с любой

Докажи.
S>>>>Есть свои сборки. То есть любую без предварительного описания.
EP>>>Ещё раз, SWIG не требует предварительного описания.
S>> А что делает SWIG? Ты должен получить врапер причем статически. Или он компилирует на лету по исходникам?

EP>Он делает весь glue code по исходникам.

Ну вот, а говоришь, что не требует предварительного описания.
S>>>>Нету у вас рефлекшина.
EP>>>Нету, это недостаток, сейчас кое-как эмулируется. При этом reflection не обязательно должен быть runtime — он может быть compile-time, и такой скорей всего и введут.
S>> А зачем рефлекшн в compile-time? Он нужен как раз в runtime.

EP>Нет, нам-то как раз нужен в compile-time. Из compile-time reflection нетрудно перейти в runtime, а вот обратно уже нет.

EP>По факту же большинство случаев использования refleciton прекрасно укладываются в compile-time.
У нас все в реал тайме. Можно подкинуть любую сборку и работать либо по утинной типизации, либо по информации о типе

S>>>>В Net value тип боксится

EP>>>В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного размера
S>>Кстати в примерах только value типы. Нет там примеров с объектами, типами итд.
S>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?

EP>Каким зоопарком? Ты о чём?

То есть у вас как в Delphi один менеждер памяти? Все классы поддерживают подсчет ссылок?
и солнце б утром не вставало, когда бы не было меня
Re[99]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 21:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S>>>>> Я беру любую нетовскую сборку и использую её.
EP>>>>От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper?
S>>> Мой врапер работает с любой DLL без предварительного описания. В рефлекшине все есть.
EP>>Нет, не с любой
S>Докажи.

Возьми любую native dll

S>>>>>Есть свои сборки. То есть любую без предварительного описания.

EP>>>>Ещё раз, SWIG не требует предварительного описания.
S>>> А что делает SWIG? Ты должен получить врапер причем статически. Или он компилирует на лету по исходникам?
EP>>Он делает весь glue code по исходникам.
S> Ну вот, а говоришь, что не требует предварительного описания.

Это исходный класс что-ли предварительное описание?

S>>>>>В Net value тип боксится

EP>>>>В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного размера
S>>>Кстати в примерах только value типы. Нет там примеров с объектами, типами итд.
S>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>Каким зоопарком? Ты о чём?
S> То есть у вас как в Delphi один менеждер памяти?

Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.

S>Все классы поддерживают подсчет ссылок?


Это всё прекрасно реализуется неинтрузивно.
Нет подсчёта ссылок:
struct Widget
{
    Data x;
};
Легким движением руки подсчёт ссылок появляется:
shared_ptr<Widget> ref_counted_widget;
Re[100]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 22:01
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>>>Причём тут "во время исполнения"? Ты свой класс, для которого нужен IDispatch, меняешь в runtime? Ты этого не говорил в условии

S>>>>>> Я беру любую нетовскую сборку и использую её.
EP>>>>>От native варианта ты что хочешь? Взять любую DLL и сделать к ней wrapper?
S>>>> Мой врапер работает с любой DLL без предварительного описания. В рефлекшине все есть.
EP>>>Нет, не с любой
S>>Докажи.

EP>Возьми любую native dll

Я говорил про любую нетовскую. Кстати может и не все нетовские если он обфусцирован. Правда ни разу с ними не работал
S>>>>>>Есть свои сборки. То есть любую без предварительного описания.
EP>>>>>Ещё раз, SWIG не требует предварительного описания.
S>>>> А что делает SWIG? Ты должен получить врапер причем статически. Или он компилирует на лету по исходникам?
EP>>>Он делает весь glue code по исходникам.
S>> Ну вот, а говоришь, что не требует предварительного описания.

EP>Это исходный класс что-ли предварительное описание?

Ну вообще то да. Или у вас все с открытыми кодами? Swig делает в итоге делает предварительное описание.

S>>>>>>В Net value тип боксится

EP>>>>>В C++ объект любого типа можно создать где угодно (не считая несколько экстремальных случаев к теме не относящихся) — в любой кучке байт достаточного размера
S>>>>Кстати в примерах только value типы. Нет там примеров с объектами, типами итд.
S>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?
EP>>>Каким зоопарком? Ты о чём?
S>> То есть у вас как в Delphi один менеждер памяти?

EP>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.

Это когда это такое было? Вся прелесть COM в том, что используется единый менеджер памяти.
Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
Еще раз все объекты должны поддерживать подсчет ссылок.

S>>Все классы поддерживают подсчет ссылок?


EP>Это всё прекрасно реализуется неинтрузивно.

EP>Нет подсчёта ссылок:
EP>
EP>struct Widget
EP>{
EP>    Data x;
EP>};
EP>
Легким движением руки подсчёт ссылок появляется:

EP>
EP>shared_ptr<Widget> ref_counted_widget;
EP>


Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
По сути тебе нужно, что бы все классы поддерживали подсче ссылок.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 22:20 Serginio1 . Предыдущая версия .
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 11.10.15 22:33
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.

dot>>На плюсах были бы те же извращения.
EP>Это демагогия чистой воды, непонятно на кого рассчитанная
EP>В ролике действительно есть описание тех аспектов которые были бы на C++, их даже извращением трудно назвать — банальное affinity.
EP>Помимо этого есть извращения с GC-free, off-heap — их выступающий упомянул только вскользь, мол да — надо как-то решать. Вот этих извращений на C++ бы не было
Решается, конечно. Но каких либо особенных сложностей нет. Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы. Там где offheap или нарезание на массивы — будут structure-of-arrays.

dot>>>>А в плюсах выбора нет.

EP>>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>>>Причём реализации возможны как библиотечные, так и runtime.
dot>>Ой, да не прикалывайся.
EP>Не прикалываюсь
И как оказалось по факту есть только boehm

EP>Например Boehm GC есть очень давно, и используется в реальных проектах

Он используется в особенного типа проектов — gcj, mono, lisp и т.п. Прикладной код, а уж тем более LL — что-то очень сомневаюсь.

dot>>>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,

EP>>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".
dot>>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".
EP>От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул.
Да сколько раз повторять. Нет проблем никаких.

dot>>>>может быть синтаксис не очень, и код непривычен, но помехой не является.

EP>>>И уровень кода ниже чем C, и больше его во много раз.
dot>>Не знаю что тут значит "уровень кода", но это не важно.
EP>На C есть структуры — это выше уровнем чем ручное нарезание буферов.
И что они дают? Без них всё работает замечательно, зачем лишняя сущность?

dot>>Все преимущества java никуда не деваются.

EP>Конечно теряются — например появляются те самые расстрелы памяти
Во-первых, такие извращения делаются только в очень небольшом участке кода, дай боже 1% от всей системы, во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода. В-третьих, этот кусок кода довольно примитивный, при желании можно даже формально доказать отсутствие расстрелов. В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами. В-пятых, обычно это красиво оборачивается, например, в Disruptor, за много лет отлаженная библиотека.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[101]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 22:55
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Это исходный класс что-ли предварительное описание?

S>Ну вообще то да. Или у вас все с открытыми кодами?

Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?

S>Swig делает в итоге делает предварительное описание.


Он генерирует необходимый клей.

S>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?

EP>>>>Каким зоопарком? Ты о чём?
S>>> То есть у вас как в Delphi один менеждер памяти?
EP>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S> Это когда это такое было?

Всегда.

S>Вся прелесть COM в том, что используется единый менеджер памяти.

S>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>Еще раз все объекты должны поддерживать подсчет ссылок.

Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.

S>>>Все классы поддерживают подсчет ссылок?

EP>>Это всё прекрасно реализуется неинтрузивно.
EP>>Нет подсчёта ссылок:
EP>>
EP>>struct Widget
EP>>{
EP>>    Data x;
EP>>};
EP>>
Легким движением руки подсчёт ссылок появляется:

EP>>
EP>>shared_ptr<Widget> ref_counted_widget;
EP>>

S>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.

Они удалятся автоматически вместе с аггрегирующей их структурой.

S>По сути тебе нужно, что бы все классы поддерживали подсче ссылок.


Зачем все?
Отредактировано 11.10.2015 22:58 Evgeny.Panasyuk . Предыдущая версия .
Re[102]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.10.15 23:32
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Это исходный класс что-ли предварительное описание?

S>>Ну вообще то да. Или у вас все с открытыми кодами?

EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?

Я не предлагаю. Я это делаю для нетовских DLL
S>>Swig делает в итоге делает предварительное описание.

EP>Он генерирует необходимый клей.

Не клей, а прокси класс.

S>>>>>>Как ваш описатель врапера разберется с зоопарком менеджеров памяти?

EP>>>>>Каким зоопарком? Ты о чём?
S>>>> То есть у вас как в Delphi один менеждер памяти?
EP>>>Не один, и здесь в этом нет проблемы. COM объекты создаются и удаляются на одной стороне.
S>> Это когда это такое было?

EP>Всегда.


S>>Вся прелесть COM в том, что используется единый менеджер памяти.

S>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>Еще раз все объекты должны поддерживать подсчет ссылок.

EP>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).

Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него. Это же по сути виртуальный деструктор



EP>На стороне клиента объект нигде в явном виде не создаётся и не удаляется, грубо говоря нет никаких new и delete.

На стороне клиента есть строки ,SafeArray. Кроме того в Net есть GAC где при создании объекта будет использоваться одна DLL. Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
И при передаче данных из разных DLL это еще и разные враперы.

S>>>>Все классы поддерживают подсчет ссылок?

EP>>>Это всё прекрасно реализуется неинтрузивно.
EP>>>Нет подсчёта ссылок:
EP>>>
EP>>>struct Widget
EP>>>{
EP>>>    Data x;
EP>>>};
EP>>>
Легким движением руки подсчёт ссылок появляется:

EP>>>
EP>>>shared_ptr<Widget> ref_counted_widget;
EP>>>

S>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.

EP>Они удалятся автоматически вместе с аггрегирующей их структурой.

Автоматически когда? И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)? Все объекты должны поддерживать подсчет ссылок

S>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.


EP>Зачем все?


Плохо читаешь.
Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки. Создался врапер.
Теперь все объекты полей кроме того на который есть ссылка клиента могут удалиться.
Получается, что все должны поддерживать счетчик, такие ссылки хранить отдельно например в Хэш таблице и перед удалением смотреть если они во враперах.
Но ведь это не так. Не все классы поддерживают подсчет ссылок.

Просто вся прелесть Net в том, что все выполняется в единой среде c информацией о типе и контроле типа, которая разруливает кучу взаимосвязей.
Ну и конечно твой нелюбимый GC
и солнце б утром не вставало, когда бы не было меня
Отредактировано 11.10.2015 23:44 Serginio1 . Предыдущая версия . Еще …
Отредактировано 11.10.2015 23:42 Serginio1 . Предыдущая версия .
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 11.10.15 23:41
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>И то что "извращения java" никуда не делись. Он всего лишь рассказал про один аспект задачи, который никак не отменяет другие.

dot>>>На плюсах были бы те же извращения.
EP>>Это демагогия чистой воды, непонятно на кого рассчитанная
EP>>В ролике действительно есть описание тех аспектов которые были бы на C++, их даже извращением трудно назвать — банальное affinity.
EP>>Помимо этого есть извращения с GC-free, off-heap — их выступающий упомянул только вскользь, мол да — надо как-то решать. Вот этих извращений на C++ бы не было
dot>Решается, конечно.

Да, всё решаемо.

dot>Но каких либо особенных сложностей нет.


Привыкли есть кактус

dot>Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы.


Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.
vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.

Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.

dot>Там где offheap или нарезание на массивы — будут structure-of-arrays.


Сам же понимаешь что это передёргивание.
Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры.
Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде.
Причём SoA требуются на порядки реже чем обычные структуры.

dot>>>>>А в плюсах выбора нет.

EP>>>>GC для C++ существуют (и их применяют) как минимум с начала девяностых годов / конца восьмидесятых. В стандарте C++11 появилось специальное API для GC.
EP>>>>Причём реализации возможны как библиотечные, так и runtime.
dot>>>Ой, да не прикалывайся.
EP>>Не прикалываюсь
dot>И как оказалось по факту есть только boehm

Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет

EP>>Например Boehm GC есть очень давно, и используется в реальных проектах

dot>Он используется в особенного типа проектов — gcj, mono, lisp и т.п. Прикладной код, а уж тем более LL — что-то очень сомневаюсь.

Например Inkscape — вполне прикладной код
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Boehm-GC

dot>>>>>К тому, что java уже давно побороли... Большинство выкрутасов это не "извращения java", а именно LL,

EP>>>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".
dot>>>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".
EP>>От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул.
dot>Да сколько раз повторять. Нет проблем никаких.

То есть ты извращения с off-heap за проблемы не считаешь? Ну ок

dot>>>>>может быть синтаксис не очень, и код непривычен, но помехой не является.

EP>>>>И уровень кода ниже чем C, и больше его во много раз.
dot>>>Не знаю что тут значит "уровень кода", но это не важно.
EP>>На C есть структуры — это выше уровнем чем ручное нарезание буферов.
dot>И что они дают?

Например абстракцию над пачкой байт лежащих в массиве.

dot>Без них всё работает замечательно, зачем лишняя сущность?


Несерьёзно, это уже blub-аргументация.

dot>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода.


Действительно, подумаешь код не работает.
Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?

dot>В-третьих, этот кусок кода довольно примитивный, при желании можно даже формально доказать отсутствие расстрелов.


Да не то что доказать, тут подобный кусок без ошибки написать не смогли
Автор: Evgeny.Panasyuk
Дата: 08.10.15
.

dot>В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами.


Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.

dot>В-пятых, обычно это красиво оборачивается, например, в Disruptor, за много лет отлаженная библиотека.


Со своими структурами что делать?
Re[103]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 00:09
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Это исходный класс что-ли предварительное описание?

S>>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>Я не предлагаю. Я это делаю для нетовских DLL
S>>>Swig делает в итоге делает предварительное описание.
EP>>Он генерирует необходимый клей.
S> Не клей, а прокси класс.

Клей.

http://www.swig.org/
SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.


S>>>Вся прелесть COM в том, что используется единый менеджер памяти.

S>>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
S> Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него.

Она есть. В простейшем виде такая ссылка зашита в самом коде методов CreateInstance и Release.
А нужные методы вызываются правильным выбором vtable ptr, который находится по указателю с которым работает пользователь.

S>Это же по сути виртуальный деструктор


В обязанности деструктора не входит очистка памяти. Его например можно вызывать без очистки памяти.
Release грубо говоря это виртуальный метод который внутри делает что-то типа if(--counter == 0) delete this;, а уже delete вызывает деструктор (который даже может быть не виртуальным) и очищает память.

S>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.


Какого параметра?

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


Из-за чего?
Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом

S> И при передаче данных из разных DLL это еще и разные враперы.


И что?

S>>>>>Все классы поддерживают подсчет ссылок?

EP>>>>Это всё прекрасно реализуется неинтрузивно.
EP>>>>Нет подсчёта ссылок:
EP>>>>
EP>>>>struct Widget
EP>>>>{
EP>>>>    Data x;
EP>>>>};
EP>>>>
Легким движением руки подсчёт ссылок появляется:

EP>>>>
EP>>>>shared_ptr<Widget> ref_counted_widget;
EP>>>>

S>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>>Они удалятся автоматически вместе с аггрегирующей их структурой.
S> Автоматически когда?

После того как отработает тело деструктора аггрегирующей их структуры.

S>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?


А как он к ним получил доступ?

S>Все объекты должны поддерживать подсчет ссылок


Нет, не все.

S>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.

EP>>Зачем все?
S> Плохо читаешь.

Что конкретно я плохо читаю? То что ты там задним числом наредактировал?

S>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.


Каким образом?

S>Создался врапер.


Когда? Где? Кем? И каким образом?

S>Ну и конечно твой нелюбимый GC


Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
Да и причём тут GC?
Отредактировано 12.10.2015 0:11 Evgeny.Panasyuk . Предыдущая версия . Еще …
Отредактировано 12.10.2015 0:10 Evgeny.Panasyuk . Предыдущая версия .
Re[104]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 00:31
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


.
S>>>>Вся прелесть COM в том, что используется единый менеджер памяти.
S>>>>Строки, массивы могут создаваться на стороне клиента и передаваться в объект. Да и объекты могут создаваться в разных DLL.
S>>>>Еще раз все объекты должны поддерживать подсчет ссылок.
EP>>>Создание и удаление объекта происходит на одной стороне. Создание в CreateInstance, удаление грубо говоря в Release. Оба метода предоставляются одним и тем же лицом, и работают с одним и тем же менеджером памяти — с тем который определит автор этих методов (например автор соответствующей DLL).
S>> Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него.

EP>Она есть. В простейшем виде такая ссылка зашита в самом коде методов CreateInstance и Release.

EP>А нужные методы вызываются правильным выбором vtable ptr, который находится по указателю с которым работает пользователь.

S>>Это же по сути виртуальный деструктор


EP>В обязанности деструктора не входит очистка памяти. Его например можно вызывать без очистки памяти.

EP>Release грубо говоря это виртуальный метод который внутри делает что-то типа if(--counter == 0) delete this;, а уже delete вызывает деструктор (который даже может быть не виртуальным) и очищает память.

Тогда C++ это тормоза. А ты говоришь о скорости.
S>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.

EP>Какого параметра?


У класса есть методы, у метода есть параметры, в том числе и out
S>>Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.

EP>Из-за чего?

EP>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом

А обращаться к несуществующим полям, или массивам меньшей длины?
S>> И при передаче данных из разных DLL это еще и разные враперы.

EP>И что?


А то, что разные версии Swig и соответственно разные поля
S>>>>>>Все классы поддерживают подсчет ссылок?
S>>>>Ну вот у тебя есть две структуры. Кто и когда будет удалять объекты находящихся в полях структуры.
EP>>>Они удалятся автоматически вместе с аггрегирующей их структурой.
S>> Автоматически когда?

EP>После того как отработает тело деструктора аггрегирующей их структуры.


S>>И почему они должны удаляться если на них есть ссылка на клиенте (во врапере)?


EP>А как он к ним получил доступ?

А как ты получаешь доступ к полям, свойствам объекта.

S>>Все объекты должны поддерживать подсчет ссылок


EP>Нет, не все.


S>>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.

EP>>>Зачем все?
S>> Плохо читаешь.

EP>Что конкретно я плохо читаю? То что ты там задним числом наредактировал?

Я тебе уже кучу времени долблю про деревья, и то что у клиента должен быть доступ к любому публичному (в Net можно к любому) полю, свойству

S>>Есть объект у которого куча полей с объектами. На стороне клиента получили поле через 2 точки.


EP>Каким образом?

А как ты достаешь Объект.Поле1.Тратаьа
S>>Создался врапер.

EP>Когда? Где? Кем? И каким образом?


Не знаю, что там твой SWIG нагородил
S>>Ну и конечно твой нелюбимый GC

EP>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.

EP>Да и причём тут GC?
А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
и солнце б утром не вставало, когда бы не было меня
Re[102]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 00:32
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Это исходный класс что-ли предварительное описание?

S>>Ну вообще то да. Или у вас все с открытыми кодами?

EP>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?


Кстати Сборка Net это не только DLL. Это том числе и Exe.
и солнце б утром не вставало, когда бы не было меня
Re[104]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 00:41
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>Это исходный класс что-ли предварительное описание?

S>>>>Ну вообще то да. Или у вас все с открытыми кодами?
EP>>>Для этого достаточно заголовков (.h/.hpp). Или ты опять предлагаешь враппить произвольные бинарники?
S>>Я не предлагаю. Я это делаю для нетовских DLL
S>>>>Swig делает в итоге делает предварительное описание.
EP>>>Он генерирует необходимый клей.
S>> Не клей, а прокси класс.

EP>Клей.

EP>

EP>http://www.swig.org/
EP>SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.


А ты вообще представляешь какой результирующий врапер должен получиться если делать ко всем DLL.
При этом реально то нужно совсем немного. Но это заранее неизвестно. А теперь сравни размер моей функции и предполагаемый врапер по всем возможным DLL.
А ведь для Net с точки зрения классов нет большой разницы между DLL и EXE.

Кстати а чем С++ хуже питона, раз питон используется с С++?
C# точно ничем не хуже.
и солнце б утром не вставало, когда бы не было меня
Re[105]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 01:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>>>Он генерирует необходимый клей.

S>>> Не клей, а прокси класс.
EP>>Клей.
EP>>

EP>>http://www.swig.org/
EP>>SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.

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

Зачем ко всем? К каким всем?

S>При этом реально то нужно совсем немного. Но это заранее неизвестно. А теперь сравни размер моей функции и предполагаемый врапер по всем возможным DLL.


По каким всем возможным? Речь изначально шла про какой-то один тип.
Если же тебе нужно что-то типа REPL (для чего?), то тогда уже надо смотреть в сторону интерпретатора C++ — Cling.

S>А ведь для Net с точки зрения классов нет большой разницы между DLL и EXE.


К чему это вообще?

S> Кстати а чем С++ хуже питона, раз питон используется с С++?


Ты о чём вообще?

S> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>C# точно ничем не хуже.

^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит.
Re[105]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 02:24
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Тогда в объекте должна быть ссылка на свой менеджер памяти и удаление через него.

EP>>Она есть. В простейшем виде такая ссылка зашита в самом коде методов CreateInstance и Release.
EP>>А нужные методы вызываются правильным выбором vtable ptr, который находится по указателю с которым работает пользователь.
S>>>Это же по сути виртуальный деструктор
EP>>В обязанности деструктора не входит очистка памяти. Его например можно вызывать без очистки памяти.
EP>>Release грубо говоря это виртуальный метод который внутри делает что-то типа if(--counter == 0) delete this;, а уже delete вызывает деструктор (который даже может быть не виртуальным) и очищает память.

S> Тогда C++ это тормоза. А ты говоришь о скорости.


Как ты пришёл к такому выводу?

S>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.

EP>>Какого параметра?
S> У класса есть методы, у метода есть параметры, в том числе и out

Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.

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

EP>>Из-за чего?
EP>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
S> А обращаться к несуществующим полям, или массивам меньшей длины?

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

S>>>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.

EP>>>>Зачем все?
S>>> Плохо читаешь.
EP>>Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
S> Я тебе уже кучу времени долблю про деревья, и то что у клиента должен быть доступ к любому публичному (в Net можно к любому) полю, свойству

Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения

S> Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
S> Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
S>И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?

Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.
Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.

S>>>Ну и конечно твой нелюбимый GC

EP>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>Да и причём тут GC?
S> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.

Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
Отредактировано 12.10.2015 2:31 Evgeny.Panasyuk . Предыдущая версия .
Re[106]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 06:36
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>>>Он генерирует необходимый клей.

S>>>> Не клей, а прокси класс.
EP>>>Клей.
EP>>>

EP>>>http://www.swig.org/
EP>>>SWIG is typically used to parse C/C++ interfaces and generate the 'glue code' required for the above target languages to call into the C/C++ code.

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

EP>Зачем ко всем? К каким всем?

Ко всем возможным. Я заранее не знаю какие сборки буду использовать. Этим будет заниматься программист 1С.
S>>При этом реально то нужно совсем немного. Но это заранее неизвестно. А теперь сравни размер моей функции и предполагаемый врапер по всем возможным DLL.

EP>По каким всем возможным? Речь изначально шла про какой-то один тип.

EP>Если же тебе нужно что-то типа REPL (для чего?), то тогда уже надо смотреть в сторону интерпретатора C++ — Cling.
Это ты о чем то думал. Я говорил о любом классе.

S>>А ведь для Net с точки зрения классов нет большой разницы между DLL и EXE.


EP>К чему это вообще?

К тому, что как ты будешь создавать классы из бинарника EXE где нет импорта функций, заголовков
S>> Кстати а чем С++ хуже питона, раз питон используется с С++?

EP>Ты о чём вообще?


S>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>C# точно ничем не хуже.

EP>^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит.

Вы используете питон для написания приложений. В этой ветке не раз подымался. Кроме того ты пример врапера именно для питона.
и солнце б утром не вставало, когда бы не было меня
Re[106]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 06:49
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:



S>>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.

EP>>>Какого параметра?
S>> У класса есть методы, у метода есть параметры, в том числе и out

EP>Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.

Воо теперь нужно сравнивать не только тип, но и его эквивалентность
S>>>>Кроме того в двух DLL могут быть разные версии класса, что приводит к повреждению памяти.
EP>>>Из-за чего?
EP>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
S>> А обращаться к несуществующим полям, или массивам меньшей длины?

EP>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет.

У тебя расположение полей может быть другое.
EP>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.
А как ты понимаешь обращение к полям, вызов метода. Смещение полей, методов может меняться. Даже VMT и та может поменяться.
Да и методы могут в реалии иметь другую сигнатуру.

S>>>>>>По сути тебе нужно, что бы все классы поддерживали подсчет ссылок.

EP>>>>>Зачем все?
S>>>> Плохо читаешь.
EP>>>Что конкретно я плохо читаю? То что ты там задним числом наредактировал?
S>> Я тебе уже кучу времени долблю про деревья, и то что у клиента должен быть доступ к любому публичному (в Net можно к любому) полю, свойству

EP>Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения


Про валуе типы я подправил. А вот то, что полями могут быть экземпляры классов, как раз и говорит о деревьях.
Так как полей объектов тоже могут быть поля объекты.
EP>

S>> Кстати единственный вариант , это когда есть подсчет ссылок. Я так понимаю, что у вас там куча вариантов даже по этой теме
S>> Возьмем пример. Например у тебя есть структура с кучей полей объектов этакое дерево с циклическими ссылками
S>>И тебе эту структуру нужно передать на сторону клиента. Врапер структуру обернул. Но у структуры то нет подсчета ссылок?

EP>Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.
EP>Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.

Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах

S>>>>Ну и конечно твой нелюбимый GC

EP>>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>>Да и причём тут GC?
S>> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.

EP>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release


То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
Такого даже в Delphi нет.
и солнце б утром не вставало, когда бы не было меня
Re[89]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 07:10
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. )))

S> Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту
S>Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов.
S>Давай прямо сейчас.

Ну вообще то создание COM объектов в виде обёртки над существующими классами — это не самый лучший путь. По нормальному реализацию COM вставляют прямо в эти классы (мы же обычно заранее знаем, хотим ли мы поддерживать вызов нас через COM или нет). Соответственно реализация делается тривиально: http://doc.qt.io/qt-5/activeqt-activeqt-simple-example.html или например вот http://doc.qt.io/qt-5/activeqt-activeqt-comapp-example.html для полноценного приложения (exe) с документами и т.п., управляемого через COM.

Но если всё же есть большое желание создание COM обёртку над уже реализованными классами, то это естественно тоже не проблема: http://doc.qt.io/qt-5/activeqt-activeqt-wrapper-example.html.

S> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки


Эээ что? )
Re[106]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 07:10
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.
EP>>>Какого параметра?
S>> У класса есть методы, у метода есть параметры, в том числе и out

EP>Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.


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

EP>>>Из-за чего?
EP>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
S>> А обращаться к несуществующим полям, или массивам меньшей длины?

EP>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет.

EP>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.
Если если. А на самом деле могут меняться как поля, так и сигнатуры методов и VMT.
Кстати в Net поместил в GAC и все будут использовать одну версию. Либо могу передать объект врапера, где будут через рефлексию вызываться его методы и свойства.

Например

public whatsappFor1C(dynamic Врапер, string Отправитель, string Пароль, String NickName)
        {
            this.Врапер = Врапер;



А внутри при возвращении объектов

Sc.Send(d => Событие(Врапер.ОбернутьОбъект(value)),  null);
и солнце б утром не вставало, когда бы не было меня
Re[107]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 07:49
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>C# точно ничем не хуже.

C# менее гибкий для обобщённого кода. Например
Python:
def add(x, y):
    return x + y

def sub(x, y):
    return x - y

def apply(f, *args):
    return f(*args)

print(apply(apply, apply, apply, add, 1, 2))
print(apply(apply, apply, sub, 11, 2))
C++:
auto add = [](auto x, auto y)
{
    return x + y;
};
auto sub = [](auto x, auto y)
{
    return x - y;
};

auto apply = [](auto f, auto... args)
{
    return f(args...);
};

print(apply(apply, apply, apply, add, 1, 2));
print(apply(apply, apply, sub, 11, 2));

C#?

Да и по большей части ориентирован на одну платформу (afaik Mono постоянно в роли догоняющего), в то время как Python использую на Windows/Linux/OS X.

EP>>^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит.

S> Вы используете питон для написания приложений. В этой ветке не раз подымался.

Python использую в нескольких контекстах:

1. Автоматизация сборки и тестов, в дополнение к CMake.
2. Некоторый софт для инженеров, в основном склеивающий другие проекты.

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

3. Всякие скрипты для личных нужд, работа с файлами, построение графиков, символьные вычисления и т.п.

Здесь бы подошёл и C++ (тем более C++14), но есть пара останавливающих факторов:
а) нет под рукой моментальных замен каким-то функциям/etc, точнее они даже есть — но нужно потратить время чтобы собрать это всё воедино, и сделать несколько обёрток чтобы было script-like.
б) нужно сделать workflow ближе к скриптам — настроить быструю компиляцию с запуском и/или интерпретацию через Cling.
И то и другое достижимо, но требует затрат времени, в то время как Python уже под рукой.

Были ещё какие-то use-case'ы, но сходу не вспомню.

S>Кроме того ты пример врапера именно для питона.


Первое что под руку попалось.
Re[90]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 07:59
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Аааа, так оно ещё и через COM это делается... ) Тогда уж точно никакой разницы с другими языками нет, причём уже прямо сейчас. Т.е. банально реализуем соответствующий COM интерфейс и без проблем используем его в 1C. Не знаю правда зачем, но делается это тривиально. )))

S>> Тебе нужно делать обертку Idispatch над объектом, типом. В Net это делается через Reflection к любому типу, объекту
S>>Раз это элементарно забацайка. В той статье класс оборачивает любой объект, тип. Поддержка энумераторов.
S>>Давай прямо сейчас.

_>Ну вообще то создание COM объектов в виде обёртки над существующими классами — это не самый лучший путь. По нормальному реализацию COM вставляют прямо в эти классы (мы же обычно заранее знаем, хотим ли мы поддерживать вызов нас через COM или нет). Соответственно реализация делается тривиально: http://doc.qt.io/qt-5/activeqt-activeqt-simple-example.html или например вот http://doc.qt.io/qt-5/activeqt-activeqt-comapp-example.html для полноценного приложения (exe) с документами и т.п., управляемого через COM.


Еще раз моя обертка для любого нетовского класса, который 1С ник может использовать только зная имя класса если сборка загружена либо AssemblyQualifiedName
если сборка находится в GAC.
_>Но если всё же есть большое желание создание COM обёртку над уже реализованными классами, то это естественно тоже не проблема: http://doc.qt.io/qt-5/activeqt-activeqt-wrapper-example.html.

S>> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки


_>Эээ что? )

То, что привел пример универсальной обертки. Где не нужно делать каких либо действий, кроме подписки на события.
Это плюсы Net, где есть Reflection, заглушка к COM, GC. Чего нет в C++. А решать все через предварительное создание враперов не выход, так как я не знаю, чего захочет 1С ник (какие классы, сборки будет использовать), так как врапер универсальный и в real time. По сути это бесплатное расширение 1С. Но самый смех в том, что это мало кому нужно.
и солнце б утром не вставало, когда бы не было меня
Re[107]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 08:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.

EP>>>>Какого параметра?
S>>> У класса есть методы, у метода есть параметры, в том числе и out
EP>>Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.
S>Воо теперь нужно сравнивать не только тип, но и его эквивалентность

Я говорю не про сами типы, а про интерфейсы.

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

EP>>>>Из-за чего?
EP>>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
S>>> А обращаться к несуществующим полям, или массивам меньшей длины?
EP>>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет.
S> У тебя расположение полей может быть другое.

И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.

EP>>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.

S> А как ты понимаешь обращение к полям, вызов метода. Смещение полей, методов может меняться.

Ни смещение полей, ни методов, роли не играет пока мы к ним не обращаемся напрямую. Также не играет роли sizeof пока мы сами не создаём объекты.

S>Даже VMT и та может поменяться. Да и методы могут в реалии иметь другую сигнатуру.


Это уже изменение интерфейса.

EP>>Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения

S>Про валуе типы я подправил. А вот то, что полями могут быть экземпляры классов, как раз и говорит о деревьях.
S>Так как полей объектов тоже могут быть поля объекты.

И что из этого?

EP>>Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.

EP>>Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S> Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах

Подробнее.

S>>>>>Ну и конечно твой нелюбимый GC

EP>>>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>>>Да и причём тут GC?
S>>> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
EP>>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
S> То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
S>Такого даже в Delphi нет.

Ещё раз, они реализуются неинтрузивно, тем более когда речь идёт о враппере под IDispatch.
Re[91]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 08:30
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Еще раз моя обертка для любого нетовского класса, который 1С ник может использовать только зная имя класса если сборка загружена либо AssemblyQualifiedName

S>если сборка находится в GAC.

Ну так а для использования из 1C C++ кода, сделанного с поддержкой COM'a даже и никакие обёртки не нужны.

S>>> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки

_>>Эээ что? )
S> То, что привел пример универсальной обертки. Где не нужно делать каких либо действий, кроме подписки на события.
S>Это плюсы Net, где есть Reflection, заглушка к COM, GC. Чего нет в C++. А решать все через предварительное создание враперов не выход, так как я не знаю, чего захочет 1С ник (какие классы, сборки будет использовать), так как врапер универсальный и в real time. По сути это бесплатное расширение 1С. Но самый смех в том, что это мало кому нужно.

Вообще то мы сравнивали сложность написания C# и C++ кода, который потом будут вызывать из 1C. Так вот в этом разницы не видно. Если же ты хочешь поговорить о возможности запуска из 1C некого чужого, скомпилированного в бинарник кода, то это уже совсем другой вопрос для другой дискуссии.
Re[108]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 08:40
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>>C# точно ничем не хуже.

EP>C# менее гибкий для обобщённого кода. Например

EP>Python:
EP>
EP>def add(x, y):
EP>    return x + y

EP>def sub(x, y):
EP>    return x - y

EP>def apply(f, *args):
EP>    return f(*args)

EP>print(apply(apply, apply, apply, add, 1, 2))
EP>print(apply(apply, apply, sub, 11, 2))
EP>
C++:

EP>
EP>auto add = [](auto x, auto y)
EP>{
EP>    return x + y;
EP>};
EP>auto sub = [](auto x, auto y)
EP>{
EP>    return x - y;
EP>};

EP>auto apply = [](auto f, auto... args)
EP>{
EP>    return f(args...);
EP>};

EP>print(apply(apply, apply, apply, add, 1, 2));
EP>print(apply(apply, apply, sub, 11, 2));
EP>

EP>C#?

https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx
Ну и джененрики интефейсы
EP>Да и по большей части ориентирован на одну платформу (afaik Mono постоянно в роли догоняющего), в то время как Python использую на Windows/Linux/OS X.

Сейчас будут развиваться параллельно так же.
EP>>>^^^^ Прочти то что сам написал, и попробуй расшифруй что это значит.
S>> Вы используете питон для написания приложений. В этой ветке не раз подымался.

EP>Python использую в нескольких контекстах:


EP>1. Автоматизация сборки и тестов, в дополнение к CMake.

EP>2. Некоторый софт для инженеров, в основном склеивающий другие проекты.

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


EP>3. Всякие скрипты для личных нужд, работа с файлами, построение графиков, символьные вычисления и т.п.


То есть, что не удобно делать на С++.
EP>Здесь бы подошёл и C++ (тем более C++14), но есть пара останавливающих факторов:
EP>а) нет под рукой моментальных замен каким-то функциям/etc, точнее они даже есть — но нужно потратить время чтобы собрать это всё воедино, и сделать несколько обёрток чтобы было script-like.
EP>б) нужно сделать workflow ближе к скриптам — настроить быструю компиляцию с запуском и/или интерпретацию через Cling.
EP>И то и другое достижимо, но требует затрат времени, в то время как Python уже под рукой.

Вот а в C# практически все в одном.
EP>Были ещё какие-то use-case'ы, но сходу не вспомню.

S>>Кроме того ты пример врапера именно для питона.


EP>Первое что под руку попалось.
и солнце б утром не вставало, когда бы не было меня
Re[108]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 08:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>>>Если объекты создаются из разных DLL пусть это даже будут копии, то это уже будут разные типы. И при передаче параметра будет вызвано исключение.

EP>>>>>Какого параметра?
S>>>> У класса есть методы, у метода есть параметры, в том числе и out
EP>>>Если у параметра тип который даёт единый ABI интерфейс для разных версий — то никаких проблем не будет.
S>>Воо теперь нужно сравнивать не только тип, но и его эквивалентность

EP>Я говорю не про сами типы, а про интерфейсы.

А при чем здесь интерфейсы? Ааааах да в DLL то с классами проблема из-за версионности. А в Net есть GAC.

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

EP>>>>>Из-за чего?
EP>>>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
S>>>> А обращаться к несуществующим полям, или массивам меньшей длины?
EP>>>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет.
S>> У тебя расположение полей может быть другое.

EP>И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.

А в Net можно и без VMT и со статическими методами.

EP>>>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.

S>> А как ты понимаешь обращение к полям, вызов метода. Смещение полей, методов может меняться.

EP>Ни смещение полей, ни методов, роли не играет пока мы к ним не обращаемся напрямую. Также не играет роли sizeof пока мы сами не создаём объекты.

А как мы должны обращаться к методам класса? В Net за соответствие типов отвечает среда выполнения.

S>>Даже VMT и та может поменяться. Да и методы могут в реалии иметь другую сигнатуру.


EP>Это уже изменение интерфейса.

А они имеют свойства меняться. В Com эта проблема решенная в Net
EP>>>Про деревья нашёл вот тут — то есть правка уже после того как я прочитал и начал отвечать. Ты если делаешь существенные правки — выноси их в отдельные сообщения
S>>Про валуе типы я подправил. А вот то, что полями могут быть экземпляры классов, как раз и говорит о деревьях.
S>>Так как полей объектов тоже могут быть поля объекты.

EP>И что из этого?


EP>>>Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.

EP>>>Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S>> Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах

EP>Подробнее.

Подробнее не времени. Ссылки на объект могут быть как из враперов (а их может быть несколько если они не кэшируются), так и внутри объектов.
Нужен подсчет ссылок объекта

S>>>>>>Ну и конечно твой нелюбимый GC

EP>>>>>Почему нелюбимый? Без проблем использую языки с GC, о чём тебе лично уже пару раз сказал. Я даже как-то делал копирующий GC for fun.
EP>>>>>Да и причём тут GC?
S>>>> А то, что не нужен подсчет ссылок в объекте. GC сам ведет подсчет.
EP>>>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
S>> То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
S>>Такого даже в Delphi нет.

EP>Ещё раз, они реализуются неинтрузивно, тем более когда речь идёт о враппере под IDispatch.

Блин а русских словей у тебя нет?
и солнце б утром не вставало, когда бы не было меня
Re[92]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 08:51
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>> Еще раз моя обертка для любого нетовского класса, который 1С ник может использовать только зная имя класса если сборка загружена либо AssemblyQualifiedName

S>>если сборка находится в GAC.

_>Ну так а для использования из 1C C++ кода, сделанного с поддержкой COM'a даже и никакие обёртки не нужны.

А вот мне не нужна поддержка ком любого нетовского класса. Это уже издевательство какое то.

S>>>> Это еще раз подтверждение того, что ты невнимательно читаешь ссылки

_>>>Эээ что? )
S>> То, что привел пример универсальной обертки. Где не нужно делать каких либо действий, кроме подписки на события.
S>>Это плюсы Net, где есть Reflection, заглушка к COM, GC. Чего нет в C++. А решать все через предварительное создание враперов не выход, так как я не знаю, чего захочет 1С ник (какие классы, сборки будет использовать), так как врапер универсальный и в real time. По сути это бесплатное расширение 1С. Но самый смех в том, что это мало кому нужно.

_>Вообще то мы сравнивали сложность написания C# и C++ кода, который потом будут вызывать из 1C. Так вот в этом разницы не видно. Если же ты хочешь поговорить о возможности запуска из 1C некого чужого, скомпилированного в бинарник кода, то это уже совсем другой вопрос для другой дискуссии.

Да написания C# кода вообще не существует. Используются любые нетовские классы.
Так запускается то скомпилированный код сборки. Ну читайте внимательно о чем речь. Вы же С++ ники белая кость.

public object CreateObject(object type)
        {

            var res = ТипДляСоздатьОбъект(type);
            return AutoWrap.ОбернутьОбъект(System.Activator.CreateInstance(res));

        }

        public object СоздатьОбъект(object Тип, params object[] argOrig)
        {
            //   MessageBox.Show(Тип.ToString() + " параметров=" + args.Length.ToString());

            var res = ТипДляСоздатьОбъект(Тип);

            object[] args = AutoWrap.ПолучитьМассивРеальныхОбъектов(argOrig);
            return AutoWrap.ОбернутьОбъект(System.Activator.CreateInstance(res, args));

        }


https://msdn.microsoft.com/ru-ru/library/system.activator.createinstance(v=vs.110).aspx
Activator.CreateInstance — метод

Создает экземпляр указанного типа, используя конструктор, соответствующий заданным параметрам.
Кстати в Net 4.5 появилась поддержка для Com params object[]
и солнце б утром не вставало, когда бы не было меня
Отредактировано 12.10.2015 8:57 Serginio1 . Предыдущая версия .
Re[109]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 08:58
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>>>C# точно ничем не хуже.
EP>>C# менее гибкий для обобщённого кода. Например
EP>>Python:
EP>>C++:
EP>>C#?

S>https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx


И как это относится к примеру?

S>Ну и джененрики интефейсы


Покажи код.

EP>>3. Всякие скрипты для личных нужд, работа с файлами, построение графиков, символьные вычисления и т.п.

S> То есть, что не удобно делать на С++.

Почему по-твоему не удобно?

S> Вот а в C# практически все в одном.


Язык менее гибкий чем Python. А плюсы-то какие?
Re[41]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.15 09:04
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>>>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.

EP>>>Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил
I>> Алё, я эти издержки вообще не считаю. На кой ляд ты доказываешь мне, что они ничтожны ?

EP>В этом случае других издержек нет


Ну да, а граф объектов разрушится за время 0.
Re[109]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 09:10
Оценка:
Здравствуйте, Serginio1, Вы писали:

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

EP>>>>>>Из-за чего?
EP>>>>>>Объекты могут быть разных версий, иметь разные менеджеры памяти, и при этом прекрасно сочетаться друг с другом
S>>>>> А обращаться к несуществующим полям, или массивам меньшей длины?
EP>>>>Проблемы будут есть вызывать методы одного класса на объекте другого. Если методы виртуальные и интерфейсы не поменялись, или вообще динамические а-ля Invoke — то проблемы не будет.
S>>> У тебя расположение полей может быть другое.
EP>>И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.
S> А в Net можно и без VMT и со статическими методами.

Минуя COM?

EP>>>>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.

S>>> А как ты понимаешь обращение к полям, вызов метода. Смещение полей, методов может меняться.
EP>>Ни смещение полей, ни методов, роли не играет пока мы к ним не обращаемся напрямую. Также не играет роли sizeof пока мы сами не создаём объекты.
S> А как мы должны обращаться к методам класса? В Net за соответствие типов отвечает среда выполнения.

Если речь идёт про COM, то через виртуальную таблицу, а её layout зависит от интерфейса.

EP>>>>Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.

EP>>>>Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S>>> Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах
EP>>Подробнее.
S> Подробнее не времени. Ссылки на объект могут быть как из враперов (а их может быть несколько если они не кэшируются), так и внутри объектов.
S>Нужен подсчет ссылок объекта

Проблема в чём?

EP>>>>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release

S>>> То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
S>>>Такого даже в Delphi нет.
EP>>Ещё раз, они реализуются неинтрузивно, тем более когда речь идёт о враппере под IDispatch.
S>Блин а русских словей у тебя нет?

"неинтрузивно" — то есть не меняя сам класс. Счётчик ссылок, также как и вся кухня Invoke/etc, будет во враппере.
Re[35]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.15 09:10
Оценка:
Здравствуйте, ·, Вы писали:

I>>Все эти вещи когда то писали на Си/С++. Питон, перл, пхп — все это выстрелило уже после того, как С++ оттуда ушел.

·>Что-то сомневаюсь. C ещё может быть, С++ — очень вряд ли. Но С просто старше. А уж LAMP всегда был классикой. Веб на С — это либо экзотика, либо старьё.

Смешно. "всегда" началось совсем недавно, от силы 10 лет назад.

I>>·>Наравне с Java.

I>>Джава в роли догоняющего.
·>Примерно как С++ догоняет Кобол.

Кобол в HFT ? Пудозреваю, исключительно за счет С++.

I>>·>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.

I>>По факту запрещено многие вещи вызывать именно из за этого ограничения.
·>Что запрещено? Не понял мысль.

Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`.
Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд.
Re[42]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 09:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>>>Браво, капитан, глубина не изменится, потому что граф объектов будет тем же самым.

EP>>>>Значит весь оверхед от случаев где ref-counting это исключительно подстраховка — это inc/dec (которых на C++11 существенно меньше). О чём я и говорил
I>>> Алё, я эти издержки вообще не считаю. На кой ляд ты доказываешь мне, что они ничтожны ?
EP>>В этом случае других издержек нет
I>Ну да, а граф объектов разрушится за время 0.

Он разрушался бы даже если убрать этот ref-counting, который был лишь исключительно для подстраховки (а речь именно об этом случае).
Re[110]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 09:18
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>>>>C# точно ничем не хуже.
EP>>>C# менее гибкий для обобщённого кода. Например
EP>>>Python:
EP>>>C++:
EP>>>C#?

S>>https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx


EP>И как это относится к примеру?

https://msdn.microsoft.com/ru-ru/library/s53ehcz3.aspx
Я могу через рефлекшн вызвать соответствующие методы.
https://msdn.microsoft.com/ru-RU/library/system.datetime.op_addition(v=vs.71).aspx
S>>Ну и джененрики интефейсы

EP>Покажи код.

Нет времени.
EP>>>3. Всякие скрипты для личных нужд, работа с файлами, построение графиков, символьные вычисления и т.п.
S>> То есть, что не удобно делать на С++.

EP>Почему по-твоему не удобно?


S>> Вот а в C# практически все в одном.


EP>Язык менее гибкий чем Python. А плюсы-то какие?

Это с чего это менее гибкий?
То есть ты плюсов не видишь? Я потратил кучу времени, а ты даже плюсов не нашел. Смысл в разговоре?
и солнце б утром не вставало, когда бы не было меня
Re[110]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 09:22
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


S>>>> У тебя расположение полей может быть другое.

EP>>>И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.
S>> А в Net можно и без VMT и со статическими методами.

EP>Минуя COM?

Да
EP>>>>>Если же у тебя в голове какой-то use-case, в котором метод одного класса вызывается на объекте другого класса — то так и опиши его, я мысли читать не умею.
S>>>> А как ты понимаешь обращение к полям, вызов метода. Смещение полей, методов может меняться.
EP>>>Ни смещение полей, ни методов, роли не играет пока мы к ним не обращаемся напрямую. Также не играет роли sizeof пока мы сами не создаём объекты.
S>> А как мы должны обращаться к методам класса? В Net за соответствие типов отвечает среда выполнения.

EP>Если речь идёт про COM, то через виртуальную таблицу, а её layout зависит от интерфейса.

Вообще то речь идет про доступ к С++ и .Net объектам через Idispatch.
Ghb 'njv j,]trns vjuen gthtlfdfnmcz bp hfpys[ ВДД

EP>>>>>Подсчёт ссылок есть у враппера — он предоставляет AddRef/Release, которые должен дёргать клиент в соответствии с протоколом COM.

EP>>>>>Если например запрашивается свойство не примитивного типа — возвращается новый враппер, при этом если у этого свойства в оригинале нет своего подсчёта ссылок, то будет использоваться счётчик агрегирующего объекта.
S>>>> Подсчет ссыло врапера не спасает, от того, что тебе нужно либо считать ссылки на объект, либо перед удалением искать ссылки во враперах
EP>>>Подробнее.
S>> Подробнее не времени. Ссылки на объект могут быть как из враперов (а их может быть несколько если они не кэшируются), так и внутри объектов.
S>>Нужен подсчет ссылок объекта

EP>Проблема в чём?

У тебя нет проблем.Ты даже ни одного примера с полями объектами не привел.
EP>>>>>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release
S>>>> То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
S>>>>Такого даже в Delphi нет.
EP>>>Ещё раз, они реализуются неинтрузивно, тем более когда речь идёт о враппере под IDispatch.
S>>Блин а русских словей у тебя нет?

EP>"неинтрузивно" — то есть не меняя сам класс. Счётчик ссылок, также как и вся кухня Invoke/etc, будет во враппере.

Ну дык он должен поменяться не только для врапера но и везде где используется
и солнце б утром не вставало, когда бы не было меня
Re[111]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 09:50
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>>>>>C# точно ничем не хуже.
EP>>>>C# менее гибкий для обобщённого кода. Например
EP>>>>Python:
EP>>>>C++:
EP>>>>C#?
S>>>https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx
EP>>И как это относится к примеру?
S> https://msdn.microsoft.com/ru-ru/library/s53ehcz3.aspx
S>Я могу через рефлекшн вызвать соответствующие методы.
S>https://msdn.microsoft.com/ru-RU/library/system.datetime.op_addition(v=vs.71).aspx

Да причём тут это? Пример про простую функцию высшего порядка apply — на Python и C++ она элементарно реализуется. Покажи аналог на C#.

S>>>Ну и джененрики интефейсы

EP>>Покажи код.
S> Нет времени.

Необязательно прям сейчас.

S>>> Вот а в C# практически все в одном.

EP>>Язык менее гибкий чем Python. А плюсы-то какие?
S> Это с чего это менее гибкий?

Покажи пример с apply — на нём видно как раз.

S>То есть ты плюсов не видишь? Я потратил кучу времени, а ты даже плюсов не нашел. Смысл в разговоре?


Какие плюсы у C# перед Python примирительно к скриптам?
Re[111]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 09:55
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>> У тебя расположение полей может быть другое.

EP>>>>И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.
S>>> А в Net можно и без VMT и со статическими методами.
EP>>Минуя COM?
S> Да

И к чему это? Речь-то шла про COM

EP>>>>>>Счётчик должен быть внутри компонента, это базовый интерфейс — IUnknown. То что конкретные клиенты могут вызывать AddRef/Release на основе разных подходов — дело десятое, и не снимает необходимости в вызове этих AddRef/Release

S>>>>> То есть в С++ все классы реализуют IUnknown с автоматическим AddRef/Release?
S>>>>>Такого даже в Delphi нет.
EP>>>>Ещё раз, они реализуются неинтрузивно, тем более когда речь идёт о враппере под IDispatch.
S>>>Блин а русских словей у тебя нет?
EP>>"неинтрузивно" — то есть не меняя сам класс. Счётчик ссылок, также как и вся кухня Invoke/etc, будет во враппере.
S> Ну дык он должен поменяться не только для врапера но и везде где используется

Он и для враппера не меняется.
Re[43]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.15 10:25
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>Ну да, а граф объектов разрушится за время 0.


EP>Он разрушался бы даже если убрать этот ref-counting, который был лишь исключительно для подстраховки (а речь именно об этом случае).


В пятый раз говорю — речь совсем про другое.
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 10:54
Оценка:
Здравствуйте, alex_public, Вы писали:

_>А ты их сам сравнивал? ) Я вот сравнивал и MSVS и Eclipse и Netbeans и QtCreator. MSVC кстати весьма слабенький для C++, если не пользоваться VisualAssist'ом (отдельная платная штука). Eclipse и Netbeans весьма похожи между собой по возможностям и при этом существенно отличаются от того же QtCreator. У них используется модель полного анализа кода, которая позволяет такую возможность как подчёркивать невалидный код до компиляции и т.п.. Но цена у этого жуткие тормоза. Ну точнее если работать только с ними, то постепенно привыкаешь к тормознутости IDE... Но если вдруг при этом включить QtCreator, то такое впечатление что он просто мгновенный. Но при этом он делает не полный анализ кода... В принципе выбор между этими продуктами является делом вкуса. Но говорить о явном преимуществ какой-то из них странно.

QtCreator проще тем, что это только С++ и больше ничего. Другие IDE — это целая платформа с кучей расширений и плагинов.

_>Кстати, недавно одному моему товарищу, работающему в основном в мире Java, потребовалось сделать приложение с GUI на C++. Он взял библиотеку Qt (по моему совету) и соответственно QtCreator в качестве IDE (ради удобного встроенного редактора форм/сигналов и т.п.). Так вот он был в полном восторге (особенно от всяческих автоматических компоновщиков и их поддержке в редакторе, управлением сигналами и т.п.) от этого инструмента (накидал довольно сложный GUI за несколько дней), причём во многом он удивлялся что так вообще можно (в своём java мире он такого не встречал).

Java в GUI не самая лучшая, родные средства довольно убогие и устаревшие. Надо было хотя бы c# взять, правда оно win-only.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 10:58
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Undefined behaviour это по стандарту языка, без учёта работы ОС. Ну т.е. да, для каких-нибудь микроконтроллеров там действительно будет порча памяти, но на этих МК такие вещи как Java/C# вообще не живут. А в любой современной ОС мы получим соответствующее исключение.

_>·>Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.
_>Ну так у меня же мало практики в написание заведомо некорректного кода. Я вообще сам delete раз год вижу, даже с корректным кодом. А тут такое... )))
Ты написал его типично. Чаще так оно и происходит. Время жизни в одном месте, удаление в другом месте, добавленное в другое время, другим девом в другом потоке.

_>·>И ты правда не видел битых указателях в реальных проектах? Укажи, плиз, номер твоей планеты в тентуре.

_>В своих, ушедших в продакшен, — не видел. )
А сколько девов принимало участие? Сколько человеколет? Если меньше 5 девов, менее сотни человеколет, то это мелкие проекты... Их хоть на ассемблере пиши, не принципиально.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 11:08
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Дефолтное — это value type и контейнеры stl. Есть парочка редких случаев, когда применение этих инструментов приводит к не самому оптимальному кода (и тогда как раз делают всяческие кастомные аллокаторы и т.п.), но лично я на них натыкался исключительно в обсуждениях на форумах и т.п., а не в личной практике.

_>·>В дефолтном случае и GC замечательно работает. А вот эти обсуждаемые извращения в Яве это и есть те самые редкие случаи.
_>Нет, это как раз совсем разные случаи. Единственный сценарий, на котором GC начинает конкурировать с обычной работой с памятью в C++ — это режим создания/удаления множества мелких объектов в куче. Так вот этот режим в C++ встречается на очень редком классе задач (и для них уже есть смысл рассматривать спец. аллокаторы и т.п.). И задачи типа реалтайма или высокой нагрузки точно не относятся к этому исключению — там как раз эффективны стандартные техники C++.
Говорю же — два режима оптимальны. Второй режим — объекты создаются и уничтожаются редко. Редко меняется граф объектов в памяти. (т.е. топология графа не меняется, но данные внутри объектов меняться могут).

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

_>В то же время в Java режим создания/удаления множества мелких объектов в куче — это норма. И хотя GC не так плохо справляется тут, но он намного отстаёт от C++ на большинстве задач, т.к. в C++ в этих случаях используется другой режим (который априори быстрее). И только в том случае, когда и в C++ необходимо плодить сущности типа shared_ptr, быстродействие может сравниться (при условие, что в C++ не будем вводить кастомные извращения).

_>Соответственно, чтобы догнать C++ на задачах реалтайма, высокой нагрузки и т.п. (в остальных областях тоже медленно, но всем просто пофиг) в Java переходят от дефолтного режима на некое извращение с рукопашными буферами и т.п. ужасами для эмуляции стандартных техник C++.
Собственно и в плюсах ты переходишь от комфортного by-value/on stack к хитрым аллокаторам, жонглированию различными типами указателей, повышая риск что-то поломать или потерять.

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

Собственно в LL-системе "плохая" часть очень маленькая. Только из малой области кода выжимаются все соки, а остальное пишется как обычно, с комфортом GC.

_>>>·>А ты часто обдумываешь в какие регистры процессора какая переменная попадёт?

_>>>Совершенно не обдумываю, причём по разным причинам в двух разных случаях. В случае отсутствия необходимости в быстродействие (кстати в этом случае у меня скорее Питон в руках будет) понятно что не обдумываю потому что безразлично. А в случае необходимости высокого быстродействия и использования C++ тоже не обдумываю, потому как знаю, что оптимизатор современных компиляторов C++ создаст код лучше любого эксперта в ассемблере.
_>·>Собственно та же ситуация и с GC.
_>Абсолютно не такая же. Напомню, что мы здесь обсуждали возможности JIT выбрать расположение и типы данных (куча/стек, ссылка/значение и т.д.) наиболее оптимальным способом. И в отличие от качества генерирования ассемблерного кода оптимизаторами C++, тут ситуация даже не приблизилась к идеалу. И я сомневаюсь что приблизится когда-нибудь, т.к. тут задача намного сложнее.
Принципиально — для JIT оптимизаций доступно гораздо больше информации, т.к. оно работает во время испонения. И оптимизация происходит именно в соответствии с реальной нагрузкой. Есть, конечно Profile Guided Optimisation, но она, насколько я знаю, представляет в основном академиеческий интерес.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 11:22
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Лично я не увидел в этом списке чего-то необычного, заставившего писать непривычный код.

_>·>А тебе вообще доводилось писать LL код?
_>Я же тебе уже даже примеры приводил. ) И да, оно не из области финансов. )))
В смысле видео|игры?

_>·>В ФФ бОльшая пользовательская часть это js, xul и прочее. А вообще браузер системная вещь — основное назначение — взаимодействие с железом и ОС. Не путай с прикладными приложениями, типа очередной бухгалтерии или склада.

_>Да, написание приложения на C++ со встроенным скриптовым языком — это стандартная техника написания сложных и эффективных приложений. Это не только браузеры, но и тяжёлые игры и всякий профессиональный софт (CAD'ы, редакторы/рендереры и т.п.)и ещё много где. Проще вспомнить где такого нет. ))) Кстати, мы такое тоже используем.
Вот и считай... что java это такой встроенный скриптовый язык для решения прикладных задач — обработать 20000 заявок в секунду. И нет такой прикладной задачи "разместить структуру данных в памяти последовательно с минимумом индирекций".

_>Да, и браузер — это совсем не системный софт (с каких это пор взаимодействие с ОС стало признаком системного софта?), т.к. работает на обычном пользовательском уровне. Системный софт — это всяческие драйверы, сервисы и т.п. )

Браузер не решает _прикладные_ задачи (т.е. задача непосредственно решаемая конечным пользователем). Прикладная задача — читать емейл, инвестировать деньги, купить беззеркалку, поставить лайк. А рендер html/css, выполнение js — это не прикладные задачи. И, что характерно, всякие прикладные вещи в браузере типа управление списком скачанных файлов, диалоги настроек и т.п — пишется на js/xul.

_>>>Так а зачем я тогда буду делать такой MaClass? ))) Кстати, куча полей — это сколько? ) Ты в курсе размера линии кэша современных процессоров? )

_>·>"Дефолтное — это value type и контейнеры stl" и даст тебе тот самый жирный MyClass.
_>·>Кеш в районе всего лишь нескольких мегабайт — копейки же, миллиончик элементов — и упс, кончилось.
_>Хыхы, в данном случае важнее размер не всего кэша, а именно его линий (в соотношение с размером самого объекта). А так же очевидная для предсказателя последовательность выборки.
Линия вроде вообще 64 байта или что-то типа того. Или я с чем-то путаю?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[91]: Java vs C# vs C++
От: -MyXa- Россия  
Дата: 12.10.15 12:12
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Со свойствами проблема, но их можно динамически обернуть. То есть сделать обертку над классом для описания свойв.

S>Для простых случаев можно так.
S>[cs]
S> [ComVisible(true)]
S> [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
S> // [Guid("33B45C9D-1AED-41F9-8880-36AB6AE84749")]
S> public interface IEventFor1C

S> Либо пишу ручками используя анонимные типы. И подписка


Не понял, для каких простых случаев, какими ручками? Ты же оборачиваешь произвольную .NET сборку в COM.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[30]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 12:34
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>А зачем человеку доказывать? Например:

EP>>>Результат может содержать ссылку на этот unique, а может не содержать. Человек может например просто знать из документации что в результирующем объекте нет этого unique.
dot>>Тут мне кто-то рассказывал, что надо голые указатели использовать при передаче между потоками.
EP>Для не владеющих указателей — да. Здесь речь идёт про владеющий. Да и к чему ты тему переводишь?
Довольно нетривиально доказать кто чем владеет. Тем более в развивающемся проекте.

EP>>>Анализатору же придётся это доказывать проинлайнив весь код.

dot>>Да пусть доказывает, он железный, зарплату не просит.
EP>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей.
Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.

EP>>>Это изменение контракта, которое прекрасно выражается в системе типов — у doSomething поменяется тип параметра и приведённый код не скомпилируется

dot>>Поменяется с чего на что? как было (Widget &w) так и останется, если не лепить _ptr на каждый чих.
EP>Теперь ей требуется владение — так как есть передача куда-то что может жить дольше caller'а. Вот тут как раз будет либо *_ptr, либо например rv ref — и то и другое приведёт к ошибке компиляции в старом клиентском коде
В момент внесения изменения было очевидно, что он не может быть дольше. А вот в процессе десятка других изменений, растянутых во времени, да и при стечении обстоятельств — вдруг пережило чуть дольше, чем предполагалось изначально.

dot>>При сборке Eden Space оно и грохнется,

EP>Оно бы грохнулось в тот же самый момент и без EA.
Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.
Разница может быть заметна, если у тебя этот vector возвращается по значению из функции и его размер большой, что передачу by-value сделает неэффективой. А значит ты должен будешь его в unique_ptr обернуть или надеяться на RVO.

dot>>не совсем при выходе из стека, но очень близко.

EP>То есть совсем не при выходе из стэка.
dot>>А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.
EP>У него тоже ничего не поломается. Даже если бы это был просто vector<T>, без unique_ptr — то тоже ничего бы не поломалось
Это если голые указатели не использовать.

dot>>>>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.

EP>>>Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет.
dot>>Ты так говоришь, как будто это что-то плохое.
EP>Это очевидный недостаток. Например есть текст, нужно передать куда-то отдельный абзац — на C++ достаточно например либо двух указателей, либо указателя и числа символов, либо просто указателя на начало абзаца. На Java же придётся ещё таскать ссылку на сам текст.
В общем да, есть такое. Хотя далеко не факт, что это может стать какой-либо проблемой... В типичном приложении у тебя скорее всего будет ссылка на какой-нибудь Document, по которому можно найти его текст. Поэтому будет достаточно пары индексов. А в большинстве случаев помещение двух или трёх чисел на стек — погоды не делает.

EP>>>>>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.

dot>>>>Так и разные алгоритмы GC есть. И столько всего можно крутить... И я уверен, что вариантов даже больше, ибо ссылка в jvm более абстрактна чем указатели в плюсах, а значит больше простора для оптимизаций.
EP>>>Так вот покажи GC не с сублинейной сложностью, желательно ещё чтобы был более-менее популярен.
dot>>Если вдруг GC начинает работать в режиме, что его сложность становится O(N) — ты делаешь что-то не то, тебе надо крутить настройки или даже изменять код.
EP>Нет гарантии что она завтра вдруг не выстрелит
А где ты берёшь гарантию, что какая-нибудь фрагментация кучи или битая ссылка не выстрелит?

dot>>>>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.

EP>>>Штуки типа cuckoo hashing не на ровном месте появились.
dot>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).
EP>Меняет — поиск и удаление константы в худшем случае.
А добавление?

dot>>Так и gc не лыком шиты.

EP>И что? Это меняет их сложность?
Нет. Но на практике, если GC начинает работать в worst case режиме, т.е. с O(n), приложение просто не используют. Скорее всего JVM тупо самоубьётся. Такое происходит на порядки реже, чем битые ссылки в плюсах.

dot>>>>Не смертельно.

EP>>>Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код.
dot>>Комбинации чего?
EP>Структура данных * контейнер * алгоритм * etc. ЕМНИП даже в C# для разных структур generic даёт разные воплощения.
Круто, конечно. Но в горячем коде таких комбинаций обычно единицы. А остальному коду это всё не важно.

dot>>Сколько их? (только практику плз, а не теоретические рассуждения)

EP>Очень много, это практика, реальный код.
EP>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.
Не факт, что это принесёт хоть какую-то пользу. compile time же.

dot>>Если можно было бы — писали бы и на асме, в LL все средства идут в ход.

EP>Вряд ли получится ASM лучше того что даст C++, за какое-нибудь разумное время. Интринсинки — да, полезны, но это не ASM.
Естественно. Если получилось бы — использовали бы.

dot>>>>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.

EP>>>А например в хэш-таблице?
dot>>Если значение большое, то индирекция нужна, иначе сам массив хеш-таблицы будет слишком большим и не помещаться в кеш.
EP>1. Если малое — то уж точно не нужна, тут разногласия нет.
EP>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме
EP>3. Ключ может хранится отдельно от значения, причём без индерекции.
Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.

dot>>Если значение маленькое, то это скорее всего будет примитив.

EP>С чего бы это?
Потому что примитив это те же 8 байт, что уже не так уж мало.

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

EP>>>В случае с GC что будешь делать?

dot>>Подстрою GC.
EP>Подстройка называется GC-free/off-heap , да?
В большинстве случаев достаточно покрутить параметры самого gc — интервалы сборки, размеры поколений, етс.

dot>>Элементы — пусть лежат, если ты не создаёшь|удаляешь их постоянно, а просто меняешь их поля — GC вообще не парится. GC ведёт себя плохо если постоянно меняется граф объектов долго лежащих в памяти.

EP>Если короче, то вот это утверждение неверное:
EP>

dot>>Так в этих же случаях и в яве всё будет всё в YG, а значит никакого жуткого O(N).

По приведённому тобой случаю вообще непонятно что там происходит. Если там просто данные меняются, то да, не будет O(n), а если объекты среднеживущие и постоянно всё жутко перетасовывается, то да — gc будет тормозить.

dot>>Собственно это соответствует сложному жонглированию владением в C++,

EP>Не сложному, и не соответствует. Большинство случаев владения (и "жонглирования" им) C++ это простейший by-value.
by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.

dot>>где это запросто приведёт к битым указателям, если у вас в команде не Александреску с Страуструпом под руководством Кнута.

EP>"Запросто" не приведёт. А вот valgrind запросто отловит.
В многопоточном?.. Может отловит, может и не отловит...

EP>>>Конечно будет, и это одна из причин почему положит на лопатки.EP>>>Именно так и происходит
Автор: Evgeny.Panasyuk
Дата: 06.06.15
в Emscripten, который компилирует C++ в JS.

EP>>>И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить.
dot>>Ну и кому эти микробенчмарки нужны?
EP>Тем кого интересует скорость
Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.

dot>>Ты давай пример системы на плюсах, компилированных под jvm.

EP>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.
Потому и не знаешь, что принципиально невозможно.

dot>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.

EP>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.
Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.

dot>>Кстати, это, конечно, очень субъективно, но когда я искал работу (London), я всегда писал Java/C++ и выбирал finance. И из ~сотни интерьвю не было ни одного С++. Выводы, конечно, можно сделать разные... но всё же.

EP>Конечно субъективно — мне как раз оттуда приходили варианты C++, правда не finance, и я вообще не искал. И что характерно не было ни одной Java.
Мне тоже приходили... судя по всему анализируют резюме по ключевым словам и шлют ковровые рассылки, и зарплаты примерно в 2 раза меньше...

EP>>>>>Те же структуры есть в C#.

dot>>>>А толку-то от них...
EP>>>Не нужно вручную нарезать массивы на структуры
dot>>И что это даёт? Что позволяет добиться?
EP>Добиться меньшего количества низкоуровневого error-prone кода.
Ну и? Добились меньшего количества кода. А дальше что? И где же low latency C#-системы?
Ни один вменяемый заказчик не ставит цель "меньше кода". Цель — чтобы работало с указанными требованиями. Java, как показывает практика, работает и без стркутрур. Пусть кода чуть больше, но в целом система проще.
При наличии хорошей IDE количество кода практически ни на что не влияет. А простота кода, минимум конструкций — даёт много ништяков.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[112]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 13:05
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>>> У тебя расположение полей может быть другое.

EP>>>>>И что? К ним доступ напрямую не осуществляется, только через виртуальную таблицу.
S>>>> А в Net можно и без VMT и со статическими методами.
EP>>>Минуя COM?
S>> Да

EP>И к чему это? Речь-то шла про COM

Речь шла про доступ к объектамчерез Idispatch.
Еще раз приведу ссылки

http://infostart.ru/public/238584/
http://rsdn.ru/forum/dotnet/4296659.1
Автор: Serginio1
Дата: 02.06.11


Я первоначальный вариант сделал за 15 минут. Раз это это элементарно сделайте и 1С ники будут вам благодарны
EP>Он и для враппера не меняется.
Короче сделай раз это элементарно аналог по моим ссылкам.
У Net варианта есть минус в том, что должен установлен Net.
и солнце б утром не вставало, когда бы не было меня
Re[92]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 13:12
Оценка:
Здравствуйте, -MyXa-, Вы писали:

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


S>>Со свойствами проблема, но их можно динамически обернуть. То есть сделать обертку над классом для описания свойв.

S>>Для простых случаев можно так.
S>>
S>> [ComVisible(true)]
S>>    [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
S>>  //  [Guid("33B45C9D-1AED-41F9-8880-36AB6AE84749")]
S>>    public interface IEventFor1C

S>> Либо пишу ручками используя анонимные типы. И подписка

MX>Не понял, для каких простых случаев, какими ручками? Ты же оборачиваешь произвольную .NET сборку в COM.

Простых случаев это для методов без параметров и методом с параметром типа Object/

[code]
врап=новый COMОбъект("NetObjectToIDispatch45");
    Сборка=врап.загрузитьСборку(ИмяФайлаСборки); //ПроектИспользованияДелегатов.dll
    тип=Сборка.GetType("ПроектИспользованияДелегатов.КлассДляВнешнихСобытий");
    
    ОбъектССобытием=врап.СоздатьОбъект(Тип,КаталогДляОтслеживанияИзменений);
    Событие=Врап.ПолучитьОбъектДляСобытий(ОбъектССобытием,"Событие");
    СобытиеПереименования=Врап.ПолучитьОбъектДляСобытий(ОбъектССобытием,"СобытиеПереименованияФайла");
    
    ДобавитьОбработчик Событие.Событие, ПриИзмененииДиректории;
    ДобавитьОбработчик СобытиеПереименования.Событие, ПриПереименованииФайла;
[/code]

Сам класс такой.

[cs]
    public class КлассДляВнешнихСобытий
    {
        public string ИзмененныйФайл;
        public string ПереименованныйФайл;
        public event System.Action Событие;
        public event System.Action СобытиеПереименованияФайла;
        FileSystemWatcher watcher;

        private  void ИзмененияВДиректории(object source, FileSystemEventArgs e)
        {
            // Specify what is done when a file is changed, created, or deleted.
            ИзмененныйФайл = e.FullPath + " " + e.ChangeType;
            if (this.Событие != null) Событие();
     
        }

        public КлассДляВнешнихСобытий(string Директория)
        {
            watcher = new FileSystemWatcher();
            watcher.Path = Директория;
            /* Watch for changes in LastAccess and LastWrite times, and
               the renaming of files or directories. */
            watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite
               | NotifyFilters.FileName | NotifyFilters.DirectoryName;
            // Only watch text files.
            watcher.Filter = "*.*";

            // Add event handlers.
            watcher.Changed += new FileSystemEventHandler(ИзмененияВДиректории);
            watcher.Created += new FileSystemEventHandler(ИзмененияВДиректории);
            watcher.Deleted += new FileSystemEventHandler(ИзмененияВДиректории);
            watcher.Renamed += new RenamedEventHandler(OnRenamed);

            // Begin watching.
            watcher.IncludeSubdirectories = true;

            watcher.EnableRaisingEvents = true;


        
        }
и солнце б утром не вставало, когда бы не было меня
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 13:14
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>Но каких либо особенных сложностей нет.

EP>Привыкли есть кактус
Ещё неизвестно какой кактус более колючий — с явным управлением памятью в каждой строчке кода или byte[]-структуры в 1% кода.

dot>>Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы.

EP>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.
EP>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
"new int[1<<30]" тоже за одну. Но, если у тебя такие массивы будут выделяться|освобождаться каждую секунду... в общем плохо будет.

EP>Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.

Вот и считай, вместо кода специального аллокатора ты просто пишешь сразу GC-free код. Без лишних уровней абстракции.

dot>>Там где offheap или нарезание на массивы — будут structure-of-arrays.

EP>Сам же понимаешь что это передёргивание.
EP>Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры.
EP>Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде.
EP>Причём SoA требуются на порядки реже чем обычные структуры.
Да и оптимизация обычных структрур требуется на порядки реже.

EP>>>Не прикалываюсь

dot>>И как оказалось по факту есть только boehm
EP>Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет
Для DOM/js афаир, но не для всего кода. Т.е. создать собираемую песочницу можно, но не "пишем на С++ с мусоросборщиком".

EP>>>Например Boehm GC есть очень давно, и используется в реальных проектах

dot>>Он используется в особенного типа проектов — gcj, mono, lisp и т.п. Прикладной код, а уж тем более LL — что-то очень сомневаюсь.
EP>Например Inkscape — вполне прикладной код
EP>http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Boehm-GC
Интересно для чего он там используется. Как я понимаю это, там gc не для всего кода используется... опять поди какой-нибудь скриптинг?

EP>>>>>Из этого видео никак не следует что "большинство выкрутасов это не извращения java".

dot>>>>Это те проблемы, которые сейчас решают в LMAX, хотя всё ещё пишут всё на "извратной java".
EP>>>От того что он сорок минут рассказывал про affinity, проблемы с извращениями на Java никуда не делись, он их даже явно упомянул.
dot>>Да сколько раз повторять. Нет проблем никаких.
EP>То есть ты извращения с off-heap за проблемы не считаешь? Ну ок
Не считаю. Ибо в реальной системе количество off-heap кода составляет 0.2% (специально сейчас посчитал). Ладно, накинь порядок, на тот случай если я посчитал как-то неправильно. Пусть 2%.
Этот код пишется один раз, покрывается тестами и забывается.

EP>>>>>И уровень кода ниже чем C, и больше его во много раз.

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

dot>>Без них всё работает замечательно, зачем лишняя сущность?

EP>Несерьёзно, это уже blub-аргументация.
Нет, это KISS.

dot>>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода.

EP>Действительно, подумаешь код не работает.
EP>Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?
Тестами, без всяких valgrind.

dot>>В-третьих, этот кусок кода довольно примитивный, при желании можно даже формально доказать отсутствие расстрелов.

EP>Да не то что доказать, тут подобный кусок без ошибки написать не смогли
Автор: Evgeny.Panasyuk
Дата: 08.10.15
.

Бывает. Тестов у них не было.

dot>>В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами.

EP>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.

dot>>В-пятых, обычно это красиво оборачивается, например, в Disruptor, за много лет отлаженная библиотека.

EP>Со своими структурами что делать?
"свои" структуры наверняка в LL не заработают. Нужно очень хорошо продумывать структуры с оглядкой на LL.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 12.10.15 13:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Все эти вещи когда то писали на Си/С++. Питон, перл, пхп — все это выстрелило уже после того, как С++ оттуда ушел.

I>·>Что-то сомневаюсь. C ещё может быть, С++ — очень вряд ли. Но С просто старше. А уж LAMP всегда был классикой. Веб на С — это либо экзотика, либо старьё.
I>Смешно. "всегда" началось совсем недавно, от силы 10 лет назад.
10 лет уже было в самом разгаре. Собственно совпало с бумом Web. А до этого помню каждый второй изобретал шаблонный движок, очередное PHP-подобие... JSP, ASP, CFML и прочий треш. Но С массово никогда в вебе не было.

I>>>·>Наравне с Java.

I>>>Джава в роли догоняющего.
I>·>Примерно как С++ догоняет Кобол.
I>Кобол в HFT ? Пудозреваю, исключительно за счет С++.
В finance.

I>>>·>Да какая архитектура блин. Вместо "MyObj obj = new MyObj()" пишешь "MyObj obj = newMyObj()", в общем-то и вся разница по факту.

I>>>По факту запрещено многие вещи вызывать именно из за этого ограничения.
I>·>Что запрещено? Не понял мысль.
I>Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`.
I>Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд.
Ага... А если ты заюзаешь чужую либу, а она там malloc делает и все кастомные аллокаторы фтопку.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[112]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 13:26
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>>>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>>>>>>C# точно ничем не хуже.
EP>>>>>C# менее гибкий для обобщённого кода. Например
EP>>>>>Python:
EP>>>>>C++:
EP>>>>>C#?
S>>>>https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx
EP>>>И как это относится к примеру?
S>> https://msdn.microsoft.com/ru-ru/library/s53ehcz3.aspx
S>>Я могу через рефлекшн вызвать соответствующие методы.
S>>https://msdn.microsoft.com/ru-RU/library/system.datetime.op_addition(v=vs.71).aspx

EP>Да причём тут это? Пример про простую функцию высшего порядка apply — на Python и C++ она элементарно реализуется. Покажи аналог на C#.


Вариантов куча. Можно через рефлексию зная, что для типа существуют импликиты.

S>>>>Ну и джененрики интефейсы

EP>>>Покажи код.
S>> Нет времени.

EP>Необязательно прям сейчас.

Самое простое это
interface IEquatable<T>
{
    T Add(T obj,T obj1);
    T Add(T obj,T obj1);
 итд
}

И не забываем про T4.
S>>>> Вот а в C# практически все в одном.
EP>>>Язык менее гибкий чем Python. А плюсы-то какие?
S>> Это с чего это менее гибкий?

EP>Покажи пример с apply — на нём видно как раз.


S>>То есть ты плюсов не видишь? Я потратил кучу времени, а ты даже плюсов не нашел. Смысл в разговоре?


EP>Какие плюсы у C# перед Python примирительно к скриптам?

На C# можно писать в стиле скриптов через динамики, компилировать динамические сборки.
Напиши динамическую обертку IDispatch над любым объектом С++
и солнце б утром не вставало, когда бы не было меня
Отредактировано 12.10.2015 13:27 Serginio1 . Предыдущая версия .
Re[93]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 14:07
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Вообще то мы сравнивали сложность написания C# и C++ кода, который потом будут вызывать из 1C. Так вот в этом разницы не видно. Если же ты хочешь поговорить о возможности запуска из 1C некого чужого, скомпилированного в бинарник кода, то это уже совсем другой вопрос для другой дискуссии.

S> Да написания C# кода вообще не существует. Используются любые нетовские классы.
S>Так запускается то скомпилированный код сборки. Ну читайте внимательно о чем речь. Вы же С++ ники белая кость.

Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там.

P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает.
Re[37]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 14:16
Оценка:
Здравствуйте, ·, Вы писали:

·>QtCreator проще тем, что это только С++ и больше ничего. Другие IDE — это целая платформа с кучей расширений и плагинов.


Я в курсе. Но я же сравниваю их в контексте использования именно для C++, так что всё честно. Ну и в QtCreator тоже есть плагины) Да и если говорить про подсветку синтаксиса, то там естественно тоже есть все возможные (собственно загружаются из инета по требованию). А вот другие возможности IDE там действительно только для C++.
Re[39]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 14:27
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.

_>>Ну так у меня же мало практики в написание заведомо некорректного кода. Я вообще сам delete раз год вижу, даже с корректным кодом. А тут такое... )))
·>Ты написал его типично. Чаще так оно и происходит. Время жизни в одном месте, удаление в другом месте, добавленное в другое время, другим девом в другом потоке.

Это типично для C. На C++ такой код вообще не встречается. Просто на нормальном для C++ коде было бы невозможно продемонстрировать описываемый тобой баг (в отличие от Жабки, где это без проблем):
{
    auto x=make_unique<T>();
    //...
} //в этой точке вызывается delete (сам!)
// а здесь уже не добраться до указателя, чтобы продемонстрировать обсуждаемое поведение


_>>·>И ты правда не видел битых указателях в реальных проектах? Укажи, плиз, номер твоей планеты в тентуре.

_>>В своих, ушедших в продакшен, — не видел. )
·>А сколько девов принимало участие? Сколько человеколет? Если меньше 5 девов, менее сотни человеколет, то это мелкие проекты... Их хоть на ассемблере пиши, не принципиально.

От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
Re[92]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 14:37
Оценка:
Здравствуйте, -MyXa-, Вы писали:



MX>Не понял, для каких простых случаев, какими ручками? Ты же оборачиваешь произвольную .NET сборку в COM.

Попробую как я наконец то динамическую компиляцию. Например
http://rsdn.ru/forum/src/3165397
Автор: Воронков Василий
Дата: 06.11.08

или
http://rsdn.ru/forum/dotnet/5011144.all
Автор:
Дата: 26.12.12

или
http://stackoverflow.com/questions/30053490/codedom-compilation-fails
http://habrahabr.ru/post/67431/
и солнце б утром не вставало, когда бы не было меня
Отредактировано 12.10.2015 18:17 Serginio1 . Предыдущая версия . Еще …
Отредактировано 12.10.2015 15:58 Serginio1 . Предыдущая версия .
Отредактировано 12.10.2015 15:17 Serginio1 . Предыдущая версия .
Re[37]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 14:52
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>В дефолтном случае и GC замечательно работает. А вот эти обсуждаемые извращения в Яве это и есть те самые редкие случаи.

_>>Нет, это как раз совсем разные случаи. Единственный сценарий, на котором GC начинает конкурировать с обычной работой с памятью в C++ — это режим создания/удаления множества мелких объектов в куче. Так вот этот режим в C++ встречается на очень редком классе задач (и для них уже есть смысл рассматривать спец. аллокаторы и т.п.). И задачи типа реалтайма или высокой нагрузки точно не относятся к этому исключению — там как раз эффективны стандартные техники C++.
·>Говорю же — два режима оптимальны. Второй режим — объекты создаются и уничтожаются редко. Редко меняется граф объектов в памяти. (т.е. топология графа не меняется, но данные внутри объектов меняться могут).
·>Неоптимальный режим — создали кучу объектов, помариновали их какое-то время и потом грохаем.

"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.

Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).

_>>В то же время в Java режим создания/удаления множества мелких объектов в куче — это норма. И хотя GC не так плохо справляется тут, но он намного отстаёт от C++ на большинстве задач, т.к. в C++ в этих случаях используется другой режим (который априори быстрее). И только в том случае, когда и в C++ необходимо плодить сущности типа shared_ptr, быстродействие может сравниться (при условие, что в C++ не будем вводить кастомные извращения).

_>>Соответственно, чтобы догнать C++ на задачах реалтайма, высокой нагрузки и т.п. (в остальных областях тоже медленно, но всем просто пофиг) в Java переходят от дефолтного режима на некое извращение с рукопашными буферами и т.п. ужасами для эмуляции стандартных техник C++.
·>Собственно и в плюсах ты переходишь от комфортного by-value/on stack к хитрым аллокаторам, жонглированию различными типами указателей, повышая риск что-то поломать или потерять.

Ещё раз повторяю: на C++ я перехожу к такому режиму только на очень узком спектре задач, требующих постоянное создания/удаления мелких объектов. Обычно такое наблюдается при написание каких-нибудь компиляторов, интерпретаторов и т.п. На большинстве задач такого нет даже близко. И уж тем более не в области LL, где все выделения памяти рекомендуется сделать вне главного цикла.

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

·>Собственно в LL-системе "плохая" часть очень маленькая. Только из малой области кода выжимаются все соки, а остальное пишется как обычно, с комфортом GC.

Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))

_>>·>Собственно та же ситуация и с GC.

_>>Абсолютно не такая же. Напомню, что мы здесь обсуждали возможности JIT выбрать расположение и типы данных (куча/стек, ссылка/значение и т.д.) наиболее оптимальным способом. И в отличие от качества генерирования ассемблерного кода оптимизаторами C++, тут ситуация даже не приблизилась к идеалу. И я сомневаюсь что приблизится когда-нибудь, т.к. тут задача намного сложнее.
·>Принципиально — для JIT оптимизаций доступно гораздо больше информации, т.к. оно работает во время испонения. И оптимизация происходит именно в соответствии с реальной нагрузкой. Есть, конечно Profile Guided Optimisation, но она, насколько я знаю, представляет в основном академиеческий интерес.

Я говорю не про теорию, а про практику. В теории компиляторы могли создавать отличный ассемблерный код и 30 лет назад — ничего этому не мешало. Однако на практике они достигли уровня, сравнимого с человеком, только лет 5-10 назад. Так вот в области автоматической оптимизации типов и т.п. на практике нет пока почти ничего реально работающего. Может лет 10-20 и появится что-то существенное, но пока такого нет.
Re[94]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 14:52
Оценка:
Здравствуйте, alex_public, Вы писали:



_>Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там.


_>P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает.

Я тебе некажется, что это далеко не то. Прочитай повнимательнее http://infostart.ru/public/238584/
Опя ть путаешь ОПП с процедурным программированием. Это даже сравнивать нельзя.
Ну дык сделайте, раз все так просто.
Я на это http://rsdn.ru/forum/dotnet/4296659.1
Автор: Serginio1
Дата: 02.06.11
потратил всего 15 минут.
Уверяю 1С ники будут вам благодарны.
Сделайте аналогичные примеры с вэб сервисам, а то народ мучается http://1c.mista.ru/topic.php?id=755069 с PHP шными массивами.
и солнце б утром не вставало, когда бы не было меня
Re[40]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.10.15 14:59
Оценка:
Здравствуйте, alex_public, Вы писали:

_>
_>{
_>    auto x=make_unique<T>();
_>    //...
_>} //в этой точке вызывается delete (сам!)
_>// а здесь уже не добраться до указателя, чтобы продемонстрировать обсуждаемое поведение
_>


_>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.


Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.
Или передаем голые указатели и C++ превращается в C_с_классами.

Кстати проблема вовсе не в delete, а в том, что указатель может быть сохранен в поле класса или статической переменной и произойдёт обращение к освобожденной памяти.
Re[35]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 15:43
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>А тебе вообще доводилось писать LL код?

_>>Я же тебе уже даже примеры приводил. ) И да, оно не из области финансов. )))
·>В смысле видео|игры?

Видео) Но не только) Бывают ещё всяческие управляющие сигналы, которые должны передаваться без задержек и т.п. Кстати, мне тут подумалось, что во всяких онлайн-играх тоже всё очень похоже. Но с играми я никогда дел не имел (как создатель ).

_>>Да, написание приложения на C++ со встроенным скриптовым языком — это стандартная техника написания сложных и эффективных приложений. Это не только браузеры, но и тяжёлые игры и всякий профессиональный софт (CAD'ы, редакторы/рендереры и т.п.)и ещё много где. Проще вспомнить где такого нет. ))) Кстати, мы такое тоже используем.

·>Вот и считай... что java это такой встроенный скриптовый язык для решения прикладных задач — обработать 20000 заявок в секунду. И нет такой прикладной задачи "разместить структуру данных в памяти последовательно с минимумом индирекций".

На скриптовой язык Java не тянет по удобству. )

_>>Да, и браузер — это совсем не системный софт (с каких это пор взаимодействие с ОС стало признаком системного софта?), т.к. работает на обычном пользовательском уровне. Системный софт — это всяческие драйверы, сервисы и т.п. )

·>Браузер не решает _прикладные_ задачи (т.е. задача непосредственно решаемая конечным пользователем). Прикладная задача — читать емейл, инвестировать деньги, купить беззеркалку, поставить лайк. А рендер html/css, выполнение js — это не прикладные задачи. И, что характерно, всякие прикладные вещи в браузере типа управление списком скачанных файлов, диалоги настроек и т.п — пишется на js/xul.

О, тогда и все современные 3D игры являются системным софтом? ))) Потому как в них тоже полно взаимодействия с ОС и всю логику задаёт некий скрипт...

_>>·>Кеш в районе всего лишь нескольких мегабайт — копейки же, миллиончик элементов — и упс, кончилось.

_>>Хыхы, в данном случае важнее размер не всего кэша, а именно его линий (в соотношение с размером самого объекта). А так же очевидная для предсказателя последовательность выборки.
·>Линия вроде вообще 64 байта или что-то типа того. Или я с чем-то путаю?

Да, всё верно. )
Re[95]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 15:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там.

_>>P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает.
S> Я тебе некажется, что это далеко не то. Прочитай повнимательнее http://infostart.ru/public/238584/

Что не то? ) Это вызов в 1C произвольной функции из произвольной нативной DLL. Ты кажется этого хотел или нет? )

S>Опя ть путаешь ОПП с процедурным программированием. Это даже сравнивать нельзя.

S> Ну дык сделайте, раз все так просто.
S>Я на это http://rsdn.ru/forum/dotnet/4296659.1
Автор: Serginio1
Дата: 02.06.11
потратил всего 15 минут.

S>Уверяю 1С ники будут вам благодарны.

Что сделать то? ) Напиши чётко и ясно. Работа с произвольным C++ классом (данным нам в исходниках) показана. Работа с произвольной dll тоже. Чего ещё не хватает? )

S>Сделайте аналогичные примеры с вэб сервисам, а то народ мучается http://1c.mista.ru/topic.php?id=755069 с PHP шными массивами.


Эээ что? )))
Re[41]: Java vs C# vs C++
От: alex_public  
Дата: 12.10.15 16:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.

G>Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.

Это с каких это пор нельзя передавать параметром? ) shared_ptr — это для очень специфического кода.

G>Или передаем голые указатели и C++ превращается в C_с_классами.


Ты путаешь. Голые указатели — это как раз нормально (а как ты без них скажем с win api поработаешь?). Не нормально это ручное удаление памяти и т.п.

G>Кстати проблема вовсе не в delete, а в том, что указатель может быть сохранен в поле класса или статической переменной и произойдёт обращение к освобожденной памяти.


Ну т.е. проблема в том, что delete вызван раньше, чем положено. Опять же проблема кривой архитектуры.
Re[96]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 18:16
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ещё раз повторяю: если ты хочешь обсудить идею возможности вызова в 1C произвольных функций из произвольной dll, то это тоже можно, но это не будет иметь никакого отношения к нашей дискуссии C# vs C++. Во-первых потому что такую dll можно написать вообще на любом языке. А во-вторых потому что данные вопросы связаны уже с возможностями самого 1C, а не внешних инструментов. В большинстве известных мне скриптовых языков имеется встроенная возможность для данной задачи. С 1C я не знаком, но не удивлюсь если это реализовано и там.

_>>>P.S. Ради развлечения сделал поиск в гугле и первой же строкой увидел это http://infostart.ru/public/18636/. Ну да, конечно очень криво (зачем-то через COM, никакого сравнения с удобными решениями типа такого https://docs.python.org/2/library/ctypes.html), но всё же работает.
S>> Я тебе некажется, что это далеко не то. Прочитай повнимательнее http://infostart.ru/public/238584/

_>Что не то? ) Это вызов в 1C произвольной функции из произвольной нативной DLL. Ты кажется этого хотел или нет? )

Разницу не чувствуешь, статический метод и метод класса. Сделай примеры из статьи. И посмотрим. В чем проблема?

S>>Опя ть путаешь ОПП с процедурным программированием. Это даже сравнивать нельзя.

S>> Ну дык сделайте, раз все так просто.
S>>Я на это http://rsdn.ru/forum/dotnet/4296659.1
Автор: Serginio1
Дата: 02.06.11
потратил всего 15 минут.

S>>Уверяю 1С ники будут вам благодарны.

_>Что сделать то? ) Напиши чётко и ясно. Работа с произвольным C++ классом (данным нам в исходниках) показана. Работа с произвольной dll тоже. Чего ещё не хватает? )


В статье есть куча примеров.
S>>Сделайте аналогичные примеры с вэб сервисам, а то народ мучается http://1c.mista.ru/topic.php?id=755069 с PHP шными массивами.

_>Эээ что? )))

Ну опять же в статье есть пример использования Вэб сервисов. Правда нужно сгенерить сборку в VS и её использовать.
Вот выдержка из статьи использования

Процедура ВызовСервисаИспользуяConfigFileНажатие(Элемент)    
 // Вставить содержимое обработчика.        
 врап=новый COMОбъект("NetObjectToIDispatch45");
    //Сборка=врап.загрузитьСборку("d:\MyPrograms\Test\NestNet45\NestNet45\bin\Debug\NestNet45.dll");     
Сборка=врап.загрузитьСборку(ИмяФайлаСборки);    
 TChannel=Сборка.GetType("NestNet45.ServiceReference1.MorpherSoap");
 ConfigFile=ИмяФайлаСборки+".config"; 
 endpointConfigurationName="MorpherSoap";    
 endpointAddress=Неопределено;     
Клиент=врап.СоздатьКлиентаWCFConfigFile(ConfigFile,TChannel,endpointConfigurationName,endpointAddress);
     // Вызываю метод и вывожу результат    
 рез = Клиент.GetForms("Вася Пупкин");
    Для каждого стр  Из рез Цикл
         сообщить(стр)    
    КонецЦикла;
 КонецПроцедуры



Легко используются доступ к Вэб сервисам из сборки.
Все очень красиво


Сборка представляет собой описание клиента.
Вот исходник

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:4.0.30319.17929
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

namespace NestNet45.ServiceReference1 {
    
    
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
    [System.ServiceModel.ServiceContractAttribute(Namespace="http://morpher.ru/webservices/", ConfigurationName="ServiceReference1.MorpherSoap")]
    public interface MorpherSoap {
        
        [System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/PropisRUB", ReplyAction="*")]
        [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
        string PropisRUB(decimal summa);
        
        [System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/PropisRUB", ReplyAction="*")]
        System.Threading.Tasks.Task<string> PropisRUBAsync(decimal summa);
        
        [System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/GetForms", ReplyAction="*")]
        [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
        string[] GetForms(string s);
        
        [System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/GetForms", ReplyAction="*")]
        System.Threading.Tasks.Task<string[]> GetFormsAsync(string s);
        
        [System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/Soglasovat", ReplyAction="*")]
        [System.ServiceModel.XmlSerializerFormatAttribute(SupportFaults=true)]
        string Soglasovat(uint n, string s);
        
        [System.ServiceModel.OperationContractAttribute(Action="http://morpher.ru/webservices/Soglasovat", ReplyAction="*")]
        System.Threading.Tasks.Task<string> SoglasovatAsync(uint n, string s);
    }
    
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
    public interface MorpherSoapChannel : NestNet45.ServiceReference1.MorpherSoap, System.ServiceModel.IClientChannel {
    }
    
    [System.Diagnostics.DebuggerStepThroughAttribute()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
    public partial class MorpherSoapClient : System.ServiceModel.ClientBase<NestNet45.ServiceReference1.MorpherSoap>, NestNet45.ServiceReference1.MorpherSoap {
        
        public MorpherSoapClient() {
        }
        
        public MorpherSoapClient(string endpointConfigurationName) : 
                base(endpointConfigurationName) {
        }
        
        public MorpherSoapClient(string endpointConfigurationName, string remoteAddress) : 
                base(endpointConfigurationName, remoteAddress) {
        }
        
        public MorpherSoapClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) : 
                base(endpointConfigurationName, remoteAddress) {
        }
        
        public MorpherSoapClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) : 
                base(binding, remoteAddress) {
        }
        
        public string PropisRUB(decimal summa) {
            return base.Channel.PropisRUB(summa);
        }
        
        public System.Threading.Tasks.Task<string> PropisRUBAsync(decimal summa) {
            return base.Channel.PropisRUBAsync(summa);
        }
        
        public string[] GetForms(string s) {
            return base.Channel.GetForms(s);
        }
        
        public System.Threading.Tasks.Task<string[]> GetFormsAsync(string s) {
            return base.Channel.GetFormsAsync(s);
        }
        
        public string Soglasovat(uint n, string s) {
            return base.Channel.Soglasovat(n, s);
        }
        
        public System.Threading.Tasks.Task<string> SoglasovatAsync(uint n, string s) {
            return base.Channel.SoglasovatAsync(n, s);
        }
    }
}
и солнце б утром не вставало, когда бы не было меня
Re[37]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.10.15 18:29
Оценка:
Здравствуйте, ·, Вы писали:

I>>>>·>Наравне с Java.

I>>>>Джава в роли догоняющего.
I>>·>Примерно как С++ догоняет Кобол.
I>>Кобол в HFT ? Пудозреваю, исключительно за счет С++.
·>В finance.

HFT это уже не финансы ?

I>>Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`.

I>>Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд.
·>Ага... А если ты заюзаешь чужую либу, а она там malloc делает и все кастомные аллокаторы фтопку.

В С++ аллокация кастомизируется
1 Многие либы поддерживают аллокаторы
2 можно дефолтный аллокатор соптимизировать под нужные сценарии

Это конечно трудная техника, но возможная. Что взамен в джаве, кастомный GC ?
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 18:35
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Анализатору же придётся это доказывать проинлайнив весь код.

dot>>>Да пусть доказывает, он железный, зарплату не просит.
EP>>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей.
dot>Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.

На C++ зачем это доказывать? Мы же про EA говорим.

dot>>>При сборке Eden Space оно и грохнется,

EP>>Оно бы грохнулось в тот же самый момент и без EA.
dot>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.

Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.

dot>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.


Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.

dot>Разница может быть заметна, если у тебя этот vector возвращается по значению из функции и его размер большой, что передачу by-value сделает неэффективой. А значит ты должен будешь его в unique_ptr обернуть или надеяться на RVO.


Сейчас есть гарантия: в худшем случае что случится в описанном варианте это move, то есть никакой unique_ptr тут не нужен, также как и во многих других случаях.
Да и RVO/NRVO прекрасно работает даже на старых MSVC.

dot>>>А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.

EP>>У него тоже ничего не поломается. Даже если бы это был просто vector<T>, без unique_ptr — то тоже ничего бы не поломалось
dot>Это если голые указатели не использовать.

Так я же говорю, их можно использовать когда нет владения. При передачи владения нужно это кодировать в типах.

dot>>>>>Указатель ещё тип имеет. Ссылка в яве тоже адрес хранит и чё.

EP>>>>Конечно, и в типе разница — на C++ можно иметь указатель на элемент массива, на Java — нет.
dot>>>Ты так говоришь, как будто это что-то плохое.
EP>>Это очевидный недостаток. Например есть текст, нужно передать куда-то отдельный абзац — на C++ достаточно например либо двух указателей, либо указателя и числа символов, либо просто указателя на начало абзаца. На Java же придётся ещё таскать ссылку на сам текст.
dot>В общем да, есть такое. Хотя далеко не факт, что это может стать какой-либо проблемой... В типичном приложении у тебя скорее всего будет ссылка на какой-нибудь Document, по которому можно найти его текст. Поэтому будет достаточно пары индексов. А в большинстве случаев помещение двух или трёх чисел на стек — погоды не делает.

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

dot>>>>>Да, неудачный пример. Лучше рассмотреть hashtable. Сложность O(n). и что? Просто крутят использование до тех пор пока не станет почти O(1). Примерно так и с GC.

EP>>>>Штуки типа cuckoo hashing не на ровном месте появились.
dot>>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).
EP>>Меняет — поиск и удаление константы в худшем случае.
dot>А добавление?

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

dot>>>>>Не смертельно.

EP>>>>Отдельный код для каждой комбинации. Конечно не смертельно, можно и на ASM'е писать рабочий код.
dot>>>Комбинации чего?
EP>>Структура данных * контейнер * алгоритм * etc. ЕМНИП даже в C# для разных структур generic даёт разные воплощения.
dot>Круто, конечно. Но в горячем коде таких комбинаций обычно единицы. А остальному коду это всё не важно.

У меня как раз в "горячем" коде их очень много.

dot>>>Сколько их? (только практику плз, а не теоретические рассуждения)

EP>>Очень много, это практика, реальный код.
EP>>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.
dot>Не факт, что это принесёт хоть какую-то пользу. compile time же.

В смысле?

dot>>>>>Это какие-то очень экзотические условия, у меня не получается представить когда в ссылочном дереве лишняя индирекция может стать серьёзной проблемой.

EP>>>>А например в хэш-таблице?
dot>>>Если значение большое, то индирекция нужна, иначе сам массив хеш-таблицы будет слишком большим и не помещаться в кеш.
EP>>1. Если малое — то уж точно не нужна, тут разногласия нет.
EP>>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме
EP>>3. Ключ может хранится отдельно от значения, причём без индерекции.
dot>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.

Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.

dot>>>Если значение маленькое, то это скорее всего будет примитив.

EP>>С чего бы это?
dot>Потому что примитив это те же 8 байт, что уже не так уж мало.

На C++ там где удобно без проблем оборачиваю даже одно значение примитивного типа в класс

dot>>>Собственно это соответствует сложному жонглированию владением в C++,

EP>>Не сложному, и не соответствует. Большинство случаев владения (и "жонглирования" им) C++ это простейший by-value.
dot>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.

by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.

EP>>>>Конечно будет, и это одна из причин почему положит на лопатки.EP>>>Именно так и происходит
Автор: Evgeny.Panasyuk
Дата: 06.06.15
в Emscripten, который компилирует C++ в JS.

EP>>>>И JS кстати получается реально быстрый. На одном из тестов работает практически в два раза быстрее чем аналогичный код на C#. JS, в веб-браузере, Карл! И этом при том что в C# версии были структуры. Если же брать аналогичный код на Java — то всё будет ещё круче Можем кстати сравнить.
dot>>>Ну и кому эти микробенчмарки нужны?
EP>>Тем кого интересует скорость
dot>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.

Так говоришь как будто быстрое означает не полезное.

dot>>>Ты давай пример системы на плюсах, компилированных под jvm.

EP>>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.
dot>Потому и не знаешь, что принципиально невозможно.

Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.

dot>>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.

EP>>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.
dot>Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.

1. В том тесте вообще GC остался за бортом, его действия не замеряли. Замеряли только обход массива с простой операцией.
2. Причём тут вообще JS GC? В случае C++ -> JS — там практически все данные находятся в одном большом буфере.
Re[26]: Java vs C# vs C++
От: Somescout  
Дата: 12.10.15 18:51
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>foreach из примера что-ли? До вот этой красоты всё равно не дотягивает:

EP>
EP>valarray<complex<double>> x(2.5 + 10i, n), y(1.2 - 20i, n);
EP>x *= y;
EP>


А в чём красота, что нашли (наконец) куда засунуть пользовательские суффиксы? Кто-то после этого попрекает C# синтаксическим сахаром.
ARI ARI ARI... Arrivederci!
Re[35]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 18:54
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>Там где gc-free — в плюсах будут alloc-free или хитровывернутые аллокаторы.

EP>>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.
EP>>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
dot>"new int[1<<30]" тоже за одну.

Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.

EP>>Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.

dot>Вот и считай, вместо кода специального аллокатора ты просто пишешь сразу GC-free код. Без лишних уровней абстракции.

Ещё раз — в одном случае отличие от дефолта это несколько параметров, в другом изменение всего кода. Разница кардинальная.
Поэтому аргументы типа "ну и что что весь код GC-free, зато у вас несколько параметров меняются" — несостоятельны.

dot>>>Там где offheap или нарезание на массивы — будут structure-of-arrays.

EP>>Сам же понимаешь что это передёргивание.
EP>>Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры.
EP>>Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде.
EP>>Причём SoA требуются на порядки реже чем обычные структуры.
dot>Да и оптимизация обычных структрур требуется на порядки реже.

Реже чем что? Чем смирение с тормозами, повышенным энергопотреблением и т.п.?

EP>>>>Не прикалываюсь

dot>>>И как оказалось по факту есть только boehm
EP>>Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет
dot>Для DOM/js афаир, но не для всего кода. Т.е. создать собираемую песочницу можно, но не "пишем на С++ с мусоросборщиком".

Там это используется для interop JS (DOM?) <-> C++ — то есть не просто внутри JS.

dot>>>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода.

EP>>Действительно, подумаешь код не работает.
EP>>Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?
dot>Тестами, без всяких valgrind.

Так в C++ будут и тесты и valgrind/etc. Об этом и речь, готовых инструментов на Java видимо нет, значит трата ещё дополнительных ресурсов.

dot>>>В-четвёртых, этот кусок кода (раз уж его так заоптимизировать пришлось) очень горячий, соответственно практически все баги выцепляются ещё юнит-тестами.

EP>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
dot>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.

Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
Re[113]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 19:27
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>>>>>>> Кстати а чем С++ хуже питона, раз питон используется с С++?

S>>>>>>>>>C# точно ничем не хуже.
EP>>>>>>C# менее гибкий для обобщённого кода. Например
EP>>>>>>Python:
EP>>>>>>C++:
EP>>>>>>C#?
S>>>>>https://msdn.microsoft.com/ru-ru/library/39bb81c3.aspx
EP>>>>И как это относится к примеру?
S>>> https://msdn.microsoft.com/ru-ru/library/s53ehcz3.aspx
S>>>Я могу через рефлекшн вызвать соответствующие методы.
S>>>https://msdn.microsoft.com/ru-RU/library/system.datetime.op_addition(v=vs.71).aspx
EP>>Да причём тут это? Пример про простую функцию высшего порядка apply — на Python и C++ она элементарно реализуется. Покажи аналог на C#.
S>Вариантов куча. Можно через рефлексию зная, что для типа существуют импликиты.

Так покажи — на Python и C++ это несколько простых строчек.

S>>>>>Ну и джененрики интефейсы

EP>>>>Покажи код.
S>>> Нет времени.
EP>>Необязательно прям сейчас.
S> Самое простое это
S>
S>interface IEquatable<T>
S>{
S>    T Add(T obj,T obj1);
S>    T Add(T obj,T obj1);
S> итд
S>}
S>


Да причём тут Add? Тут основная фишка в apply.

S> И не забываем про T4.


То есть там где на Python и C++ пара строчек, ты предлагаешь использовать кодогенерацию T4, и причём это в контексте скриптов? Мощно

EP>>Какие плюсы у C# перед Python примирительно к скриптам?

S> На C# можно писать в стиле скриптов через динамики, компилировать динамические сборки.

Напиши apply, посмотрим на это "в стиле скриптов".

S>Напиши динамическую обертку IDispatch над любым объектом С++


Я же сказал, для этого проще всего взять интерпретатор Cling — сможешь обращаться к любому объекту.
А вообще непонятно к чему это, вопрос-то был какие плюсы у C# перед Python в отношении скриптов
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 19:39
Оценка:
Здравствуйте, Somescout, Вы писали:

EP>>foreach из примера что-ли? До вот этой красоты всё равно не дотягивает:

EP>>
EP>>valarray<complex<double>> x(2.5 + 10i, n), y(1.2 - 20i, n);
EP>>x *= y;
EP>>

S>А в чём красота, что нашли (наконец) куда засунуть пользовательские суффиксы?

Почему "наконец"? Их вводили вполне под конкретные нужды.
А вообще там оппонент непонятно зачем начал показывать готовый Complex в C#, хотя пример был совершенно не про это. В ответ я и показал что есть из коробки в C++

S>Кто-то после этого попрекает C# синтаксическим сахаром.


Кто? Я как раз говорю что язык в том числе и не гибкий.
Re[114]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.10.15 19:46
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>То есть там где на Python и C++ пара строчек, ты предлагаешь использовать кодогенерацию T4, и причём это в контексте скриптов? Мощно

А макросы это что?
EP>>>Какие плюсы у C# перед Python примирительно к скриптам?
S>> На C# можно писать в стиле скриптов через динамики, компилировать динамические сборки.

EP>Напиши apply, посмотрим на это "в стиле скриптов".

А что писать? Я уже давал ссылки на динамическую компиляцию в реал тайме.
Покажи, задачу. Если на C# не получится можно использовать сборки на айрон питоне, немерле.

S>>Напиши динамическую обертку IDispatch над любым объектом С++


EP>Я же сказал, для этого проще всего взять интерпретатор Cling — сможешь обращаться к любому объекту.

EP>А вообще непонятно к чему это, вопрос-то был какие плюсы у C# перед Python в отношении скриптов
Так сделай. Я потратил 15 минут. Сколько уйдет у тебя?
Ну дык сделай на питоне эту задачу. Все ведь элементарно.
Больше времени на этом сайте тратишь. 1С ники будут благодарны расширению их функционала за счет С++ библиотек.
Так смотришь и перейдут на С++.
и солнце б утром не вставало, когда бы не было меня
Re[42]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.10.15 20:02
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.

G>>Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.

_>Это с каких это пор нельзя передавать параметром? ) shared_ptr — это для очень специфического кода.

Вот так и нельзя, конструктора копирования нет.



G>>Или передаем голые указатели и C++ превращается в C_с_классами.

_>Ты путаешь. Голые указатели — это как раз нормально (а как ты без них скажем с win api поработаешь?). Не нормально это ручное удаление памяти и т.п.
WinAPI это C, а не C++

G>>Кстати проблема вовсе не в delete, а в том, что указатель может быть сохранен в поле класса или статической переменной и произойдёт обращение к освобожденной памяти.

_>Ну т.е. проблема в том, что delete вызван раньше, чем положено. Опять же проблема кривой архитектуры.
Почему подобная кривая архитектура невозможна в C# или Java? Видимо проблема языка.
Re[115]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 21:26
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>То есть там где на Python и C++ пара строчек, ты предлагаешь использовать кодогенерацию T4, и причём это в контексте скриптов? Мощно

S> А макросы это что?

В этом примере никаких макросов. Да даже если говорить о них — они-то встроены непосредственно в язык, а не являются чем-то внешнем к нему.

EP>>>>Какие плюсы у C# перед Python примирительно к скриптам?

S>>> На C# можно писать в стиле скриптов через динамики, компилировать динамические сборки.
EP>>Напиши apply, посмотрим на это "в стиле скриптов".
S> А что писать? Я уже давал ссылки на динамическую компиляцию в реал тайме.

apply.

S>Покажи, задачу.


Я постоянно использую различные функции высшего порядка и т.п.
apply это всего лишь дистиллированный пример.

S>Если на C# не получится можно использовать сборки на айрон питоне,


Зачем если есть обычный Python?

S>немерле.


Речь-то про C# vs Python. Nemerle — это другой разговор.

S>>>Напиши динамическую обертку IDispatch над любым объектом С++

EP>>Я же сказал, для этого проще всего взять интерпретатор Cling — сможешь обращаться к любому объекту.
EP>>А вообще непонятно к чему это, вопрос-то был какие плюсы у C# перед Python в отношении скриптов
S> Так сделай. Я потратил 15 минут. Сколько уйдет у тебя?

Точно больше 15, так как метод решения другой.

S>Ну дык сделай на питоне эту задачу. Все ведь элементарно.


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

S> Больше времени на этом сайте тратишь. 1С ники будут благодарны расширению их функционала за счет С++ библиотек.

S>Так смотришь и перейдут на С++.

Это вряд ли, у меня нет цели всех переманить на C++. И как уже говорил, я сам его не везде использую.
Я лишь показываю что о C++ много мифов, люди строят какие-то предположения на основе каких-то старых баек, и на основе этих неверных предположений принимают какие-то неверные решения, и более того — распространяют эти мифы дальше. Вот это вот всё нужно купировать.
Re[43]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 12.10.15 21:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.

G>Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.

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

_>>Это с каких это пор нельзя передавать параметром? ) shared_ptr — это для очень специфического кода.

G>Вот так и нельзя, конструктора копирования нет.

http://coliru.stacked-crooked.com/a/9bbe2dcb540ba2fb
#include <utility>
#include <memory>
using namespace std;

void test(unique_ptr<int>)
{
}

auto factory()
{
    return make_unique<int>(1);
}

int main()
{
    test(factory());
    test(make_unique<int>(2));

    auto x = factory();
    // test(x); - compile error
    test(move(x));
}
Re[97]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 07:23
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Что не то? ) Это вызов в 1C произвольной функции из произвольной нативной DLL. Ты кажется этого хотел или нет? )

S> Разницу не чувствуешь, статический метод и метод класса. Сделай примеры из статьи. И посмотрим. В чем проблема?

Как только в формат dll введут понятие классов, объектов и т.п., то непременно сделаю. Хотя сомневаюсь что это когда-нибудь будет возможно (собственно из-за этой проблемы и родился COM), т.к. слишком по разному представляют себе объекты в разных языках. Теоретически можно делать интерфейсы под конкретный язык (а иногда надо будет даже под конкретный компилятор), но непонятно зачем кому-то может понадобиться подобное не универсальное решение.

_>>Что сделать то? ) Напиши чётко и ясно. Работа с произвольным C++ классом (данным нам в исходниках) показана. Работа с произвольной dll тоже. Чего ещё не хватает? )

S> В статье есть куча примеров.

Ну т.е. сформулировать не можешь. Понятно. )))

_>>Эээ что? )))

S> Ну опять же в статье есть пример использования Вэб сервисов. Правда нужно сгенерить сборку в VS и её использовать.
S>Вот выдержка из статьи использования

На C++ это всё элементарно делается. Хотя лично я бы использовал в данном случае Питон. Как раз подходящее под него задачка (небольшой объём и не требуется производительность).
Re[43]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 07:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Вот только unique_ptr везде использовать не получится (их нельзя просто передать параметром) и немалая часть указателей станет shared_ptr, что приведет к дополнительным издержкам на передачу в функции.

_>>Это с каких это пор нельзя передавать параметром? ) shared_ptr — это для очень специфического кода.
G>Вот так и нельзя, конструктора копирования нет.

Ну так зато конструктор перемещения есть. Это если надо передать владение. А если просто значением поделиться, то для этого есть ссылки.

G>>>Или передаем голые указатели и C++ превращается в C_с_классами.

_>>Ты путаешь. Голые указатели — это как раз нормально (а как ты без них скажем с win api поработаешь?). Не нормально это ручное удаление памяти и т.п.
G>WinAPI это C, а не C++

Конечно, но работать то с ним всё равно надо. ))) Ну точнее лично я давно не имею с ним дел напрямую (только через кроссплатформенные библиотеки), но это не отменяет того факта, что внутри них гуляют кучи этих указателей.

G>>>Кстати проблема вовсе не в delete, а в том, что указатель может быть сохранен в поле класса или статической переменной и произойдёт обращение к освобожденной памяти.

_>>Ну т.е. проблема в том, что delete вызван раньше, чем положено. Опять же проблема кривой архитектуры.
G>Почему подобная кривая архитектура невозможна в C# или Java? Видимо проблема языка.

Ну почему же. В unsafe C# вполне возможно всё тоже самое. И при этом, как ты помнишь, unsafe C# заметно эффективнее нормального на многих задачах. Ну а C++ в силу своей целевой ниши просто физически не имеет права генерировать не самый оптимальный код. )))
Re[116]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 07:39
Оценка: -2
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>Зачем если есть обычный Python?


S>>немерле.


EP>Речь-то про C# vs Python. Nemerle — это другой разговор.

А то, что если мне вдруг не будет хватать C# я легко могу сделать сборку на любом нетовском языке

S>>>>Напиши динамическую обертку IDispatch над любым объектом С++

EP>>>Я же сказал, для этого проще всего взять интерпретатор Cling — сможешь обращаться к любому объекту.
EP>>>А вообще непонятно к чему это, вопрос-то был какие плюсы у C# перед Python в отношении скриптов
S>> Так сделай. Я потратил 15 минут. Сколько уйдет у тебя?

EP>Точно больше 15, так как метод решения другой.


S>>Ну дык сделай на питоне эту задачу. Все ведь элементарно.


EP>Интерпретатор уже готовый, тратить время на оборачивание его в какое-то API, привязанное к одной конкретной платформе — мне не интересно.

Ну вот начинается. А у меня все сделане для любой нетовской сборке и написано за 15 минут.

S>> Больше времени на этом сайте тратишь. 1С ники будут благодарны расширению их функционала за счет С++ библиотек.

S>>Так смотришь и перейдут на С++.

EP>Это вряд ли, у меня нет цели всех переманить на C++. И как уже говорил, я сам его не везде использую.

EP>Я лишь показываю что о C++ много мифов, люди строят какие-то предположения на основе каких-то старых баек, и на основе этих неверных предположений принимают какие-то неверные решения, и более того — распространяют эти мифы дальше. Вот это вот всё нужно купировать.
Надо признавать факты того, что определенные вещи легко делаются на Net? чего нет в ваших любимых нативных языках.
А так упорствуй дальше и считай что C++ в связке с Питоном это верх совершенства.
и солнце б утром не вставало, когда бы не было меня
Re[98]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 07:46
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Что не то? ) Это вызов в 1C произвольной функции из произвольной нативной DLL. Ты кажется этого хотел или нет? )

S>> Разницу не чувствуешь, статический метод и метод класса. Сделай примеры из статьи. И посмотрим. В чем проблема?

_>Как только в формат dll введут понятие классов, объектов и т.п., то непременно сделаю. Хотя сомневаюсь что это когда-нибудь будет возможно (собственно из-за этой проблемы и родился COM), т.к. слишком по разному представляют себе объекты в разных языках. Теоретически можно делать интерфейсы под конкретный язык (а иногда надо будет даже под конкретный компилятор), но непонятно зачем кому-то может понадобиться подобное не универсальное решение.

Ну вот видишь оказывается у натива есть ограничения по сравнению с Net. А там смотришь и рефлексию добавят.

_>>>Что сделать то? ) Напиши чётко и ясно. Работа с произвольным C++ классом (данным нам в исходниках) показана. Работа с произвольной dll тоже. Чего ещё не хватает? )

S>> В статье есть куча примеров.

_>Ну т.е. сформулировать не можешь. Понятно. )))


_>>>Эээ что? )))

S>> Ну опять же в статье есть пример использования Вэб сервисов. Правда нужно сгенерить сборку в VS и её использовать.
S>>Вот выдержка из статьи использования

_>На C++ это всё элементарно делается. Хотя лично я бы использовал в данном случае Питон. Как раз подходящее под него задачка (небольшой объём и не требуется производительность).


Ну дык сделай. Именно сборку, а не COM. Я беру любую сборку и использую ей в 1С без всякой подготовки.
Но например для поддержки событий в планах написать динамическую компиляцию для создания прокси класса обертки над объектом для реализации комовских событий.
У меня на Net возможностей куча ибо рефлексия, динамическая компиляция и IReflect.
Ну а вы считайте дальше, что C++ в связке с Питоном верх совершенства.
и солнце б утром не вставало, когда бы не было меня
Re[99]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 08:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Как только в формат dll введут понятие классов, объектов и т.п., то непременно сделаю. Хотя сомневаюсь что это когда-нибудь будет возможно (собственно из-за этой проблемы и родился COM), т.к. слишком по разному представляют себе объекты в разных языках. Теоретически можно делать интерфейсы под конкретный язык (а иногда надо будет даже под конкретный компилятор), но непонятно зачем кому-то может понадобиться подобное не универсальное решение.

S> Ну вот видишь оказывается у натива есть ограничения по сравнению с Net. А там смотришь и рефлексию добавят.

Ещё раз повторяю: это не проблема нейтива vs .net, это проблема несовместимости ООП разных языков. И .net тут ничем не помогает — ты точно так же не можешь использовать его объекты из 1C и оборачиваешь их в COM для возможности взаимодействия.

_>>На C++ это всё элементарно делается. Хотя лично я бы использовал в данном случае Питон. Как раз подходящее под него задачка (небольшой объём и не требуется производительность).

S> Ну дык сделай. Именно сборку, а не COM. Я беру любую сборку и использую ей в 1С без всякой подготовки.

Т.е. .net сборку можно подключать через COM, C++ COM запрещён, да?

S>Но например для поддержки событий в планах написать динамическую компиляцию для создания прокси класса обертки над объектом для реализации комовских событий.

S>У меня на Net возможностей куча ибо рефлексия, динамическая компиляция и IReflect.

Ты так пишешь, как будто мы тебя тут отговариваем этим заниматься. )))

S>Ну а вы считайте дальше, что C++ в связке с Питоном верх совершенства.


Это только для прикладных задач повышенной сложности. В большинстве остальных случаев они рулят по одиночке. )))
Re[100]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 08:32
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Как только в формат dll введут понятие классов, объектов и т.п., то непременно сделаю. Хотя сомневаюсь что это когда-нибудь будет возможно (собственно из-за этой проблемы и родился COM), т.к. слишком по разному представляют себе объекты в разных языках. Теоретически можно делать интерфейсы под конкретный язык (а иногда надо будет даже под конкретный компилятор), но непонятно зачем кому-то может понадобиться подобное не универсальное решение.

S>> Ну вот видишь оказывается у натива есть ограничения по сравнению с Net. А там смотришь и рефлексию добавят.

_>Ещё раз повторяю: это не проблема нейтива vs .net, это проблема несовместимости ООП разных языков. И .net тут ничем не помогает — ты точно так же не можешь использовать его объекты из 1C и оборачиваешь их в COM для возможности взаимодействия.

Что не могу? Чьи объекты я не могу использовать? Любые не подвергнутые обфускации классы и объекты я могу использовать. Мало того прекрасно использую анонимные типы. Для каждого типа есть информация о нем.

_>>>На C++ это всё элементарно делается. Хотя лично я бы использовал в данном случае Питон. Как раз подходящее под него задачка (небольшой объём и не требуется производительность).

S>> Ну дык сделай. Именно сборку, а не COM. Я беру любую сборку и использую ей в 1С без всякой подготовки.

_>Т.е. .net сборку можно подключать через COM, C++ COM запрещён, да?

Да дело в том, что классы содержащиеся в сборке то не поддерживают COM. У тебя все C++ классы поддерживают COM?

S>>Но например для поддержки событий в планах написать динамическую компиляцию для создания прокси класса обертки над объектом для реализации комовских событий.

S>>У меня на Net возможностей куча ибо рефлексия, динамическая компиляция и IReflect.

_>Ты так пишешь, как будто мы тебя тут отговариваем этим заниматься. )))


S>>Ну а вы считайте дальше, что C++ в связке с Питоном верх совершенства.


_>Это только для прикладных задач повышенной сложности. В большинстве остальных случаев они рулят по одиночке. )))

Ну а .Net вообще не рулит? А то вы со своими могучими Питонами и C++ не можете сделать вещи, которые элементарно делаются на Net.
и солнце б утром не вставало, когда бы не было меня
Re[101]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 09:09
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Ещё раз повторяю: это не проблема нейтива vs .net, это проблема несовместимости ООП разных языков. И .net тут ничем не помогает — ты точно так же не можешь использовать его объекты из 1C и оборачиваешь их в COM для возможности взаимодействия.

S> Что не могу? Чьи объекты я не могу использовать? Любые не подвергнутые обфускации классы и объекты я могу использовать. Мало того прекрасно использую анонимные типы. Для каждого типа есть информация о нем.

Ты не можешь использовать объекты .net в 1C без посредника в виде COM'a.

S>>> Ну дык сделай. Именно сборку, а не COM. Я беру любую сборку и использую ей в 1С без всякой подготовки.

_>>Т.е. .net сборку можно подключать через COM, C++ COM запрещён, да?
S>Да дело в том, что классы содержащиеся в сборке то не поддерживают COM. У тебя все C++ классы поддерживают COM?

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

S>>>Ну а вы считайте дальше, что C++ в связке с Питоном верх совершенства.

_>>Это только для прикладных задач повышенной сложности. В большинстве остальных случаев они рулят по одиночке. )))
S>Ну а .Net вообще не рулит? А то вы со своими могучими Питонами и C++ не можете сделать вещи, которые элементарно делаются на Net.

.Net рулит для бизнеса, у которого IT не является главным профилем. )))
Re[102]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 10:06
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Ещё раз повторяю: это не проблема нейтива vs .net, это проблема несовместимости ООП разных языков. И .net тут ничем не помогает — ты точно так же не можешь использовать его объекты из 1C и оборачиваешь их в COM для возможности взаимодействия.

S>> Что не могу? Чьи объекты я не могу использовать? Любые не подвергнутые обфускации классы и объекты я могу использовать. Мало того прекрасно использую анонимные типы. Для каждого типа есть информация о нем.

_>Ты не можешь использовать объекты .net в 1C без посредника в виде COM'a.

Я это делаю динамически через враппер. Сделай такой динамический врапер на нативных языках.

S>>>> Ну дык сделай. Именно сборку, а не COM. Я беру любую сборку и использую ей в 1С без всякой подготовки.

_>>>Т.е. .net сборку можно подключать через COM, C++ COM запрещён, да?
Подключай. Можешь динамически компилировать сборку. Главное, что бы это было все динамически.
S>>Да дело в том, что классы содержащиеся в сборке то не поддерживают COM. У тебя все C++ классы поддерживают COM?

_>Так ты же предлагаешь мне написать соответствующий C++ код (что-то там с веб-сервисами и т.п.), а не использовать некую чужую готовую DLL. Соответственно если я пишу своё решение на C++ для вызова из 1C, то я естественно сделают там поддержку COM (в несколько строчек это делается).


Так сделай это динамически. В чем проблема? Свое решение я тебе показал.
S>>>>Ну а вы считайте дальше, что C++ в связке с Питоном верх совершенства.
_>>>Это только для прикладных задач повышенной сложности. В большинстве остальных случаев они рулят по одиночке. )))
S>>Ну а .Net вообще не рулит? А то вы со своими могучими Питонами и C++ не можете сделать вещи, которые элементарно делаются на Net.

_>.Net рулит для бизнеса, у которого IT не является главным профилем. )))

То есть Asp.Mvc это не IT? 1C это тоже не IT?
У манагед языков обширная ниша, а ты все твердишь, что C++ наше все
и солнце б утром не вставало, когда бы не было меня
Re[103]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 10:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Да дело в том, что классы содержащиеся в сборке то не поддерживают COM. У тебя все C++ классы поддерживают COM?

_>>Так ты же предлагаешь мне написать соответствующий C++ код (что-то там с веб-сервисами и т.п.), а не использовать некую чужую готовую DLL. Соответственно если я пишу своё решение на C++ для вызова из 1C, то я естественно сделают там поддержку COM (в несколько строчек это делается).
S> Так сделай это динамически. В чем проблема? Свое решение я тебе показал.

Как только ты объяснишь зачем это делать динамически. )))

S>>>Ну а .Net вообще не рулит? А то вы со своими могучими Питонами и C++ не можете сделать вещи, которые элементарно делаются на Net.

_>>.Net рулит для бизнеса, у которого IT не является главным профилем. )))
S> То есть Asp.Mvc это не IT? 1C это тоже не IT?

А 1C написал на .net? )))

S>У манагед языков обширная ниша, а ты все твердишь, что C++ наше все


Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))
Re[102]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.10.15 10:44
Оценка:
Здравствуйте, alex_public, Вы писали:

S>>Ну а .Net вообще не рулит? А то вы со своими могучими Питонами и C++ не можете сделать вещи, которые элементарно делаются на Net.


_>.Net рулит для бизнеса, у которого IT не является главным профилем. )))


Можно проще — .Net рулит для бизнеса.
C++ — всего лишь для некоторой части инфраструктуры.
Re[103]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.10.15 10:46
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>.Net рулит для бизнеса, у которого IT не является главным профилем. )))

S> То есть Asp.Mvc это не IT? 1C это тоже не IT?
S>У манагед языков обширная ниша, а ты все твердишь, что C++ наше все

Asp.Mvc и есть .net. А вот 1С это не ИТ, это автоматизация бизнеса. То есть, .Net нужен там, где зарабатываются основные деньги.
С++ это некоторая часть инфраструктуры — операционная система, драйверы и подобные вещи. Бизнез-специфику на С++ почти не пишут.
Re[104]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 10:54
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>>>Да дело в том, что классы содержащиеся в сборке то не поддерживают COM. У тебя все C++ классы поддерживают COM?

_>>>Так ты же предлагаешь мне написать соответствующий C++ код (что-то там с веб-сервисами и т.п.), а не использовать некую чужую готовую DLL. Соответственно если я пишу своё решение на C++ для вызова из 1C, то я естественно сделают там поддержку COM (в несколько строчек это делается).
S>> Так сделай это динамически. В чем проблема? Свое решение я тебе показал.

_>Как только ты объяснишь зачем это делать динамически. )))


Я заранее не знаю, что захочет 1С ник. У него постоянно проблемы с регистрацией COM и ему не нужен зоопарк Com компонентов.

S>>>>Ну а .Net вообще не рулит? А то вы со своими могучими Питонами и C++ не можете сделать вещи, которые элементарно делаются на Net.

_>>>.Net рулит для бизнеса, у которого IT не является главным профилем. )))
S>> То есть Asp.Mvc это не IT? 1C это тоже не IT?

_>А 1C написал на .net? )))

Я на 1С через врапер использую сборки Net расширяя функционал 1С

S>>У манагед языков обширная ниша, а ты все твердишь, что C++ наше все


_>Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))

Я как раз имел ввиду все манагед языки. Ибо есть ведь и манагед С++.
и солнце б утром не вставало, когда бы не было меня
Re[104]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 10:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


_>>>.Net рулит для бизнеса, у которого IT не является главным профилем. )))

S>> То есть Asp.Mvc это не IT? 1C это тоже не IT?
S>>У манагед языков обширная ниша, а ты все твердишь, что C++ наше все

I>Asp.Mvc и есть .net. А вот 1С это не ИТ, это автоматизация бизнеса. То есть, .Net нужен там, где зарабатываются основные деньги.

I>С++ это некоторая часть инфраструктуры — операционная система, драйверы и подобные вещи. Бизнез-специфику на С++ почти не пишут.
Я вобщем то про это и пишу.
Ну а на 1С кстати деньги зарабатывают то больше всех в стране.
Читаем Вики

Информацио́нные техноло́гии (ИТ, также — информационно-коммуникационные технологии[1]) — процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов (ФЗ № 149-ФЗ)[2]; приёмы, способы и методы применения средств вычислительной техники при выполнении функций сбора, хранения, обработки, передачи и использования данных (ГОСТ 34.003-90)[3]; ресурсы, необходимые для сбора, обработки, хранения и распространения информации (ISO/IEC 38500:2008)[4].

1С это IT. А сборки Net легко использовать в 1С через класы реализующие IReflect
и солнце б утром не вставало, когда бы не было меня
Re[103]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 11:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>.Net рулит для бизнеса, у которого IT не является главным профилем. )))

I>Можно проще — .Net рулит для бизнеса.
I>C++ — всего лишь для некоторой части инфраструктуры.

Ну т.е. всякие там гуглы, яндексы или вообще варгейминги — это не бизнесы? )))
Re[105]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 11:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Так сделай это динамически. В чем проблема? Свое решение я тебе показал.

_>>Как только ты объяснишь зачем это делать динамически. )))
S> Я заранее не знаю, что захочет 1С ник. У него постоянно проблемы с регистрацией COM и ему не нужен зоопарк Com компонентов.

Огромный зоопарк COM компонентов и так присутствует на любой винде, потому что это одна из базовых технологий и на ней подстроено очень много подсистем.

Ну так ты можешь наконец чётко сформулировать какую задачу ты хочешь решить или нет? )))

S>>> То есть Asp.Mvc это не IT? 1C это тоже не IT?

_>>А 1C написал на .net? )))
S> Я на 1С через врапер использую сборки Net расширяя функционал 1С

Ну так это ты... ) Судя по тому, что авторы 1C сами не предусмотрели такой возможности, .net их особо не интересует. )))

S>>>У манагед языков обширная ниша, а ты все твердишь, что C++ наше все

_>>Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))
S>Я как раз имел ввиду все манагед языки. Ибо есть ведь и манагед С++.

В таком случае ты наврал, причём ещё и от моего имени. Т.к. я никогда не говорил что "C++ наше всё", подразумевая его как замену и Python'у, JS, и т.п.)
Re[106]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 11:53
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>>> Так сделай это динамически. В чем проблема? Свое решение я тебе показал.

_>>>Как только ты объяснишь зачем это делать динамически. )))
S>> Я заранее не знаю, что захочет 1С ник. У него постоянно проблемы с регистрацией COM и ему не нужен зоопарк Com компонентов.

_>Огромный зоопарк COM компонентов и так присутствует на любой винде, потому что это одна из базовых технологий и на ней подстроено очень много подсистем.

Так зачем этот зоопарк если можно без него? Проще использовать оди Com компонент который загружает сборки.
На самом деле я тоже так думал, но потом столкнулся с Вэб сервисами с кучей классов итд. И было проще использовать один враппер на любые нетовские сборки.
Это уже пройденный этап.

_>Ну так ты можешь наконец чётко сформулировать какую задачу ты хочешь решить или нет? )))


S>>>> То есть Asp.Mvc это не IT? 1C это тоже не IT?

_>>>А 1C написал на .net? )))
S>> Я на 1С через врапер использую сборки Net расширяя функционал 1С

_>Ну так это ты... ) Судя по тому, что авторы 1C сами не предусмотрели такой возможности, .net их особо не интересует. )))

Они еще и линукс придумали и Систему внешних компонент.
Линуксом пользуются немногие, а мой врапер по сути делает ненужным внешние компоненты. Но проблема в другом.
Для использования моего врапера нужно знать классы Net. Хотя есть куча примеров как решить ту или иную задачу.
В 1С есть минимальный набор для работы с HTTP, файлами, Вэб сервисами. Но если что то сложнее то все проблему.
Я тебе уже давал ссылки на битовые операции на 1С. Проблема только в одном мало кто знает .Net. Программируют только на 1С.
Кстати и 1С то Net не жалуют. Примеры для C++ Delphi. А для C# была только в свое время Вэб компонента.
Сейчас кстати добавляют Json. Просто зная Net расширение языка безгранично.
Правда не знаю как на линуксе можно соединить натив с манагед.
Основа использования манагедв нативе это информация о типах.



S>>>>У манагед языков обширная ниша, а ты все твердишь, что C++ наше все

_>>>Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))
S>>Я как раз имел ввиду все манагед языки. Ибо есть ведь и манагед С++.

_>В таком случае ты наврал, причём ещё и от моего имени. Т.к. я никогда не говорил что "C++ наше всё", подразумевая его как замену и Python'у, JS, и т.п.)

Но ты говоршь, что C# то отстой и что С++ в связке с Питоном это ваше все.
А я говорю, что у каждого языка есть своя ниша. Свои достоинства и недостатки.
и солнце б утром не вставало, когда бы не было меня
Re[107]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 13:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Огромный зоопарк COM компонентов и так присутствует на любой винде, потому что это одна из базовых технологий и на ней подстроено очень много подсистем.

S>Так зачем этот зоопарк если можно без него? Проще использовать оди Com компонент который загружает сборки.

Т.е. DirectX тоже перепишем под .net и будем запускать через обёртку? )))

_>>>>Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))

S>>>Я как раз имел ввиду все манагед языки. Ибо есть ведь и манагед С++.
_>>В таком случае ты наврал, причём ещё и от моего имени. Т.к. я никогда не говорил что "C++ наше всё", подразумевая его как замену и Python'у, JS, и т.п.)
S>Но ты говоршь, что C# то отстой и что С++ в связке с Питоном это ваше все.

Я как раз говорил, что частенько использую Питон сам по себе. Да и JS приходится иногда.

S>А я говорю, что у каждого языка есть своя ниша. Свои достоинства и недостатки.


А тут кто-то с этим спорит? )
Re[28]: Java vs C# vs C++
От: Somescout  
Дата: 13.10.15 13:38
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

S>>А в чём красота, что нашли (наконец) куда засунуть пользовательские суффиксы?

EP>Почему "наконец"? Их вводили вполне под конкретные нужды.
Ога, ведь стандарт C++ удобный, компактный и легко расширяемый.

EP>А вообще там оппонент непонятно зачем начал показывать готовый Complex в C#, хотя пример был совершенно не про это. В ответ я и показал что есть из коробки в C++

Речь в моём сообщении шла о выделенных жирным параметрах конструктора. Пользовательские суффиксы (уж извините, не знаю как они официально называются) из всех виденных примеров только тут их использование хоть чем-то оправданно.

EP>Кто? Я как раз говорю что язык в том числе и не гибкий.

Вы пытаетесь приводя удобные вам примеры доказать что для удобных вам задач язык не подходит. Особого смысла спорить с этим нет, однако в прошлом обсуждении ответа, к примеру, на не очень удобный вопрос по рефлексии в языке как-то не последовало.
ARI ARI ARI... Arrivederci!
Re[40]: Java vs C# vs C++
От: · Великобритания  
Дата: 13.10.15 15:08
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>·>Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.

_>>>Ну так у меня же мало практики в написание заведомо некорректного кода. Я вообще сам delete раз год вижу, даже с корректным кодом. А тут такое... )))
_>·>Ты написал его типично. Чаще так оно и происходит. Время жизни в одном месте, удаление в другом месте, добавленное в другое время, другим девом в другом потоке.

_>Это типично для C. На C++ такой код вообще не встречается. Просто на нормальном для C++ коде было бы невозможно продемонстрировать описываемый тобой баг


_>
_>{
_>    auto x=make_unique<T>();
doSomethingProbablyInAnotherThread(*x);// а если так?
_>    //...
_>} //в этой точке вызывается delete (сам!)
_>// а здесь уже не добраться до указателя, чтобы продемонстрировать обсуждаемое поведение
_>


_> (в отличие от Жабки, где это без проблем):

И чем это отличается от Жабки-то?
{
   T x = new T();
doSomethingProbablyInAnotherThread(x);
   //...
}//в этой точке x становится доступен для gc (сам!), но только если ссылка никуда в другой контекст не ускользнула.
// и чё?


_>>>В своих, ушедших в продакшен, — не видел. )

_>·>А сколько девов принимало участие? Сколько человеколет? Если меньше 5 девов, менее сотни человеколет, то это мелкие проекты... Их хоть на ассемблере пиши, не принципиально.
_>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
Зависит. Если один человек напишет код и не будет сильно трогать после, то одно, а другое если у тебя проект с десяктами девов, продолжительностью в несколько лет, с релизами каждые две недели, то это совершенно другие правила игры.
Дело не в delete, а в &-ссылках или *-указателях.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Java vs C# vs C++
От: · Великобритания  
Дата: 13.10.15 15:26
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Говорю же — два режима оптимальны. Второй режим — объекты создаются и уничтожаются редко. Редко меняется граф объектов в памяти. (т.е. топология графа не меняется, но данные внутри объектов меняться могут).

_>·>Неоптимальный режим — создали кучу объектов, помариновали их какое-то время и потом грохаем.
_>"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.
Различного вида буферы, кеши, пулы — это оно. Они никому не интересны??!

_>Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).

Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.

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

_>·>Собственно и в плюсах ты переходишь от комфортного by-value/on stack к хитрым аллокаторам, жонглированию различными типами указателей, повышая риск что-то поломать или потерять.
_>Ещё раз повторяю: на C++ я перехожу к такому режиму только на очень узком спектре задач, требующих постоянное создания/удаления мелких объектов. Обычно такое наблюдается при написание каких-нибудь компиляторов, интерпретаторов и т.п. На большинстве задач такого нет даже близко. И уж тем более не в области LL, где все выделения памяти рекомендуется сделать вне главного цикла.
Так ведь есть ещё неглавные циклы...

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

_>·>Собственно в LL-системе "плохая" часть очень маленькая. Только из малой области кода выжимаются все соки, а остальное пишется как обычно, с комфортом GC.
_>Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))
Если уж по правде говорить, то С++ синтаксис на порядок сложнее java (надеюсь, не будешь спорить?). А поэтому да, с таким же комфортом. Однако этот комфорт ниже типичного в Яве. Особенно при наличии IDE.

_>>>Абсолютно не такая же. Напомню, что мы здесь обсуждали возможности JIT выбрать расположение и типы данных (куча/стек, ссылка/значение и т.д.) наиболее оптимальным способом. И в отличие от качества генерирования ассемблерного кода оптимизаторами C++, тут ситуация даже не приблизилась к идеалу. И я сомневаюсь что приблизится когда-нибудь, т.к. тут задача намного сложнее.

_>·>Принципиально — для JIT оптимизаций доступно гораздо больше информации, т.к. оно работает во время испонения. И оптимизация происходит именно в соответствии с реальной нагрузкой. Есть, конечно Profile Guided Optimisation, но она, насколько я знаю, представляет в основном академиеческий интерес.
_>Я говорю не про теорию, а про практику. В теории компиляторы могли создавать отличный ассемблерный код и 30 лет назад — ничего этому не мешало. Однако на практике они достигли уровня, сравнимого с человеком, только лет 5-10 назад. Так вот в области автоматической оптимизации типов и т.п. на практике нет пока почти ничего реально работающего. Может лет 10-20 и появится что-то существенное, но пока такого нет.
А вот теперь представь, что этим компиляторам дают не только исходный код, но и статистику реального выполнения программы с реальными данными.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[108]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.10.15 15:37
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>Огромный зоопарк COM компонентов и так присутствует на любой винде, потому что это одна из базовых технологий и на ней подстроено очень много подсистем.

S>>Так зачем этот зоопарк если можно без него? Проще использовать оди Com компонент который загружает сборки.

_>Т.е. DirectX тоже перепишем под .net и будем запускать через обёртку? )))

Если надо то нет проблем http://habrahabr.ru/post/142025/

_>>>>>Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))

S>>>>Я как раз имел ввиду все манагед языки. Ибо есть ведь и манагед С++.
_>>>В таком случае ты наврал, причём ещё и от моего имени. Т.к. я никогда не говорил что "C++ наше всё", подразумевая его как замену и Python'у, JS, и т.п.)
S>>Но ты говоршь, что C# то отстой и что С++ в связке с Питоном это ваше все.

_>Я как раз говорил, что частенько использую Питон сам по себе. Да и JS приходится иногда.

Да уж куда без него. А я вот предпочитаю TS

S>>А я говорю, что у каждого языка есть своя ниша. Свои достоинства и недостатки.


_>А тут кто-то с этим спорит? )

Пока вы все говорите, то что делается на C# легко реализуется на C# и с лучшей скоростью. Я привожу примеры, что это не так.
и солнце б утром не вставало, когда бы не было меня
Re[29]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 13.10.15 16:50
Оценка:
Здравствуйте, Somescout, Вы писали:

EP>>А вообще там оппонент непонятно зачем начал показывать готовый Complex в C#, хотя пример был совершенно не про это. В ответ я и показал что есть из коробки в C++

S>Речь в моём сообщении шла о выделенных жирным параметрах конструктора. Пользовательские суффиксы (уж извините, не знаю как они официально называются) из всех виденных примеров только тут их использование хоть чем-то оправданно.

Выше был пример про единицы измерения + dimensional analysis.

EP>>Кто? Я как раз говорю что язык в том числе и не гибкий.

S>Вы пытаетесь приводя удобные вам примеры доказать что для удобных вам задач язык не подходит.

Я уже в этой теме говорил, что использую и C++ и Python, и даже C#. И да, для задач выбираю тот язык который более удобен

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


Это демагогия. Вообще-то я сразу сказал что это недостаток:

S>>Нету у вас рефлекшина.

EP>Нету, это недостаток, сейчас кое-как эмулируется. При этом reflection не обязательно должен быть runtime — он может быть compile-time, и такой скорей всего и введут.

Какой ещё ответ должен был последовать?
Re[104]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.10.15 18:51
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Можно проще — .Net рулит для бизнеса.

I>>C++ — всего лишь для некоторой части инфраструктуры.

_>Ну т.е. всякие там гуглы, яндексы или вообще варгейминги — это не бизнесы? )))


Бизнесы. Инфраструктура в них пишется на плюсах. Бизнес-специфика — в основном на менеджед решениях. Драйвер — инфраструктура. База данных — инфраструктура. Как то так.
Re[30]: Java vs C# vs C++
От: Somescout  
Дата: 13.10.15 19:03
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Выше был пример про единицы измерения

Как раз бессмысленный синтаксический сахар. Фактически вместо KG(5) пишем 5kg — нереальный выигрыш.

EP>+ dimensional analysis.

Посмотрю чуть позже.

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


EP>Это демагогия. Вообще-то я сразу сказал что это недостаток:

Да неужели? Вот память-то меня подводит:

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

А вот раскрыть подробности внешней утилиты — этого я уже не дождался.

EP>Какой ещё ответ должен был последовать?

Кровавые подробности того как:

И эта добавленная рефлексия, позволит мне, к примеру, загрузить внешний модуль (чужой внешний модуль) в рантайме, пройтись по его классам, выбрать нужные мне, создать их (instantiate) и заглянуть во внутрь рефлексией?

Реализуются внешней утилитой.
ARI ARI ARI... Arrivederci!
Re[117]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 13.10.15 19:59
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Зачем если есть обычный Python?

S>>>немерле.
EP>>Речь-то про C# vs Python. Nemerle — это другой разговор.
S> А то, что если мне вдруг не будет хватать C# я легко могу сделать сборку на любом нетовском языке

А я вообще возьму любой язык

S>>>Ну дык сделай на питоне эту задачу. Все ведь элементарно.

EP>>Интерпретатор уже готовый, тратить время на оборачивание его в какое-то API, привязанное к одной конкретной платформе — мне не интересно.
S> Ну вот начинается. А у меня все сделане для любой нетовской сборке и написано за 15 минут.

Вот практически готовый пример.

EP>>Это вряд ли, у меня нет цели всех переманить на C++. И как уже говорил, я сам его не везде использую.

EP>>Я лишь показываю что о C++ много мифов, люди строят какие-то предположения на основе каких-то старых баек, и на основе этих неверных предположений принимают какие-то неверные решения, и более того — распространяют эти мифы дальше. Вот это вот всё нужно купировать.
S> Надо признавать факты того,

А я не отрицал. Я тебе в первом же ответе сказал что иногда сам использую C#, но ты это продолжаешь упорно игнорировать, и спорить с какими-то воображаемыми тезисами.

S>что определенные вещи легко делаются на Net? чего нет в ваших любимых нативных языках.


Есть некоторые вещи которые проще на .NET.

S> А так упорствуй дальше и считай что C++ в связке с Питоном это верх совершенства.


Это откровенное и наглое враньё
Re[31]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 13.10.15 20:27
Оценка:
Здравствуйте, Somescout, Вы писали:

EP>>Выше был пример про единицы измерения

S>Как раз бессмысленный синтаксический сахар. Фактически вместо KG(5) пишем 5kg — нереальный выигрыш.

Один из мотивирующих примеров. Другие use-case'ы: бинарные литералы, литералы для больших чисел.

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

EP>>Это демагогия. Вообще-то я сразу сказал что это недостаток:
S>Да неужели? Вот память-то меня подводит:
S>

Сейчас же это реализуется через макросы, причём получается даже чище чем в языках с передовым мета-программированием.


В этой цитате была конкретная ссылка
Автор: Evgeny.Panasyuk
Дата: 24.10.13
.

S>

В целом же рефлексию добавить внешней утилитой намного проще чем восполнить отсутствующее метапрограммирование.

S>А вот раскрыть подробности внешней утилиты — этого я уже не дождался.

Там дальше же подробности и описываются:

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

То есть генерируй классы по схеме чем угодно, хоть тем же Python'ом. В одном из проектов у меня так и происходит, причём там генерируется не только C++ код — то есть генерировать всё равно пришлось бы.

Другой вариант например взять выхлоп от SWIG:

SWIG can also export its parse tree in the form of XML and Lisp s-expressions


EP>>Какой ещё ответ должен был последовать?

S>Кровавые подробности того как:
S>

И эта добавленная рефлексия, позволит мне, к примеру, загрузить внешний модуль (чужой внешний модуль) в рантайме, пройтись по его классам, выбрать нужные мне, создать их (instantiate) и заглянуть во внутрь рефлексией?

S>Реализуются внешней утилитой.

Я вполне явно говорил про compile-time reflection
Если автор этого стороннего модуля применит её — то из неё легко автоматически получить runtime reflection. Если есть заголовки — то это можно сделать на своей стороне. Если же нет заголовков — тогда вообще о чём идёт речь? О неизвестно откуда полученных бинарниках?
Re[41]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 20:51
Оценка:
Здравствуйте, ·, Вы писали:

_>>Это типично для C. На C++ такой код вообще не встречается. Просто на нормальном для C++ коде было бы невозможно продемонстрировать описываемый тобой баг

_>> (в отличие от Жабки, где это без проблем):
·>И чем это отличается от Жабки-то?

Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.

_>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.

·>Зависит. Если один человек напишет код и не будет сильно трогать после, то одно, а другое если у тебя проект с десяктами девов, продолжительностью в несколько лет, с релизами каждые две недели, то это совершенно другие правила игры.
·>Дело не в delete, а в &-ссылках или *-указателях.

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

— использование контейнеров stl (если конечно не требуется чего-то специфического)
— следование какой-то известной архитектуре организации многопоточности (например мне нравится модель акторов).
Re[39]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 21:08
Оценка:
Здравствуйте, ·, Вы писали:

_>>"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.

·>Различного вида буферы, кеши, пулы — это оно. Они никому не интересны??!

Не интересно время их выделения/уничтожения, потому как сам же говоришь, что это происходит редко.

_>>Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).

·>Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.

Не очень понятно. Эти самые потоки "Б, В, Г, и, иногда Д" должны получить изначальную версию объекта, обработанную версию объекта, или обе? )

_>>Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))

·>Если уж по правде говорить, то С++ синтаксис на порядок сложнее java (надеюсь, не будешь спорить?). А поэтому да, с таким же комфортом. Однако этот комфорт ниже типичного в Яве. Особенно при наличии IDE.

Это уже скорее дело вкуса (ну или квалификации)... Для кого-то чем проще, тем комфортнее, а для другого чем больше возможностей, тем комфортнее. )

_>>Я говорю не про теорию, а про практику. В теории компиляторы могли создавать отличный ассемблерный код и 30 лет назад — ничего этому не мешало. Однако на практике они достигли уровня, сравнимого с человеком, только лет 5-10 назад. Так вот в области автоматической оптимизации типов и т.п. на практике нет пока почти ничего реально работающего. Может лет 10-20 и появится что-то существенное, но пока такого нет.

·>А вот теперь представь, что этим компиляторам дают не только исходный код, но и статистику реального выполнения программы с реальными данными.

Такое тоже уже давным давно используется в мире C++ https://blog.mozilla.org/tglek/2010/04/12/squeezing-every-last-bit-of-performance-out-of-the-linux-toolchain/ и иногда действительно даёт неплохие результаты. Но тут дело совершенно не в этом. Вопрос не в инструментах, а в задаче. Проблема выбора оптимальные контейнеров и алгоритмов не идёт ни в какое сравнение с проблемой оптимизации ассемблерного кода под современные процессоры. И то с последней сколько лет возились...
Re[109]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 21:15
Оценка: :))
Здравствуйте, Serginio1, Вы писали:

S>>>Так зачем этот зоопарк если можно без него? Проще использовать оди Com компонент который загружает сборки.

_>>Т.е. DirectX тоже перепишем под .net и будем запускать через обёртку? )))
S> Если надо то нет проблем http://habrahabr.ru/post/142025/



S>>>А я говорю, что у каждого языка есть своя ниша. Свои достоинства и недостатки.

_>>А тут кто-то с этим спорит? )
S> Пока вы все говорите, то что делается на C# легко реализуется на C# и с лучшей скоростью. Я привожу примеры, что это не так.

Да, большая часть задач, решаемых на C#, может быть решена на C++ проще и с лучше скоростью. Но это не значит, что у C# нет своей ниши, потому что предыдущее утверждение делалось в расчёте на экспертные знания в каждом языке. Если же брать специалистов более низкого уровня, то ситуация становится совсем другой. Собственно на этом Java/C# и живут.
Re[105]: Java vs C# vs C++
От: alex_public  
Дата: 13.10.15 21:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Можно проще — .Net рулит для бизнеса.

I>>>C++ — всего лишь для некоторой части инфраструктуры.
_>>Ну т.е. всякие там гуглы, яндексы или вообще варгейминги — это не бизнесы? )))
I>Бизнесы. Инфраструктура в них пишется на плюсах. Бизнес-специфика — в основном на менеджед решениях. Драйвер — инфраструктура. База данных — инфраструктура. Как то так.

Что-то понятие "основной продукт компании" не укладывается ни в понятие "инфраструктура", ни в "бизнес-специфику" (для данных компаний)... )
Re[106]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.10.15 05:36
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Бизнесы. Инфраструктура в них пишется на плюсах. Бизнес-специфика — в основном на менеджед решениях. Драйвер — инфраструктура. База данных — инфраструктура. Как то так.


_>Что-то понятие "основной продукт компании" не укладывается ни в понятие "инфраструктура", ни в "бизнес-специфику" (для данных компаний)... )


Именно. Потому как слово продукт слишком общее, потому и надо уточнять
Пример 1. Основной продукт — инфраструктура.
Пример 2. Основной продукт — бизнес-решения.
Пример 3. Основной продукт — сыр 'Беловежский'.

Бизнес-решения == инструменты для конкретного бизнеса, как правило автоматизация.
Вопрос — чего ты драйвером в видеокарте автоматизируешь ?

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

Что касается яндекса и гугла — все примерно так же. Драйвера, числодробилки, и прочая инфраструктура — С++. Остальное Джава, Питон и тд.
Re[118]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.10.15 09:18
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Зачем если есть обычный Python?

S>>>>немерле.
EP>>>Речь-то про C# vs Python. Nemerle — это другой разговор.
S>> А то, что если мне вдруг не будет хватать C# я легко могу сделать сборку на любом нетовском языке

EP>А я вообще возьму любой язык


S>>>>Ну дык сделай на питоне эту задачу. Все ведь элементарно.

EP>>>Интерпретатор уже готовый, тратить время на оборачивание его в какое-то API, привязанное к одной конкретной платформе — мне не интересно.
S>> Ну вот начинается. А у меня все сделане для любой нетовской сборке и написано за 15 минут.

EP>Вот практически готовый пример.


Воо уже более интересно. У питона есть информация о типе. Только несколько замечаний
Есть ref и out параметры которые тоже нужно оборачивать как и результат функции.
Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.
Еще бы и реализацию ITypeInfo, но это уже незачем.
и солнце б утром не вставало, когда бы не было меня
Re[38]: Java vs C# vs C++
От: · Великобритания  
Дата: 14.10.15 12:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>>>Джава в роли догоняющего.

I>>>·>Примерно как С++ догоняет Кобол.
I>>>Кобол в HFT ? Пудозреваю, исключительно за счет С++.
I>·>В finance.
I>HFT это уже не финансы ?
финансы это не только HFT.

I>>>Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`.

I>>>Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд.
I>·>Ага... А если ты заюзаешь чужую либу, а она там malloc делает и все кастомные аллокаторы фтопку.
I>В С++ аллокация кастомизируется
I>1 Многие либы поддерживают аллокаторы
То же и с java — если либа поддерживает расширение, то хорошо, если не поддерживает, то плохо.

I>2 можно дефолтный аллокатор соптимизировать под нужные сценарии

I>Это конечно трудная техника, но возможная. Что взамен в джаве, кастомный GC ?
Другая либа, обычно
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Java vs C# vs C++
От: · Великобритания  
Дата: 14.10.15 13:55
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>Да пусть доказывает, он железный, зарплату не просит.

EP>>>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей.
dot>>Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.
EP>На C++ зачем это доказывать? Мы же про EA говорим.
Чтобы писать надёжные программы.

EP>>>Оно бы грохнулось в тот же самый момент и без EA.

dot>>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
EP>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен. Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.

dot>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.

EP>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
Ты принимаешь решение в compile time — какой размер считать small.

dot>>Разница может быть заметна, если у тебя этот vector возвращается по значению из функции и его размер большой, что передачу by-value сделает неэффективой. А значит ты должен будешь его в unique_ptr обернуть или надеяться на RVO.

EP>Сейчас есть гарантия: в худшем случае что случится в описанном варианте это move, то есть никакой unique_ptr тут не нужен, также как и во многих других случаях.
Вот это и неудобно. Чуток хочешь переписать код и приходится приседать с тем что как возвращается и кто чем владеет. Даже простые рефакторинги типа extract method становятся нетривиальными.

EP>Да и RVO/NRVO прекрасно работает даже на старых MSVC.

Но код нужно писать определённым способом, чтобы этот RVO был возможен.

dot>>>>А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.

EP>>>У него тоже ничего не поломается. Даже если бы это был просто vector<T>, без unique_ptr — то тоже ничего бы не поломалось
dot>>Это если голые указатели не использовать.
EP>Так я же говорю, их можно использовать когда нет владения. При передачи владения нужно это кодировать в типах.
Владение есть всегда.

EP>>>Это очевидный недостаток. Например есть текст, нужно передать куда-то отдельный абзац — на C++ достаточно например либо двух указателей, либо указателя и числа символов, либо просто указателя на начало абзаца. На Java же придётся ещё таскать ссылку на сам текст.

dot>>В общем да, есть такое. Хотя далеко не факт, что это может стать какой-либо проблемой... В типичном приложении у тебя скорее всего будет ссылка на какой-нибудь Document, по которому можно найти его текст. Поэтому будет достаточно пары индексов. А в большинстве случаев помещение двух или трёх чисел на стек — погоды не делает.
EP>На стеке да, а вот например если нужно хранить массив абзацев из разных документов — то уже будет существенная разница.
Уу... тогда ты в полный рост нарвёшься на проблемы с владением, временем жизни разных документов, что скорее всего выльется в массив который так же будет включать ссылки на документы.
А если очень надо такое соорудить в java, то можешь сделать индексы с уникальными оффсетами для каждого документа (по сути аналог указателей в единый массив адресов, как в С++).

dot>>>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).

EP>>>Меняет — поиск и удаление константы в худшем случае.
dot>>А добавление?
EP>С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
В точности то же и с gc.

dot>>>>Комбинации чего?

EP>>>Структура данных * контейнер * алгоритм * etc. ЕМНИП даже в C# для разных структур generic даёт разные воплощения.
dot>>Круто, конечно. Но в горячем коде таких комбинаций обычно единицы. А остальному коду это всё не важно.
EP>У меня как раз в "горячем" коде их очень много.
Ок. Возможно у тебя такая специфика кода.

EP>>>Очень много, это практика, реальный код.

EP>>>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.
dot>>Не факт, что это принесёт хоть какую-то пользу. compile time же.
EP>В смысле?
JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.

EP>>>1. Если малое — то уж точно не нужна, тут разногласия нет.

EP>>>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме
EP>>>3. Ключ может хранится отдельно от значения, причём без индерекции.
dot>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.
EP>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.

dot>>>>Если значение маленькое, то это скорее всего будет примитив.

EP>>>С чего бы это?
dot>>Потому что примитив это те же 8 байт, что уже не так уж мало.
EP>На C++ там где удобно без проблем оборачиваю даже одно значение примитивного типа в класс
Да, система типов и шаблоны в С++ — мощнее, аж Turing complete.

dot>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.

EP>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
Это как? Кастомные аллокаторы что-ли?

dot>>>>Ну и кому эти микробенчмарки нужны?

EP>>>Тем кого интересует скорость
dot>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.
EP>Так говоришь как будто быстрое означает не полезное.
Я говорю, что быстрое не означает полезное.

dot>>>>Ты давай пример системы на плюсах, компилированных под jvm.

EP>>>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.
dot>>Потому и не знаешь, что принципиально невозможно.
EP>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
Возможно, но практически — бесполезно. JS — однопоточный.

dot>>>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.

EP>>>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.
dot>>Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.
EP>1. В том тесте вообще GC остался за бортом, его действия не замеряли. Замеряли только обход массива с простой операцией.
EP>2. Причём тут вообще JS GC? В случае C++ -> JS — там практически все данные находятся в одном большом буфере.
Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.
Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: Java vs C# vs C++
От: · Великобритания  
Дата: 14.10.15 14:39
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.

EP>>>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
dot>>"new int[1<<30]" тоже за одну.
EP>Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
В итоге что тут получится — простенькая формула как по индексу массива и положению вычислить индекс внутри int[1 << 30]. Уж чего-чего, но без этого можно прожить.

EP>>>Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.

dot>>Вот и считай, вместо кода специального аллокатора ты просто пишешь сразу GC-free код. Без лишних уровней абстракции.
EP>Ещё раз — в одном случае отличие от дефолта это несколько параметров, в другом изменение всего кода. Разница кардинальная.
EP>Поэтому аргументы типа "ну и что что весь код GC-free, зато у вас несколько параметров меняются" — несостоятельны.
"весь код" — это как-то пессимистично. На практике получаются гораздо более локальные рефакторинги.

EP>>>Сам же понимаешь что это передёргивание.

EP>>>Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры.
EP>>>Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде.
EP>>>Причём SoA требуются на порядки реже чем обычные структуры.
dot>>Да и оптимизация обычных структрур требуется на порядки реже.
EP>Реже чем что? Чем смирение с тормозами, повышенным энергопотреблением и т.п.?
Да нет особых тормозов. Ты, как приплюснутый, знаешь "как правильно писать на С++, чтобы не нарваься на битый указатель", а я, как жабнутый, "как правильно писать на Java чтобы gc не тормозил". Вот и всё. Ни на каком языке невозможно писать как в голову взбредёт и получать код, который работает хорошо.

EP>>>Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет

dot>>Для DOM/js афаир, но не для всего кода. Т.е. создать собираемую песочницу можно, но не "пишем на С++ с мусоросборщиком".
EP>Там это используется для interop JS (DOM?) <-> C++ — то есть не просто внутри JS.
Т.е. используется только для определённого вида объектов, с которыми без gc вообще не справиться.

dot>>>>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода.

EP>>>Действительно, подумаешь код не работает.
EP>>>Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?
dot>>Тестами, без всяких valgrind.
EP>Так в C++ будут и тесты и valgrind/etc. Об этом и речь, готовых инструментов на Java видимо нет, значит трата ещё дополнительных ресурсов.
off-heap объекты в довльно маленькой песочнице. Кода там порядка тысячи строк, что совсем мало для явы. И меняется этот код редко, ибо бизнес-логику не содержит.

EP>>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.

dot>>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
EP>Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
Остаётся как минимум простота поддержки и разработки, скорость внесения изменений без страха что-то нечаянно поломать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[42]: Java vs C# vs C++
От: · Великобритания  
Дата: 14.10.15 15:02
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>> (в отличие от Жабки, где это без проблем):

_>·>И чем это отличается от Жабки-то?
_>Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.
Ты что-то фигню говоришь полную. Может что-то из давнего прошлого помнишь просто? Такое уж как минимум 6 лет неактуально.
Специально сейчас посчитал. В проекте 965 вхождений " = null" на ~2 миллиона строк. Притом большая часть из них вида
Some x = null;
if(...)
{
  x = ...;
}
use(x);

или
if(...)
{
...
   this.currentActiveSomething = ...;
...
}
else
{
...
   this.currentActiveSomething = null;
...
}

Т.е. конструкция такая используется, конечно, но никак к gc не относится.

_>>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.

_>·>Зависит. Если один человек напишет код и не будет сильно трогать после, то одно, а другое если у тебя проект с десяктами девов, продолжительностью в несколько лет, с релизами каждые две недели, то это совершенно другие правила игры.
_>·>Дело не в delete, а в &-ссылках или *-указателях.
_>Это только если разработка абсолютно бесконтрольная.
Или если в проекте используются сторонние библиотеки.

_>Если же в команде установлены хотя бы минимальные правила, то подобных проблем точно не будет, вне зависимости от размера команды. Если говорить о конкретном вопросе, то для его решения достаточно пары простейших правил:

_>- использование контейнеров stl (если конечно не требуется чего-то специфического)
_>- следование какой-то известной архитектуре организации многопоточности (например мне нравится модель акторов).
Архитектура многопоточности в первую очередь зависит от решаемых задач, а не личных предпочтений.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[40]: Java vs C# vs C++
От: · Великобритания  
Дата: 14.10.15 15:15
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.

_>·>Различного вида буферы, кеши, пулы — это оно. Они никому не интересны??!
_>Не интересно время их выделения/уничтожения, потому как сам же говоришь, что это происходит редко.
Редко, но метко. А есть ещё сами объекты в кешах — приходят, уходят.
Контролировать их время жизни явно — сущий ужас.

_>>>Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).

_>·>Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.
_>Не очень понятно. Эти самые потоки "Б, В, Г, и, иногда Д" должны получить изначальную версию объекта, обработанную версию объекта, или обе? )
Да
В Яве-то без разницы...

_>>>Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))

_>·>Если уж по правде говорить, то С++ синтаксис на порядок сложнее java (надеюсь, не будешь спорить?). А поэтому да, с таким же комфортом. Однако этот комфорт ниже типичного в Яве. Особенно при наличии IDE.
_>Это уже скорее дело вкуса (ну или квалификации)... Для кого-то чем проще, тем комфортнее, а для другого чем больше возможностей, тем комфортнее. )
Зачем возможности, если можно проще? Оккам — бог, и бритва — пророк его. Усложнять — просто. Упрощать — сложно.

_>·>А вот теперь представь, что этим компиляторам дают не только исходный код, но и статистику реального выполнения программы с реальными данными.

_>Такое тоже уже давным давно используется в мире C++ https://blog.mozilla.org/tglek/2010/04/12/squeezing-every-last-bit-of-performance-out-of-the-linux-toolchain/ и иногда действительно даёт неплохие результаты. Но тут дело совершенно не в этом. Вопрос не в инструментах, а в задаче. Проблема выбора оптимальные контейнеров и алгоритмов не идёт ни в какое сравнение с проблемой оптимизации ассемблерного кода под современные процессоры. И то с последней сколько лет возились...
PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[119]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 14.10.15 16:00
Оценка:
Здравствуйте, Serginio1, Вы писали:

EP>>Вот практически готовый пример.

S> Воо уже более интересно. У питона есть информация о типе.

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

S>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.


Не проблема — импортировать модуль можно по строковому имени в любом месте.
Re[33]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 14.10.15 16:43
Оценка:
Здравствуйте, ·, Вы писали:

dot>>>>>Да пусть доказывает, он железный, зарплату не просит.

EP>>>>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей.
dot>>>Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.
EP>>На C++ зачем это доказывать? Мы же про EA говорим.
dot>Чтобы писать надёжные программы.

Вот здесь есть escape, при этом сам объект типа vector передаётся по стеку.
auto foo()
{
    vector<Widget> xs;
    // ...
    return xs;
}
То есть та оптимизация которую делает EA есть даже при escape.

EP>>>>Оно бы грохнулось в тот же самый момент и без EA.

dot>>>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
EP>>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
dot>С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен.

Возможен, я делал. Но это опять соскакивание с темы.

dot>Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.


Это понятно. Речь про размещение в куче, например большого массива, и вот для некоторых типов куч имеет смысл ставить условный delete как можно раньше (что может сделать EA).

dot>>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.

EP>>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
dot>Ты принимаешь решение в compile time — какой размер считать small.

Да, и этот размер обычно очевиден для конкретной задачи.

EP>>Да и RVO/NRVO прекрасно работает даже на старых MSVC.

dot>Но код нужно писать определённым способом, чтобы этот RVO был возможен.

Если он вдруг по какой-то причине невозможен — будет гарантированное перемещение.

dot>>>>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).

EP>>>>Меняет — поиск и удаление константы в худшем случае.
dot>>>А добавление?
EP>>С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
dot>В точности то же и с gc.

Решили? Для хеш-таблиц-то есть легкодоступные альтернативы.

EP>>>>Очень много, это практика, реальный код.

EP>>>>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.
dot>>>Не факт, что это принесёт хоть какую-то пользу. compile time же.
EP>>В смысле?
dot>JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.

1. JIT ограничен по времени — не все оптимизации доступны. Его задача в том числе работать быстро.
2. JIT не превращает массив указателей на классы в массив структур — а именно про такие данные идёт речь.
3. В данном случае информации не больше.

EP>>>>1. Если малое — то уж точно не нужна, тут разногласия нет.

EP>>>>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме
EP>>>>3. Ключ может хранится отдельно от значения, причём без индерекции.
dot>>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.
EP>>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
dot>Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.

Вообще-то здесь про хеш-таблицу, а не сканирование массива.

dot>>>>>Если значение маленькое, то это скорее всего будет примитив.

EP>>>>С чего бы это?
dot>>>Потому что примитив это те же 8 байт, что уже не так уж мало.
EP>>На C++ там где удобно без проблем оборачиваю даже одно значение примитивного типа в класс
dot>Да, система типов и шаблоны в С++ — мощнее, аж Turing complete.

Не в этом дело. Это работает даже без шаблонов. Дело в том что это бесплатно, либо практически бесплатно.

dot>>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.

EP>>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
dot>Это как? Кастомные аллокаторы что-ли?

Да, как один из вариантов.

dot>>>>>Ну и кому эти микробенчмарки нужны?

EP>>>>Тем кого интересует скорость
dot>>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.
EP>>Так говоришь как будто быстрое означает не полезное.
dot>Я говорю, что быстрое не означает полезное.

Оно не означает ни "полезное", ни "не полезное". Ты же явно противопоставляешь полезное быстрому "что-то полезное делало, а не быстрое".

dot>>>>>Ты давай пример системы на плюсах, компилированных под jvm.

EP>>>>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.
dot>>>Потому и не знаешь, что принципиально невозможно.
EP>>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
dot>Возможно, но практически — бесполезно. JS — однопоточный.

И что из этого следует? Нельзя сделать многопоточно на Java?
По теме: https://groups.google.com/forum/#!topic/emscripten-discuss/gQQRjajQ6iY

dot>>>>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.

EP>>>>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.
dot>>>Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.
EP>>1. В том тесте вообще GC остался за бортом, его действия не замеряли. Замеряли только обход массива с простой операцией.
EP>>2. Причём тут вообще JS GC? В случае C++ -> JS — там практически все данные находятся в одном большом буфере.
dot>Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.
dot>Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.

Практический смысл в том, что можно будет писать быстрый код на высоком уровне, и легко портировать готовый код.
Re[37]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 14.10.15 16:58
Оценка:
Здравствуйте, ·, Вы писали:

EP>>>>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.

EP>>>>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
dot>>>"new int[1<<30]" тоже за одну.
EP>>Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
dot>В итоге что тут получится — простенькая формула как по индексу массива и положению вычислить индекс внутри int[1 << 30].

1. Перед этим придётся вручную выпрямить иерархию агрегирования.
2. Данные могут быть разных типов — придётся брать сырой буфер.
3. Нельзя использовать стандартные готовые алгоритмы — придётся писать новые.

EP>>>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.

dot>>>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
EP>>Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
dot>Остаётся как минимум простота поддержки и разработки,

Есть же более гибкие/удобные и при этом достаточно не сильно сложные языки. Тот же C#.

dot>скорость внесения изменений без страха что-то нечаянно поломать.


Чем это достигается? И почему думаешь что этого нет в других управляемых, но более гибких языках?
Re[120]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.10.15 17:23
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


EP>>>Вот практически готовый пример.

S>> Воо уже более интересно. У питона есть информация о типе.

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


S>>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.


EP>Не проблема — импортировать модуль можно по строковому имени в любом месте.

Как это сделать из 1С?
и солнце б утром не вставало, когда бы не было меня
Re[121]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 14.10.15 17:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.

EP>>Не проблема — импортировать модуль можно по строковому имени в любом месте.
S> Как это сделать из 1С?

Вызывать Python функцию которая импортирует модуль по заданному строковому имени.
Re[43]: Java vs C# vs C++
От: alex_public  
Дата: 14.10.15 20:23
Оценка:
Здравствуйте, ·, Вы писали:

_>>Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.

·>Ты что-то фигню говоришь полную. Может что-то из давнего прошлого помнишь просто? Такое уж как минимум 6 лет неактуально.
·>Специально сейчас посчитал. В проекте 965 вхождений " = null" на ~2 миллиона строк.

Ну вот ты наконец то увидел аналог ситуации в C++. В старых проектах или у заставших в древности авторов ещё можно найти множественные delete, а в нормальных проектах такого не увидишь.
Re[41]: Java vs C# vs C++
От: alex_public  
Дата: 14.10.15 20:34
Оценка:
Здравствуйте, ·, Вы писали:

_>>·>Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.

_>>Не очень понятно. Эти самые потоки "Б, В, Г, и, иногда Д" должны получить изначальную версию объекта, обработанную версию объекта, или обе? )
·>Да
·>В Яве-то без разницы...

Ага, без разницы) И при этом работает с кучей тормозов и блокировок. )))

_>>Это уже скорее дело вкуса (ну или квалификации)... Для кого-то чем проще, тем комфортнее, а для другого чем больше возможностей, тем комфортнее. )

·>Зачем возможности, если можно проще? Оккам — бог, и бритва — пророк его. Усложнять — просто. Упрощать — сложно.

Это верно, но при одном условие — отсутствие потери возможностей. Если же упрощение достигается путём сокращения возможностей, то его ценность уже далеко не так однозначна.

·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.


Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода конкретного алгоритма и конкретных типов (в существование такого у меня нет сомнений) и некую оптимизацию, выбирающую алгоритмы и типы данных (существование подобных эффективных оптимизаторов — это миф).
Re[122]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.10.15 10:57
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

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


S>>>>Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.

EP>>>Не проблема — импортировать модуль можно по строковому имени в любом месте.
S>> Как это сделать из 1С?

EP>Вызывать Python функцию которая импортирует модуль по заданному строковому имени.

Ну я же не знаток Питона. То есть как реализовать следющее

Врапер=Новый ComОбъект(ПрогИДВрайпераПитона);
Врапер.ЗагрузитьСборку(ФайлГдеНаходитсяОписаниеНужногоКласса);
Объект=Врапер.СоздатьОбъект(СтроковоеИмяОбъектаНужногоКласса);
и солнце б утром не вставало, когда бы не было меня
Re[42]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.15 11:20
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.


_>Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода


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

...а у «Танков» внутри — в основном Python.


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

"если хоть одна функция написана на С++... " @alex_public
Re[43]: Java vs C# vs C++
От: alex_public  
Дата: 15.10.15 12:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.

_>>Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода
I>Не надо путать архитектуру с низкоуровневыми оптимизациями.

Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))

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

I>

I>...а у «Танков» внутри — в основном Python.

I>Если ты не в курсе, то танки варгейминга это нынче один из лучших примеров, как менеджед решение отлично справляется с конской нагрузкой.
I>"если хоть одна функция написана на С++... " @alex_public

Ты похоже бредишь) Я уже много раз (в том числе и в этой темке) высказывал своё полное одобрение использованием схемы со встроенным в C++ приложение Питоном (или другим скриптовым языком) для сложных проектов.
Re[44]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.15 12:35
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Не надо путать архитектуру с низкоуровневыми оптимизациями.


_>Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))


Удивляюсь, как ты ухитряешь прочесть написаное.

I>>"если хоть одна функция написана на С++... " @alex_public


_>Ты похоже бредишь) Я уже много раз (в том числе и в этой темке) высказывал своё полное одобрение использованием схемы со встроенным в C++ приложение Питоном (или другим скриптовым языком) для сложных проектов.


Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?
Re[45]: Java vs C# vs C++
От: alex_public  
Дата: 15.10.15 12:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>Ты похоже бредишь) Я уже много раз (в том числе и в этой темке) высказывал своё полное одобрение использованием схемы со встроенным в C++ приложение Питоном (или другим скриптовым языком) для сложных проектов.

I>Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?

В танчиках то? ) Так они у меня установлены... )))
Re[46]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.15 13:42
Оценка:
Здравствуйте, alex_public, Вы писали:

I>>Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?


_>В танчиках то? ) Так они у меня установлены... )))


Типа ты не понял, что речь про серверный софт
Re[34]: Java vs C# vs C++
От: · Великобритания  
Дата: 15.10.15 13:47
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Вот здесь есть escape, при этом сам объект типа vector передаётся по стеку.

А что такого в этом векторе? Он же маленький, соответствует 4 или 8 байтной ссылке в Яве. Самое интересное это то, на что он указывает в куче.

EP>
EP>auto foo()
EP>{
EP>    vector<Widget> xs;
EP>    // ...
EP>    return xs;
EP>}
EP>
То есть та оптимизация которую делает EA есть даже при escape.

EA работает не на уровне одного метода, а для довольно большого куска кода, притом даже если у тебя методы виртуальные (что для C++ компиляторов очень неприятное обстоятельство).

dot>>>>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.

EP>>>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
dot>>С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен.
EP>Возможен, я делал. Но это опять соскакивание с темы.
Но как? Или опять оборачиванием указателей в специальную песочницу типа как gc_root?

dot>>Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.

EP>Это понятно. Речь про размещение в куче, например большого массива, и вот для некоторых типов куч имеет смысл ставить условный delete как можно раньше (что может сделать EA).
В яве — не имеет смысла что-то ставить.

dot>>>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.

EP>>>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
dot>>Ты принимаешь решение в compile time — какой размер считать small.
EP>Да, и этот размер обычно очевиден для конкретной задачи.
не факт, размер может варьироваться от реальных условий. И всякие стандартные vector это, вроде не умеют.

dot>>>>А добавление?

EP>>>С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
dot>>В точности то же и с gc.
EP>Решили? Для хеш-таблиц-то есть легкодоступные альтернативы.


dot>>>>Не факт, что это принесёт хоть какую-то пользу. compile time же.

EP>>>В смысле?
dot>>JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.
EP>1. JIT ограничен по времени — не все оптимизации доступны. Его задача в том числе работать быстро.
Это практически миф, особенно для долгоиграющих серверов. JIT не оптимизирует весь код, а только самый горячий, в отличие от обычного compile time оптимизатора или даже PGO, который старается оптимизировать абсолютно всё, даже куски которые в реальности может быть и не будут выполнены вообще. И времени на долгоиграющем сервере ему предостаточно.

EP>2. JIT не превращает массив указателей на классы в массив структур — а именно про такие данные идёт речь.

Собственно у меня есть сомнения по поводу ценности такого превращения. Ценным может быть превращение в структуру массивов (а такое и С++ не умеет), либо компактификация кучи (чем занимается gc).

EP>3. В данном случае информации не больше.

jit может принести пользу, если перенесёт массив объектов на стек.

dot>>>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.

EP>>>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
dot>>Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.
EP>Вообще-то здесь про хеш-таблицу, а не сканирование массива.
Даже и хеш-таблица — всё равно. Два случая
— массив хеш-таблицы поместился в кеш и значения маленькие, лежат в самом массиве.
— массив хеш-таблицы поместился к кеш лишь потому, что значения лежат по ссылкам, т.е. индирекция используется.
И собственно и то и другое аналогично делается и в С++ и в Яве.

dot>>>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.

EP>>>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>>>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
dot>>Это как? Кастомные аллокаторы что-ли?
EP>Да, как один из вариантов.
Ну собственно не сильно отличается от Явы, там кастомное расположение данных в массиве.

dot>>>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.

EP>>>Так говоришь как будто быстрое означает не полезное.
dot>>Я говорю, что быстрое не означает полезное.
EP>Оно не означает ни "полезное", ни "не полезное". Ты же явно противопоставляешь полезное быстрому "что-то полезное делало, а не быстрое".
Компиляция C++ -> JVM или JS не полезное, пусть хоть и быстрое.

dot>>>>Потому и не знаешь, что принципиально невозможно.

EP>>>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
dot>>Возможно, но практически — бесполезно. JS — однопоточный.
EP>И что из этого следует? Нельзя сделать многопоточно на Java?
Можно, но думаю получится медленно, либо с ограничениями.

EP>По теме: https://groups.google.com/forum/#!topic/emscripten-discuss/gQQRjajQ6iY

Поживём, увидим. А пока это лишь PoC.

dot>>Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.

dot>>Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.
EP>Практический смысл в том, что можно будет писать быстрый код на высоком уровне, и легко портировать готовый код.
Может быть и можно будет. А пока — облом.
Хотя я не верю что можно будет с таким дизайном языка как в C++. Может что-то в духе C++/CLI прокатит...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: Java vs C# vs C++
От: · Великобритания  
Дата: 15.10.15 14:09
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

dot>>>>"new int[1<<30]" тоже за одну.

EP>>>Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
dot>>В итоге что тут получится — простенькая формула как по индексу массива и положению вычислить индекс внутри int[1 << 30].
EP>1. Перед этим придётся вручную выпрямить иерархию агрегирования.
EP>2. Данные могут быть разных типов — придётся брать сырой буфер.
EP>3. Нельзя использовать стандартные готовые алгоритмы — придётся писать новые.
Часто это всё не является проблемами. Но в общем случае, конечно, да.

EP>>>>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.

dot>>>>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
EP>>>Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже Что остаётся-то? Legacy и общая инертность?
dot>>Остаётся как минимум простота поддержки и разработки,

EP>Есть же более гибкие/удобные и при этом достаточно не сильно сложные языки. Тот же C#.

Ну давай примеры C# в LL.

dot>>скорость внесения изменений без страха что-то нечаянно поломать.

EP>Чем это достигается? И почему думаешь что этого нет в других управляемых, но более гибких языках?
В .net особо не видно. А в jvm есть и другие языки, да.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[44]: Java vs C# vs C++
От: · Великобритания  
Дата: 15.10.15 14:12
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.

_>·>Ты что-то фигню говоришь полную. Может что-то из давнего прошлого помнишь просто? Такое уж как минимум 6 лет неактуально.
_>·>Специально сейчас посчитал. В проекте 965 вхождений " = null" на ~2 миллиона строк.
_>Ну вот ты наконец то увидел аналог ситуации в C++. В старых проектах или у заставших в древности авторов ещё можно найти множественные delete, а в нормальных проектах такого не увидишь.
Да и x=null особо в Яве никогда не было. Я никогда в реальном коде такого не видел, даже в старом. Превратилось из баек в миф.
Зато в С++ можно найти ptr.reset() и всякие извращения с владением, и */&-указатели, и битые указатели, и утечки из-за циклических зависимостей...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[44]: Java vs C# vs C++
От: · Великобритания  
Дата: 15.10.15 14:16
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>·>PGO я уже упоминал... Но PGO таки уступает по возможностям JIT. Может быть польза для определённого вида программ — типа коробочных UI. Т.е. что-то что запускается у пользователей. А вот на серверах, которые работают днями|неделями — JIT незаменим.

_>>>Ещё раз: не надо путать оптимизацию генерирования ассемблерного кода
I>>Не надо путать архитектуру с низкоуровневыми оптимизациями.
_>Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))
Ты, как плюсовик, считаешь частью архитектуры разные комбинации _ptr, [], &, *. В яве это частью архитектуры не является. Всё выражается одним абстрактным понятием — ссылка. А как оно будет в итоге расположено — JIT умеет не лету корректировать для лучшей производительности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[47]: Java vs C# vs C++
От: alex_public  
Дата: 15.10.15 18:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Кто тебе сказал, что там питон встроен в нативное приложение ? Откуда догадки ?

_>>В танчиках то? ) Так они у меня установлены... )))
I>Типа ты не понял, что речь про серверный софт

Вроде бы же речь шла о сочетание C++ + Python, а это как раз устройство их клиента. Что касается сервера, то там у них вообще адская мешанина включая не только C++ и Python, но и Ruby и ещё чёрт знает что.)))
Re[45]: Java vs C# vs C++
От: alex_public  
Дата: 15.10.15 19:00
Оценка:
Здравствуйте, ·, Вы писали:

I>>>Не надо путать архитектуру с низкоуровневыми оптимизациями.

_>>Так а кто тут путает то? ) Это вот тут товарищи заявляют, что JIT в JVM умеет на лету сам корректировать архитектуру для лучшей производительности. А я высказываю свои сомнения в этом. )))
·>Ты, как плюсовик, считаешь частью архитектуры разные комбинации _ptr, [], &, *. В яве это частью архитектуры не является. Всё выражается одним абстрактным понятием — ссылка. А как оно будет в итоге расположено — JIT умеет не лету корректировать для лучшей производительности.

Всё верно. Только я как раз выражаю свои сомнения в способности современного оптимизатора сделать это лучше человека. На самом деле аналогичная ситуация была и с ручным ассемблерным кодом vs C/C++ оптимизаторы лет 20 назад. Тогда нормальный спец. по ассемблеру легко писал код эффективнее C++ компилятора. Сейчас же это почти не реально. Так вот выше обсуждаемый оптимизатор в Java в данный момент не способен создавать ничего сравнимого с человеком. Теоретически когда-нибудь может и сможет, но я сомневаюсь, что это случится в ближайшем будущем. Потому как слишком сложная и неформализованная задача.
Re[48]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.15 19:10
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>В танчиках то? ) Так они у меня установлены... )))

I>>Типа ты не понял, что речь про серверный софт

_>Вроде бы же речь шла о сочетание C++ + Python


Речь шла про сервер.
Re[46]: Java vs C# vs C++
От: · Великобритания  
Дата: 15.10.15 19:14
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Ты, как плюсовик, считаешь частью архитектуры разные комбинации _ptr, [], &, *. В яве это частью архитектуры не является. Всё выражается одним абстрактным понятием — ссылка. А как оно будет в итоге расположено — JIT умеет не лету корректировать для лучшей производительности.

_>Всё верно. Только я как раз выражаю свои сомнения в способности современного оптимизатора сделать это лучше человека. На самом деле аналогичная ситуация была и с ручным ассемблерным кодом vs C/C++ оптимизаторы лет 20 назад. Тогда нормальный спец. по ассемблеру легко писал код эффективнее C++ компилятора. Сейчас же это почти не реально. Так вот выше обсуждаемый оптимизатор в Java в данный момент не способен создавать ничего сравнимого с человеком. Теоретически когда-нибудь может и сможет, но я сомневаюсь, что это случится в ближайшем будущем. Потому как слишком сложная и неформализованная задача.
Собственно почему java успешна в LL, это потому что оптимизатор способен создавать достаточно хороший код в большинстве случаев, а в тех местах, где это недостаточно — позволяет применять приёмы и приближая скорость к ручной оптимизации, при этом оставляя преимущества управляемой платформы.
Т.е. это очень удачный компромисс между скоростью и безопасностью.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[49]: Java vs C# vs C++
От: alex_public  
Дата: 15.10.15 19:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>>>В танчиках то? ) Так они у меня установлены... )))

I>>>Типа ты не понял, что речь про серверный софт
_>>Вроде бы же речь шла о сочетание C++ + Python
I>Речь шла про сервер.

Что-то не припомню такого ограничения в нашей дискуссии.
Re[47]: Java vs C# vs C++
От: alex_public  
Дата: 15.10.15 19:42
Оценка:
Здравствуйте, ·, Вы писали:

_>>Всё верно. Только я как раз выражаю свои сомнения в способности современного оптимизатора сделать это лучше человека. На самом деле аналогичная ситуация была и с ручным ассемблерным кодом vs C/C++ оптимизаторы лет 20 назад. Тогда нормальный спец. по ассемблеру легко писал код эффективнее C++ компилятора. Сейчас же это почти не реально. Так вот выше обсуждаемый оптимизатор в Java в данный момент не способен создавать ничего сравнимого с человеком. Теоретически когда-нибудь может и сможет, но я сомневаюсь, что это случится в ближайшем будущем. Потому как слишком сложная и неформализованная задача.

·>Собственно почему java успешна в LL, это потому что оптимизатор способен создавать достаточно хороший код в большинстве случаев, а в тех местах, где это недостаточно — позволяет применять приёмы и приближая скорость к ручной оптимизации, при этом оставляя преимущества управляемой платформы.
·>Т.е. это очень удачный компромисс между скоростью и безопасностью.

Всё точно написано. Как раз неплохой компромисс. А вот при переходе с ассемблера на современный C++ никакого компромисса нет — одни преимущества. Если когда-нибудь подобное будет и с каким-то управляемым языком (в чём я крайне сомневаюсь в силу врождённых ограничений этого подхода), то возможно нативные языки будут отмирать (или останутся в каких-нибудь микроконтроллерах). Но пока они на оборот становятся более актуальными в связи с наступлением мобильной эпохи и остановкой роста производительности процессоров.
Re[35]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 16.10.15 00:43
Оценка:
Здравствуйте, ·, Вы писали:

EP>>Вот здесь есть escape, при этом сам объект типа vector передаётся по стеку.

dot>А что такого в этом векторе? Он же маленький, соответствует 4 или 8 байтной ссылке в Яве. Самое интересное это то, на что он указывает в куче.

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

EP>>
EP>>auto foo()
EP>>{
EP>>    vector<Widget> xs;
EP>>    // ...
EP>>    return xs;
EP>>}
EP>>
То есть та оптимизация которую делает EA есть даже при escape.

dot>EA работает не на уровне одного метода, а для довольно большого куска кода, притом даже если у тебя методы виртуальные (что для C++ компиляторов очень неприятное обстоятельство).

EA всё равно не сработает если будешь сохранять массив в какую-нибудь структуру.

EP>>>>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.

dot>>>С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен.
EP>>Возможен, я делал. Но это опять соскакивание с темы.
dot>Но как? Или опять оборачиванием указателей в специальную песочницу типа как gc_root?

Да.

dot>>>Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.

EP>>Это понятно. Речь про размещение в куче, например большого массива, и вот для некоторых типов куч имеет смысл ставить условный delete как можно раньше (что может сделать EA).
dot>В яве — не имеет смысла что-то ставить.

То есть там все кучи компактифицирующие? Нет ни одной похожей на обычную?

dot>>>>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.

EP>>>>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
dot>>>Ты принимаешь решение в compile time — какой размер считать small.
EP>>Да, и этот размер обычно очевиден для конкретной задачи.
dot>не факт, размер может варьироваться от реальных условий. И всякие стандартные vector это, вроде не умеют.

Есть готовые библиотечные. Например boost::container::small_vector или folly::small_vector.
Некоторые реализации std::string также используют этот приём.

dot>>>>>Не факт, что это принесёт хоть какую-то пользу. compile time же.

EP>>>>В смысле?
dot>>>JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.
EP>>1. JIT ограничен по времени — не все оптимизации доступны. Его задача в том числе работать быстро.
dot>Это практически миф, особенно для долгоиграющих серверов.

Почему? Например попалась конкретная комбинация циклических виртуальных вызовов — он её начинает оптимизировать, и если будет делать это долго, то в итоге может получиться дольше чем без попыток оптимизации, причём конкретные рамки он априори не знает.
Если же настраивать его под конкретные use-case'ы, то это становится уже очень близко к PGO.

dot>JIT не оптимизирует весь код, а только самый горячий,


У меня только на компиляцию самого горячего куска уходят минуты.

dot>в отличие от обычного compile time оптимизатора или даже PGO, который старается оптимизировать абсолютно всё, даже куски которые в реальности может быть и не будут выполнены вообще.


PGO как раз таки работает по собранной статистике на реальных use-cases'ах. То есть сначала статистика, потом оптимизация.

dot>И времени на долгоиграющем сервере ему предостаточно.


Значит тратится лишнее время на прогрев, плюс наверняка какие-нибудь растапливающие костыли.

EP>>2. JIT не превращает массив указателей на классы в массив структур — а именно про такие данные идёт речь.

dot>Собственно у меня есть сомнения по поводу ценности такого превращения.

Разница может быть на несколько порядков. Выше уже давал ссылку, на C# это дало замедление в ~80x.

dot>Ценным может быть превращение в структуру массивов


Не надо фантазировать. Да, превращение в структуру массивов иногда полезно, но требуется намного реже обычного массива структур.

dot>(а такое и С++ не умеет),


Умеет, я же сказал что это реализуется в библиотечном виде: описал набор полей, получил готовый SOA.

dot>>>>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.

EP>>>>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
dot>>>Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.
EP>>Вообще-то здесь про хеш-таблицу, а не сканирование массива.
dot>Даже и хеш-таблица — всё равно. Два случая
dot>- массив хеш-таблицы поместился в кеш и значения маленькие, лежат в самом массиве.
dot>- массив хеш-таблицы поместился к кеш лишь потому, что значения лежат по ссылкам, т.е. индирекция используется.
dot>И собственно и то и другое аналогично делается и в С++ и в Яве.

Я же уже объяснял Ещё раз, если у тебя ссылки лежат в кэше, а значения в куче, то тебе придётся делать как минимум две индерекции — одну по кэшу, а вторую по RAM — даже на happy-path.
Если же ссылки отдельно не хранятся, и вся таблица значений не умещается в кэш, то на happy-path будет только одна индерекция в сразу RAM.

dot>>>>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.

EP>>>>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>>>>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
dot>>>Это как? Кастомные аллокаторы что-ли?
EP>>Да, как один из вариантов.
dot>Ну собственно не сильно отличается от Явы, там кастомное расположение данных в массиве.

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

dot>>>>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.

EP>>>>Так говоришь как будто быстрое означает не полезное.
dot>>>Я говорю, что быстрое не означает полезное.
EP>>Оно не означает ни "полезное", ни "не полезное". Ты же явно противопоставляешь полезное быстрому "что-то полезное делало, а не быстрое".
dot>Компиляция C++ -> JVM или JS не полезное, пусть хоть и быстрое.

Полезное, используется в реальных проектах:
http://formit360.autodesk.com/blog/
https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos

dot>>>>>Потому и не знаешь, что принципиально невозможно.

EP>>>>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
dot>>>Возможно, но практически — бесполезно. JS — однопоточный.
EP>>И что из этого следует? Нельзя сделать многопоточно на Java?
dot>Можно, но думаю получится медленно, либо с ограничениями.

Почему? Какие предположения?

dot>>>Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.

dot>>>Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.
EP>>Практический смысл в том, что можно будет писать быстрый код на высоком уровне, и легко портировать готовый код.
dot>Может быть и можно будет. А пока — облом.

Уже используется в реальных проектах. Можешь сам пощупать: http://beta.unity3d.com/jonas/DT2/

dot>Хотя я не верю что можно будет с таким дизайном языка как в C++. Может что-то в духе C++/CLI прокатит...


Не верь
Re[50]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.15 07:37
Оценка:
Здравствуйте, alex_public, Вы писали:

_>>>Вроде бы же речь шла о сочетание C++ + Python

I>>Речь шла про сервер.

_>Что-то не припомню такого ограничения в нашей дискуссии.


Ну да, LL, т.е. low latency, о чем тебе постоянно напоминает . это просто слова и ничего не значат.
Re[51]: Java vs C# vs C++
От: alex_public  
Дата: 16.10.15 17:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

_>>>>Вроде бы же речь шла о сочетание C++ + Python

I>>>Речь шла про сервер.
_>>Что-то не припомню такого ограничения в нашей дискуссии.
I>Ну да, LL, т.е. low latency, о чем тебе постоянно напоминает . это просто слова и ничего не значат.

Вообще то тут речь шла уже не только о LL. Но даже если бы и говорить об этом, то у меня как раз встречается не серверная задачка из области LL. )))
Re[52]: Java vs C# vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.15 19:45
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Вообще то тут речь шла уже не только о LL. Но даже если бы и говорить об этом, то у меня как раз встречается не серверная задачка из области LL. )))


И твоя задачка докажет, что у варгейминга на серверах в основном с++ ?
Re[36]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 17.10.15 08:18
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:


EP>1. Про замыкание результаты в первом сообщении темы — ввод замыкания на C# дал десятикратное замедление и гигабайты аллокаций. На C++ результат идентичен ручному коду. Или ты хочешь сказать что C# без замыканий мог обогнать C++? — не, несерьёзно.

EP>2. По поводу замены структуры на класс — я уже ссылку приводил.

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

S>> Она как раз самая, что вероятная, особенно в серверных вариантах.

EP>Приведи статистику.


S>>Мало того, за кучей может следить GC в отдельном потоке.


EP>Точно — конкурентная гадость, которая скорей всего не lock-free.


Кстати самый простой вариант для увеличения эффективности GC это выделение памяти для объектов на стеке.
Для этого компилятор может помечать переменные которые используются только в этом методе.
Помечать входные параметры которые используются только в этом методе
Помечать результат метода если память выделяется только в этом методе.

Что мы получим.
1. Для конструктора объекта может передаваться менеджер памяти который будет выделять память для объекта либо в куче либо на стеке.
Для конструктора полей будет передаваться МП на кучу.
2. Зная информацию где будет выделяться память для результата функции передавать в метод МП для стека
3. Зная о том, что в вызываемых методах параметр используется только внутри вызываемого метода мы можем помечать такой как локальный для выделения памяти на стеке.
4. Для объектов которые выделены на стеке, можно вызывать деструктор.

Так можно повысить эффективность GC. А скорее всего так и есть.
Можно пойти дальше и проверять параметры методов рекурсивно на их вхождение в параметры методов внутри метода.
Но это уже другая песня.
и солнце б утром не вставало, когда бы не было меня
Re[26]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 19.10.15 08:50
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.


Забавно, когда я изобретал свой О(1)-аллокатор, то пришёл почти к тому же. Но у меня блоки не объединяются (я решил, что так проще), ну и размеры только по степеням двойки.
Правда, мне сказали, что у меня функция двоичного логарифма работает за логарифм, а не за единицу, формально это правда, но я почему-то забил на это.
Вообще у меня главная фича — это наличие realloc_inplace, для вектора это охренеть как полезно, почему раньше никто не додумался?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[27]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 19.10.15 09:30
Оценка:
Здравствуйте, T4r4sB, Вы писали:

EP>>Например для Buddy Allocation сложность логарифмическая. Есть же в том числе и O(1) алгоритмы, например TLSF.

TB>Забавно, когда я изобретал свой О(1)-аллокатор, то пришёл почти к тому же. Но у меня блоки не объединяются (я решил, что так проще), ну и размеры только по степеням двойки.

Amortized O(1) не трудно сделать через набор free-list'ов.

TB>Правда, мне сказали, что у меня функция двоичного логарифма работает за логарифм, а не за единицу, формально это правда, но я почему-то забил на это.


Так в итоге у тебя какой алгоритм? Что-то типа Buddy Allocation?

TB>Вообще у меня главная фича — это наличие realloc_inplace, для вектора это охренеть как полезно, почему раньше никто не додумался?


Додумывались. ЕМНИП у Александреску даже было выступление на эту тему, они нечто подобное использовали в Facebook.
Re[28]: Java vs C# vs C++
От: T4r4sB Россия  
Дата: 19.10.15 09:43
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Amortized O(1) не трудно сделать через набор free-list'ов.


Без амортизации, просто O(1)

EP>Так в итоге у тебя какой алгоритм? Что-то типа Buddy Allocation?


Так я же сказал: TLSF (отсюда: http://peguser.narod.ru/translations/files/tlsf.pdf) без объединения и с только чисто-двоичным размером. Работает за О(1) всё.

EP>Додумывались. ЕМНИП у Александреску даже было выступление на эту тему, они нечто подобное использовали в Facebook.


А, глядишь в С++37 добавят
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[92]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.11.15 12:39
Оценка:
Здравствуйте, -MyXa-, Вы писали:

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


S>>Со свойствами проблема, но их можно динамически обернуть. То есть сделать обертку над классом для описания свойв.

S>>Для простых случаев можно так.
S>>[cs]
S>> [ComVisible(true)]
S>> [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
S>> // [Guid("33B45C9D-1AED-41F9-8880-36AB6AE84749")]
S>> public interface IEventFor1C

S>> Либо пишу ручками используя анонимные типы. И подписка


MX>Не понял, для каких простых случаев, какими ручками? Ты же оборачиваешь произвольную .NET сборку в COM.


Сделал для всех случаев http://rsdn.ru/forum/dotnet/6242418.1
Автор: Serginio1
Дата: 12.11.15
и солнце б утром не вставало, когда бы не было меня
Re[2]: Java vs C# vs C++
От: ELazin http://rsdn.ru/forum/prj/6225353.1
Автор: ELazin
Дата: 26.10.15
Дата: 17.11.15 08:31
Оценка:
A>Для желающих проверить на практике — предлагаю желающим реализовать простейший интерпретатор нетипизированного лямбда исчисления на С++

Задача прикладного программирования детектед! :D

Вообще, кодогенерация времени выполнения на С++ становится все более и более доступной, спасибо LLVM и CLang.
Re[2]: Java vs C# vs C++
От: dikun Беларусь  
Дата: 19.11.15 22:39
Оценка:
RAZ>> Вообще, на хабре мало чего хорошего бывает.

А где бывает хорошее?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.