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

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

lpd>>Может, в некоторых случаях и можно использовать несколько языков. Только ради чего вообще в проекте C#? Только ради автоматического управления памятью? Утечки памяти в C++ отлично отлавливаются с помощью valgrind. C# сейчас используются исключительно из-за наличия удобного фреймворка веб-приложений — других серьезных причин я не вижу.

С>Ради реализации сложной логики без идиотских ошибок. Сложная логика сама по себе сложна, и читаться с экрана она должна легко. Мозг человека ограничен, и если в коде насрано &&&<<><>::->, то чтобы продраться через насранное — требуются немалые мозговые ресурсы.

Я сам не сторонник излишнего использования шаблонов и некоторых фич последних стандартов. Обычный C++ читается легко.

lpd>>тем более, что на практике их не применяют.

С>Да половина всех machine learning контор в силиконовке сидят на этом фреймфорке, и не первый год. Тема очень горячая. Вот, например: http://www.h2o.ai

machine learning — перегретая тема, в перспективы которой я лично вообще не верю. Когда-то было много программистов и даже программ на Бэйсике. Однако Бэйсик исчез, и та же судьба ждет Java в HPC.

Почему-то когда я поднимаю вопрос, чем конкретно C#/Java лучше C++, ответы сводятся в управлению памятью, и конкретным фреймворкам и инфраструктуре. Принципиальных же отличий нет, кроме разной скорости кода, и весьма теоретической и кроссплатформенности Java/C#.

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

lpd>В нагруженных серверах(например, когда клиентами являются мобильные пользователи, VoIP) может быть постоянный обмен обмен пакетами, запросами, обработка данных. В таких случаях быстродействие языка играет роль.
Ну даже если предположить, что stackoveflow — ненагруженный сервер(ггг) то даже при всем при этом быстродействие языка программирования неважно, главное правильно сконфигуренная инфраструктура. Проверено фейсбуком — там ваще пхп был многолет.

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

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

lpd>>В нагруженных серверах(например, когда клиентами являются мобильные пользователи, VoIP) может быть постоянный обмен обмен пакетами, запросами, обработка данных. В таких случаях быстродействие языка играет роль.
I>Ну даже если предположить, что stackoveflow — ненагруженный сервер(ггг) то даже при всем при этом быстродействие языка программирования неважно, главное правильно сконфигуренная инфраструктура. Проверено фейсбуком — там ваще пхп был многолет.

Это имеет смысл только если считать, что автоматическое управление памятью стоит в 2-3 раза большего числа серверов. Кроме того, не все задачи параллелятся так хорошо.
Рассмотрим другой пример: у меня есть планшет 2011 года выпуска Samsung на Android(Java) с процессором 1Gz и 1Gb памяти, на котором не установлено никаких приложений. Новые вкладки chrome открываются на нем по 5-10 секунд. В то время как iPhone более старый работает практически без тормозов. Возникает вопрос: накой Android написан на Java? Может, и web-сервера _лучше_ писать на C++? Я понимаю, что сейчас фреймворки и билд системы в Java/C# удобоней, и это существенная причина при выборе языка.
Однако по сути все сводится к trade-off: ручное управление памятью vs в 2-4 раза более низкое быстродействие. Учитывая, что есть valgrind и память никуда не утекает в C++, остается только ошибка переполнения буфера. Вот мне и интересно, неужели легче админить в 2-3 раза больше серверов и сопрягать C++ с C#, чем вовремя вызывать delete?

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


_>ОС, драйверы и т.д. — это уже другой вопрос, связанный с универсальным доступом к произвольному железу. А вот веб — это классическая прикладная задача, которая упрощённо (если не рассматривать промежуточную сетевую инфраструктуру) представляет собой классическое клиент-серверное приложение. В качестве сервера у нас тут выступают http-демоны (написанные на C/C++), кастомизируемые скриптами (которые пишутся на множестве языков) под конкретный сайт. А в качестве клиента у нас выступают браузеры (написанные на C++) и кастомизируемые скриптами

