Здравствуйте, gandjustas, Вы писали:
G>А мотив очень простой. Голый C интеропается с программой на любом языке.
Ну и толку с того что он интеропается?
G> Если не использовать динамическое выделение памяти, указатели
Это вообще то всё есть и в С.
G> наследование, полиморфизм и шаблоны и прочую высокоуровневую лабуду, то пропадают все проблемы, присущие C++.
И какие же проблемы, кроме кривых рук говнокодера с вышеперечисленным связаны?
G>Кроме того, повышается переносимость кода. При удачном стечении обстоятельств можно взять код на С и запустить его на видеокарте с помощью CUDA.
Снимай уже розовые очки.
На CUDA перенести удается только хорошо параллелящиеся алгоритмы. Все остальное превращается в УГ.
Здравствуйте, gandjustas, Вы писали:
G>Ты о чем? Исходники md5 отлично собираются голым C компилятором.
Сишная имплементация MD5 собирается сишным компилятором.
С++сная не собирается
Здравствуйте, hattab, Вы писали:
G>>Зачем мне верить, у меня результаты тестов есть. H>У тебя тест не правильный Померял непонятно что у MSVC++ и экстраполируешь на весь С++
Померял он дефакто WinHeap а не C++ аллокацию.
Зато щастлив как ребенок, что пописал.
Здравствуйте, criosray, Вы писали:
C>А необходимость возникает только тогда, когда продакшн билд начинает течь, как дырявое решето?
И часто такое у вас?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Это C++ники так пишут код на шарпе. Не надо так писать. Пишите нормально i<data.Length и будет счастье.
V>А мне надо именно i<buffLen.
ССЗБ.
V>Например, пришли в декодер сжатые данные, их заведомый размер априори неизвестен. Примеров туевы хучи, вообще-то. Просто поверь, что там где можно было размер массива заведомо подогнать под размеры данных, то это было сделано еще до нашей оранжевой революции.
Как это "априори неизвестен"? покажи мне API которые возвращают "незивестно сколько данных".
G>>А причем тут пиннинг, он имеет значние только когда выделяется память.
V>Если я правильно тебя понял, ты предлагаешь выделить память и тут же навсегда запинить. А вот все соккеты работают через кратковременный пиннинг буферов, и, если я держу постоянно запиненными несколько тысяч буферов, то мои соккеты начнут тормозить (оно так и есть, кстати).
В таком случае надо большие буферы выделять в саом начале и кратковременно их пиннить. Известный рецепт.
V>>>Это зависит от характера вычислений. Например, фильтрация — это крайне примитивные вычисления, там затраты на проверку на границу цикла сопоставимы с полезными вычислениями (сопоставимы потому, что джиттер даже не кеширует в регистре длинну массива, а каждый раз лезет за ней через коссвенную адресацию), и вместо непосредственного приращения указателя каждый раз вычисляет адрес элемента (что вполне понятно, у нас же GC). Итого, мы сможем сделать таких простых вычислений в 2-3 раза меньше. G>>Фильтрация чего?
V>Ээээ... сигналов.
Ну если это FIR-фильтрили что-то в том роде, то не думаю что накладные расходы доступ по индексу окажутся значимыми по сравнению с наложением фильтра.
V>>>В моей задаче распараллеливание одного вычисления не нужно, у меня их и так конкуррентно тысячи идут, я борюсь за эффективность каждого из них. G>>Будешь бороться за каждого — производительности не будет. Компутер гораздо лучше умеет шедулить задания, чем ты сам.
V>И что сказать хотел? Что на наш двухядерник тысячи конкурентных вычислений мало, надо еще в несколько раз распарралелить и, соотвественно, еще уменьшить гранулярность блокировок? Ты хоть глубину это чуши понимаешь?
Еще раз перечитай что я писал. "уменьшить гранулярность блокировок" это как раз попытка гоняться за каждым.
V>Вот когда будет отношение кол-ва ядер к количеству конкурентных вычислений хотя бы 1/10, то тогда я шедуллеру с радостью всё и поручу, а пока что, только лишь пересмотрев сценарии и укрупнив гранулярность блокировок, повысил емкость системы раза в полтора (кол-во одновременно обслуживаемых абонентов).
Ты лучше пересмотри свой взгляд на создание высоконагруженных систем. Например с либой типа CCR можно вообще без блокировок обходится при любом количестве входящих запросов
Здравствуйте, Anton Batenev, Вы писали:
AB>З.Ы. Да, я знаю, что это удар ниже пояса, но хотелось ответить по теме и без эмоций.
Какой удар ниже какого пояса? Ты слил спор и теперь бредишь пытаясь перевести разговор на что-то не относящееся к делу. При этом даже в теме на которую ты пытаешься перескочить ты не понимаешь ровным счетом ничего.
В общем, сплошное ламерство и не умелая демагогия с твоей стороны. Постыдился бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>А мотив очень простой. Голый C интеропается с программой на любом языке. CC>Ну и толку с того что он интеропается?
Удобно использовать как высокоуровневый ассемблер.
G>> Если не использовать динамическое выделение памяти, указатели CC>Это вообще то всё есть и в С.
Кто-тоговорил что нет?
G>> наследование, полиморфизм и шаблоны и прочую высокоуровневую лабуду, то пропадают все проблемы, присущие C++. CC>И какие же проблемы, кроме кривых рук говнокодера с вышеперечисленным связаны?
Все проблемы разработки ПО так или иначе связаны с криворукостью. Это вообще свойство человека — ошибаться.
Нормальные языки должны не допускать грубых ошибок и прощать мелкие. С++ так не умеет, невнимательное кодирование приведет к тому, что программа начнет падать в самый неожиданный момент.
G>>Кроме того, повышается переносимость кода. При удачном стечении обстоятельств можно взять код на С и запустить его на видеокарте с помощью CUDA. CC>Снимай уже розовые очки. CC>На CUDA перенести удается только хорошо параллелящиеся алгоритмы. Все остальное превращается в УГ.
Читай внимательнее выделенное.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>Ты о чем? Исходники md5 отлично собираются голым C компилятором. CC>Сишная имплементация MD5 собирается сишным компилятором. CC>С++сная не собирается
Отсюда брал — http://www.md5hashing.com/c++/
В общем ладно, может тут и моя вина, что не описал контекст, поэтому не понимаю твоего сопротивления очевидным, на мой взгляд, вещам.
В общем, сервер конференций, видео, VoIP и вся лабуда типа шаринга приложений и прочие примочки. Основная реалтаймовая и одновременно нагрузочная вещь — это именно VoIP, остальное реалтаймом можно назвать лишь условно. Что есть VoIP: это 50 пакетов в секунду на абонента в одну только сторону, т.е. итого 100 пакетов на абонента. Железка должна держать их несколько сотен, желательно под тысячу. В общем, у меня такой сценарий, что я даже не могу позволить себе такую мелочь, как лишнее копирование данных и тем паче ни о каких 100тыс выделений буферов в секунду не может быть и речи.
G>Как это "априори неизвестен"? покажи мне API которые возвращают "незивестно сколько данных".
Оно не возвращает, оно читает из сокета в наш предвыделенный буфер. После прочтения возвращает кол-во прочитанных байт. В пакете заголовок и собственно сами данные с неким смещением (зависит от заголовка). Данные обрабатываются прямо из этого буфера по указанной выше причине.
G>В таком случае надо большие буферы выделять в саом начале и кратковременно их пиннить. Известный рецепт.
Там в среднем 6 буферов на абонента, под миллион пинов в секунду — это даже на моей "сиротской" железке просто так выкинуть около 15% производительности.
G>Ну если это FIR-фильтрили что-то в том роде, то не думаю что накладные расходы доступ по индексу окажутся значимыми по сравнению с наложением фильтра.
Обычная там фильтрация, ФНЧ/ФВЧ, алгоритм рекурсивного фильтра примитивен — это просто вычисление многочленов z1*a1+z2*a2+z3*a3+..., zi — элементы последовательности, ai — константы. Думаешь, я тебе вру о том, что затраты на доступ к массиву сопоставимы с полезными вычислениями?
G>Еще раз перечитай что я писал. "уменьшить гранулярность блокировок" это как раз попытка гоняться за каждым.
Да почитал, почитал. Сейчас я тебе контекст обрисовал, ты и сам видишь, что дополнительно параллелить там нечего. Вся система асинхронная, по приходу UDP-пакета стоит задача максимально быстро его обработать и освободить тред для следующего. Кол-во таких VoIP-тредов сейчас в 4-6 раз больше, чем ядер, еще больше делать смысла нет, т.к. производительность больше не растет.
G>Ты лучше пересмотри свой взгляд на создание высоконагруженных систем. Например с либой типа CCR можно вообще без блокировок обходится при любом количестве входящих запросов
Прежде чем советовать что-либо пересмотреть, неплохо бы выяснить как оно сейчас есть... нет?
Чтобы два раза не ходить, скажу что по максимум и это у нас есть, кроме тех сценариев, для которых безблокировочные алгоритмы еще не придуманы. Если быть более точным — то некоторые существующие просто не всегда подходят, ввиду требований выделения динамической памяти для каждой порции данных.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>В общем ладно, может тут и моя вина, что не описал контекст, поэтому не понимаю твоего сопротивления очевидным, на мой взгляд, вещам.
V>В общем, сервер конференций, видео, VoIP и вся лабуда типа шаринга приложений и прочие примочки.
Все правильно, такой набор писать на дотнете — нужно быть на редкость упертым. Дотнет для таких вещей просто не предназначен.
Может быть оно конечно и можно выжать из дотнета требуемую производительность (это не утверждение), но стоить это будет дороже, чем разработка на C++.
Естественно, в таком контексте выбор очевиден. По крайней мере для высоконагруженных сервисов.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MxKazan, Вы писали: MK>>Ну т.е. в принципе, при наличии двух сервис-паков, Photoshop CS2 можно смело назвать Photoshop CS4??? V>Откуда такой вывод?
Ну как...
— Изначально ты написал: "И еще забыл, что последние года 4 тактовая частота процов практически не растет, а обсуждаемого скачка оптимизации JIT-а при переходе на 3.0 версию не было ВООБЩЕ".
— На что получил ответ, что рантайм по прежнему 2.0, что он не менялся со времен второго дотНета, ну нету CLR 3.0 и всё.
— Тем не менее, как контраргумент ты выдвинул такое: "Тем не менее, сам рантайм и .Net-сборки от второго фреймворка обновлялись с выходом каждого последующего или их SP. Для интереса, вот список изменений только лишь для 2.0SP1 http://support.microsoft.com/kb/945757, остальное найти так же не трудно, если есть желание."
Собственно отсюда и вывод, что сервис-паки каким-то магическим образом повышают версию.
Здравствуйте, criosray, Вы писали:
C>В который раз доказали, что Вы банально не понимаете разницы между фреймворком и CLR.
Цитаты?
C>Ликбез: версия CLR не менялась со времен дотнет 2.0 — v2.0.50727.
Офигенный ликбез, судя по обширности представленного материала.
Тогда встречный ликбез для тебя: рантайм и основные .Net сборки (mscorlib, System) постоянно обновлялись после выхода второго фреймворка (когда я говорю второй фреймворк, то это именно релиз Microsoft .Net Framework 2.0, который действительно 2.0.50727). Одни из самых заметных обновлений рантайма, пришедшее с .Net 3.0 — это доработка GC, самое заметное изменение сборок версии 2.0.50727, пришедшее с .Net 3.5 — это интерфейс класса Socket из System.dll. А так по мелочи доработок была куча (начни от ссылки в пред. посте), от внутренних кишок System.Data, до дублирования и переноса по неймспейсам объявлений наиболее популярных интеропных COM структур и интерфейсов.
В принципе, я тебе уже говорил, но мне не лень напомнить: перед выходом третьего фремворка тут шли обсуждения, какие будут изменения в рантайме (не в версии, а реализации, еще не допер разницу?). И некоторые из них были таки произведены: джиттер стал более агрессивно инлайнить, GC стал вовсе незаметен на глаз, но кое-что из обсуждаемого так и осталось без изменений, о чем я и упомянул... а ты развел такую вот непотребную бодягу.
C>Жду публичного признания своей неправоты, уважаемый.
Сформулируй для начала эту неправоту.
И раз ты так усердно цепляешься за версию CLR, то вот тебе домашнее задание: что есть версия CLR? Рекомендую выполнить его тщательно, дабы этот позор тугодумия не тянуть еще на кучу постов.
Здравствуйте, vdimas, Вы писали:
V>Тогда встречный ликбез для тебя: рантайм и основные .Net сборки (mscorlib, System) постоянно обновлялись после выхода второго фреймворка (когда я говорю второй фреймворк, то это именно релиз Microsoft .Net Framework 2.0, который действительно 2.0.50727). Одни из самых заметных обновлений рантайма, пришедшее с .Net 3.0 — это доработка GC, самое заметное изменение сборок версии 2.0.50727, пришедшее с .Net 3.5 — это интерфейс класса Socket из System.dll. А так по мелочи доработок была куча (начни от ссылки в пред. посте), от внутренних кишок System.Data, до дублирования и переноса по неймспейсам объявлений наиболее популярных интеропных COM структур и интерфейсов.
Короче это. Не сошлись вы в том, что один понял 3.0 как версию CLR, другой говорил о CLR, который шел вместе с 3-м FW. Вот и всё, рабочие моменты Кстати, я пару раз на собеседованиях слышал, что некоторые так и не перешли на третий FW, потому что ждут полноценно нового рантайма.
Здравствуйте, samius, Вы писали:
S>Все правильно, такой набор писать на дотнете — нужно быть на редкость упертым. Дотнет для таких вещей просто не предназначен. S>Может быть оно конечно и можно выжать из дотнета требуемую производительность (это не утверждение), но стоить это будет дороже, чем разработка на C++.
А у нас вовсе не целиком на C#. Все высокоуровневые операции — на .Net (там же сценарии по установке связи, редиректу, общение с менеджером и БД и куча всякой подобной хни). А вот на пути агрессивного потока данных лежит нейтив, и я здесь лишь объяснял, почему именно так.
S>Естественно, в таком контексте выбор очевиден. По крайней мере для высоконагруженных сервисов.
А сервис весьма разнороден по характеристикам своих составляющих. Например, видео серваком не обрабатывается, а только пересылается из канала в канал, и скорость показа 8-16 кадров в сек, почему бы не сделать тупую диспетчеризацию потока видео на .Net? То же самое с кучей других апплетов, типа шаринга приложений, общей доски, чата, голосований и т.д. Я уже молчу о задачах аутентификации пользователей, шедуллинга конференций и прочего, прочего, прочего. На С++ всё это можно было бы, разумеется, но не нужно.
Поэтому, основа системы — на дотнет, и прилично рядом кода на нейтив С++. В общем, я не зря говорю, что с интеропом здесь вряд ли кто больше меня возился.
Здравствуйте, VladD2, Вы писали:
VD> Какой удар ниже какого пояса?
Судя по хамско-истеричному тону твоего сообщения и отсутсвию комментариев по очевидным тезисам, прилетело тебе кучно.
VD> Ты слил спор и теперь бредишь пытаясь перевести разговор на что-то не относящееся к делу.
Ты спрашивал, как показать мастер-класс — я тебе ответил. При чем, подобрал задачу как раз под тебя. Или я был слишком хорошего мнения?
VD> При этом даже в теме на которую ты пытаешься перескочить ты не понимаешь ровным счетом ничего.
Ты очень хочешь, но стесняешься мне поведать историю про rocket science сайта RSDN типа "каталог статей" + "форум" с суточным количеством хитов в районе 100-200 тыс и временем жизни кэша в районе минуты? Чтож, удиви меня.
VD> В общем, сплошное ламерство и не умелая демагогия с твоей стороны. Постыдился бы.
Мне-то почему за то, к чему я не имею никакого отношения, должно быть стыдно?
Здравствуйте, vdimas, Вы писали:
V>Поэтому, основа системы — на дотнет, и прилично рядом кода на нейтив С++. В общем, я не зря говорю, что с интеропом здесь вряд ли кто больше меня возился.
У нас соотношение managed/native порядка 250/1. Интеропа почти нет. На плюсах написан только самый агрессивный алгоритм из тех что выполняются на клиентской машине в интерактивном режиме (устранение искажений дисторсии большого снимка порядка 40Мб). На дотнете кончилась фантазия по выдумыванию как его ускорить, тупое переписывание один в один на плюсы дало ускорение в 1.5 раза. Сервер же числорубит на дотнете.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>В общем ладно, может тут и моя вина, что не описал контекст, поэтому не понимаю твоего сопротивления очевидным, на мой взгляд, вещам.
V>В общем, сервер конференций, видео, VoIP и вся лабуда типа шаринга приложений и прочие примочки. Основная реалтаймовая и одновременно нагрузочная вещь — это именно VoIP, остальное реалтаймом можно назвать лишь условно. Что есть VoIP: это 50 пакетов в секунду на абонента в одну только сторону, т.е. итого 100 пакетов на абонента. Железка должна держать их несколько сотен, желательно под тысячу. В общем, у меня такой сценарий, что я даже не могу позволить себе такую мелочь, как лишнее копирование данных и тем паче ни о каких 100тыс выделений буферов в секунду не может быть и речи.
В таком случае буферы надо вделять один раз на на абонента. А еще лучше сделать пул буферов.
G>>Как это "априори неизвестен"? покажи мне API которые возвращают "незивестно сколько данных". V>Оно не возвращает, оно читает из сокета в наш предвыделенный буфер. После прочтения возвращает кол-во прочитанных байт. В пакете заголовок и собственно сами данные с неким смещением (зависит от заголовка). Данные обрабатываются прямо из этого буфера по указанной выше причине.
Так всетаки известно сколько данных.
G>>В таком случае надо большие буферы выделять в саом начале и кратковременно их пиннить. Известный рецепт. V>Там в среднем 6 буферов на абонента, под миллион пинов в секунду — это даже на моей "сиротской" железке просто так выкинуть около 15% производительности.
Пины сами по себе производительность не сажают. Сажается она лишь потому что пины мешают работе GC. Если запиненные блоки попадают в нулевое поколение, то gc начинает работать неэффективно.
G>>Ну если это FIR-фильтрили что-то в том роде, то не думаю что накладные расходы доступ по индексу окажутся значимыми по сравнению с наложением фильтра. V>Обычная там фильтрация, ФНЧ/ФВЧ, алгоритм рекурсивного фильтра примитивен — это просто вычисление многочленов z1*a1+z2*a2+z3*a3+..., zi — элементы последовательности, ai — константы. Думаешь, я тебе вру о том, что затраты на доступ к массиву сопоставимы с полезными вычислениями?
Так это и есть обычный FIR, надо будет тесты написать насколько хреново он работает в .NET.
G>>Еще раз перечитай что я писал. "уменьшить гранулярность блокировок" это как раз попытка гоняться за каждым. V>Да почитал, почитал. Сейчас я тебе контекст обрисовал, ты и сам видишь, что дополнительно параллелить там нечего. Вся система асинхронная, по приходу UDP-пакета стоит задача максимально быстро его обработать и освободить тред для следующего. Кол-во таких VoIP-тредов сейчас в 4-6 раз больше, чем ядер, еще больше делать смысла нет, т.к. производительность больше не растет.
В вашем случае нужна система на базе асинхронных агентов, работающих с асинхронным IO.
G>>Ты лучше пересмотри свой взгляд на создание высоконагруженных систем. Например с либой типа CCR можно вообще без блокировок обходится при любом количестве входящих запросов V>Прежде чем советовать что-либо пересмотреть, неплохо бы выяснить как оно сейчас есть... нет?
Не обязательно. Рецепт производства хороших hiload систем уже давно известен.
V>Чтобы два раза не ходить, скажу что по максимум и это у нас есть, кроме тех сценариев, для которых безблокировочные алгоритмы еще не придуманы. Если быть более точным — то некоторые существующие просто не всегда подходят, ввиду требований выделения динамической памяти для каждой порции данных.
Ну если выделенная память живет недолго, то в под .NET можно и выделять. Хотя это уже в конкретных случаях тестить надо.
Померял непонятно что у MSVC++ и экстраполируешь на весь С++
Кстати, я пару раз на собеседованиях слышал, что некоторые так и не перешли на третий FW, потому что ждут полноценно нового рантайма.