Давай тогда будем точны в определениях, и начнем отличать веб серверы(которых полдесятка на весь мир) от веб сервисов(которые миллионы, и которые безусловно работают поверх веб серверов.
Дык вот, веб серверы сами по себе, конечным пользователям не нужны, равно как и отдельно взятые браузеры. Им нужны конкретные сервисы, построенные поверх веб серверов и работающие в веб браузерах. И вот внезапно оказывается, что рынок веб серверов ограничивается апачем, иисом и томкатом. А, еще есть Nginx. На рынке браузеров кстате тоже все уныло и предсказуемо.
А вот рынок веб сервисов совсем другой. Именно сервисы нужны конечным потребителям, и тут крутятся реальные деньги. Вот тут и начинается бизнесс прессинг — time to market, стоимость добавления фичи и так далее. И тут внезапно оказывается что С++ в этой сфере не нужен — он проигрывает по все показателям, абстрактные попугаи производительности в вакууме никого не интересуют.

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

_>Вообще то мы уже обсудили, что на каждом из них как раз работает сервер написанный на C/C++. И на РСДН в том числе (там же IIS, правильно?). Но даже если говорить исключительно о серверных скриптах, то применяя твой подход получим, что веб живёт в основном в мире php. )))
Мы уже поняли что веб сервер — это еще один уровень абстракции(как и ОС, драйвера к железу, само железо), предназначенный для того чтобы прикладники могли быстро и беспроблемно писать софт, необходимый конечным покупателям.

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

lpd>Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
А вот тут не помешали бы пруфлинки. Причем не на синтетические тесты, а на реальные юзкейсы.

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

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

lpd>>Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
I>А вот тут не помешали бы пруфлинки. Причем не на синтетические тесты, а на реальные юзкейсы.

Уже рассматривали не раз, в том числе с линками, которые легко гуглятся. Там разница в скорости в 2-4 раза в зависимости от тестов. Я сам компилировал DFT(целочисленный) один и тот же код в C++ и Java, и на нем Java был в 4 раза медленнее.

Здравствуйте, lpd, Вы писали:
lpd>Это имеет смысл только если считать, что автоматическое управление памятью стоит в 2-3 раза большего числа серверов. Кроме того, не все задачи параллелятся так хорошо.
Стоимост ьжелеза в разы дешевле стоимости разработччиков, тестеров и так далее. Особенно квалифицированных С++ разработчиков.

lpd>Рассмотрим другой пример: у меня есть планшет 2011 года выпуска Samsung на Android(Java) с процессором 1Gz и 1Gb памяти, на котором не установлено никаких приложений. Новые вкладки chrome открываются на нем по 5-10 секунд. В то время как iPhone более старый работает практически без тормозов. Возникает вопрос: накой Android написан на Java? Может, и web-сервера _лучше_ писать на C++? Я понимаю, что сейчас фреймворки и билд системы в Java/C# удобоней, и это существенная причина при выборе языка.
Рынок уже все расставил по своим местам, и если у кого нить возникает батхерт — то это его личные проблемы. Даже не буду настаивать на том что эппл ограничил сапорт своего железа в 48 месяцев и пример айфона из 2011 года — ниочем.

lpd>Однако по сути все сводится к trade-off: ручное управление памятью vs в 2-4 раза более низкое быстродействие.
Еще раз: быстродействие самого языка программирования ничего не решает в типичных задачах. Потому что этот язык программирования зажат между БД с одной стороны и веб серверами — с другой. И именно производительность всего пайплайна решает; прирост производительности бизнес-слоя, сам по себе никому не нужен, даже если бы он внезапно стал бесплатным.

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

I>>А вот тут не помешали бы пруфлинки. Причем не на синтетические тесты, а на реальные юзкейсы.

lpd>Уже рассматривали не раз, в том числе с линками, которые легко гуглятся. Там разница в скорости в 2-4 раза в зависимости от тестов. Я сам компилировал DFT(целочисленный) один и тот же код в C++ и Java, и на нем Java был в 4 раза медленнее.
Фраза "реальные юзкейсы" естественно же ускользнула от твоего внимания и ты привычно уперся в "DFT(целочисленный)". Ожидаемо.

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

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

lpd>>Однако по сути все сводится к trade-off: ручное управление памятью vs в 2-4 раза более низкое быстродействие.
I>Еще раз: быстродействие самого языка программирования ничего не решает в типичных задачах. Потому что этот язык программирования зажат между БД с одной стороны и веб серверами — с другой. И именно производительность всего пайплайна решает; прирост производительности бизнес-слоя, сам по себе никому не нужен, даже если бы он внезапно стал бесплатным.

Ну вот Qbit86 в этом треде привел статистику по Stackoverflow(C#):

209,420,973 (+61,336,090) HTTP requests to our load balancer
66,294,789 (+30,199,477) of those were page loads
1,240,266,346,053 (+406,273,363,426) bytes (1.24 TB) of HTTP traffic sent
569,449,470,023 (+282,874,825,991) bytes (569 GB) total received
3,084,303,599,266 (+1,958,311,041,954) bytes (3.08 TB) total sent
504,816,843 (+170,244,740) SQL Queries (from HTTP requests alone)
5,831,683,114 (+5,418,818,063) Redis hits
17,158,874 (not tracked in 2013) Elastic searches
3,661,134 (+57,716) Tag Engine requests
607,073,066 (+48,848,481) ms (168 hours) spent running SQL queries
10,396,073 (-88,950,843) ms (2.8 hours) spent on Redis hits
147,018,571 (+14,634,512) ms (40.8 hours) spent on Tag Engine requests
1,609,944,301 (-1,118,232,744) ms (447 hours) spent processing in ASP.Net
22.71 (-5.29) ms average (19.12 ms in ASP.Net) for 49,180,275 question page renders
11.80 (-53.2) ms average (8.81 ms in ASP.Net) for 6,370,076 home page renders

Мы видим, что даже в задаче записать пост в базу/выдать пост из базы процессор проводит в ASP.Net в 3 раза больше времени, чем исполняет SQL-запросы.

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

lpd>Это имеет смысл только если считать, что автоматическое управление памятью стоит в 2-3 раза большего числа серверов.
lpd>Однако по сути все сводится к trade-off: ручное управление памятью vs в 2-4 раза более низкое быстродействие. Учитывая, что есть valgrind и память никуда не утекает в C++, остается только ошибка переполнения буфера. Вот мне и интересно, неужели легче админить в 2-3 раза больше серверов и сопрягать C++ с C#, чем вовремя вызывать delete?

Нормальные языки вместо C++ выбирают не только из-за управления памятью и борьбы с утечками, это чуть ли не в последнюю очередь. Их выбирают, потому что это существенно облегчает чтение (comprehension), сопровождение и написание кода. Чтобы, наведя в IDE курсор мыши на вызов функции, можно было увидеть её сигнатуру, вместо белого шума:

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

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

I>>>А вот тут не помешали бы пруфлинки. Причем не на синтетические тесты, а на реальные юзкейсы.

lpd>>Уже рассматривали не раз, в том числе с линками, которые легко гуглятся. Там разница в скорости в 2-4 раза в зависимости от тестов. Я сам компилировал DFT(целочисленный) один и тот же код в C++ и Java, и на нем Java был в 4 раза медленнее.
I>Фраза "реальные юзкейсы" естественно же ускользнула от твоего внимания и ты привычно уперся в "DFT(целочисленный)". Ожидаемо.

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

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

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

lpd>>Это имеет смысл только если считать, что автоматическое управление памятью стоит в 2-3 раза большего числа серверов.
lpd>>Однако по сути все сводится к trade-off: ручное управление памятью vs в 2-4 раза более низкое быстродействие. Учитывая, что есть valgrind и память никуда не утекает в C++, остается только ошибка переполнения буфера. Вот мне и интересно, неужели легче админить в 2-3 раза больше серверов и сопрягать C++ с C#, чем вовремя вызывать delete?

Q>Нормальные языки вместо C++ выбирают не только из-за управления памятью и борьбы с утечками, это чуть ли не в последнюю очередь. Их выбирают, потому что это существенно облегчает чтение (comprehension), сопровождение и написание кода. Чтобы, наведя в IDE курсор мыши на вызов функции, можно было увидеть её сигнатуру, вместо белого шума:

Q>Image: 2551532

Я уже не раз писал в этом треде, что лично я не сторонник злоупотребления шаблонами, boostом и некоторыми фичами последних стандартов. Классический С++ читается также, как Java.

Здравствуйте, lpd, Вы писали:
lpd>Мы видим, что даже в задаче записать пост в базу/выдать пост из базы процессор проводит в ASP.Net в 3 раза больше времени, чем исполняет SQL-запросы.
Мы видим что высоквалифицированная команда разработчиков вылизала весь пайплайн до нужного им уровня качества. Уверен, что ни у тебя, ну у меня никогда не будет ни такой команды, ни таких бюджетов, ни таких сроков. Поэтому пример конечно интересен, но иррелевантен каждодневной практике. НО и тут оказалось что С++ не нужен

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

lpd>Ну DFT можно считать за верхнюю границу разницы, а самый быстрый из тестов — за нижнюю. Тестов скорости переписанных с C# на C++ приложений я не видел.
Опять таки я буду настаивать на фразе "реальные бизнес кейсы". Ибо дискретное преобразование Фурье само по себе никому не нужно вообще никогда.

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

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

lpd>>Ну DFT можно считать за верхнюю границу разницы, а самый быстрый из тестов — за нижнюю. Тестов скорости переписанных с C# на C++ приложений я не видел.
I>Опять таки я буду настаивать на фразе "реальные бизнес кейсы". Ибо дискретное преобразование Фурье само по себе никому не нужно вообще никогда.

Вообще-то, оно применяется на каждом шагу в сжатии звука и графики/видео, томографии и всей DSP.

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

lpd>Мы видим, что даже в задаче записать пост в базу/выдать пост из базы процессор проводит в ASP.Net в 3 раза больше времени, чем исполняет SQL-запросы.

Я тебе открою страшную тайну — "кеширование", если бы SO лез в базу на каждый запрос — то он бы умер на любом железе.

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

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

lpd>>Мы видим, что даже в задаче записать пост в базу/выдать пост из базы процессор проводит в ASP.Net в 3 раза больше времени, чем исполняет SQL-запросы.

K>Я тебе открою страшную тайну — "кеширование", если бы SO лез в базу на каждый запрос — то он бы умер на любом железе.

Из статистики можно вывести, что один SQL-запрос в среднем занимает меньше 1.2ms. Так что не уверен в твоем объяснении.

Здравствуйте, lpd, Вы писали:
lpd>Классический С++ читается также, как Java.
Классический С++ это который из них? Тот который "С с классами?" Или еще и с исключениями? Или тот который еще и спецификацией исключений? Или тот который без исключений но с шаблонами? Или с без исключений, но с шаблонами, но без их спецификации? Или тот который с исключениями и шаблонами но без спецификации исключений? Или со спецификациями? Ах да, еще есть потоки ввода вывода. Классический С++ — это тот который с классами, без исключений и с потоками ввода-вывода? Или...
А, я еще забыл про стл. Входит ли она в классический С++(тот самый в который входят который с(или нет) исключения, спецификации исключений, шаблоны и так далее), если входит то в чьей реализации?
А вот я еще про буст вспомнил... ну вы поняли

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


lpd>Из статистики можно вывести, что один SQL-запрос в среднем занимает меньше 1.2ms. Так что не уверен в твоем объяснении.

Жена директора колхоза Глаша спит со всеми, а доярка Маша не даёт никому, но в среднем они обе бл*ди