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

G>>>Вряд ли они там мешают, но не помогают — это точно.
NBN>>Помогают — облегчают рефакторинг и читаемость кода.
G>Шаблоны улучшают читаемость только в самых простых случаях.
Шаблоны это не только александреску-стайл. С ними можно писать читабельный и удобный код.

NBN>>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки
G>Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит.
до 64Gb позволит. Больше современный 32бит проц адресовать не может.

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

G>Вот есть приложение на .NET — www.microsoft.com, там какая сложность?
Средняя сложность. Это если без БД, а только приложение само.

G>couchDB занимался один человек, у него времени на оптимизацию GC уж точно не было.
Ну так там есть ещё одна база данных -- его родная... Нужно было просто повторить архитектуру в целом...

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

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

G>>>Ну на управляемых языках это так, на неупрвляемых — зависит от разработчика.
E>>Нет. Не зависит. Плохой разработчик потратит на реализацию сложного проекта бесконечное время Причём на ЛЮБОМ ЯЗЫКЕ...
G>А кто говорит о плохом разработчике?
Ну там повыше выделено три твоих слова...

Про индусов и ХиндиС, я так понимаю, возражений нет? Вот и славненько!

E> Кстати, миллион строк кода -- это не очень крупный проект...

Смотря, на чем писать

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

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

И>>>>>>>Достаточно в таск менеджере взглянуть на кол-во используемой памяти .net прогой и С++ с эквивалентной функциональностью, чтобы понять, что ты гонишь.
G>>>>>>Кроме того цифра в таск менеждере ни о чем не говорит, просто сверните приложение, будете удивлены.
CC>>>>>Ты не в тот таскманагер смотришь, тебе уже сообщали.
G>>>>Пор цифирке в таскабаре — не ко мне, они меня мало интересуют. Я производидтельность профайлером меряю.
CC>>>И давно ты "кол-во используемой памяти" меряешь профайлером?
G>>А я где-то говрил что меряю количество памяти?
G>>Я же написал что эти цифирки не интересуют. Если нужно быстродействие, то меряю его профайлером.
CC>Ты придуриваешься или всегда такой? Специально оставил поквоченную всю историю вопроса. Речь шла про (см. выше) память. Перечитай внимательно.
Читай выделенное.

CC>Беда то в том, что входной порог в managed сильно низкий, и обложенный памперсами нуб может спокойно говнокодить не получая при этом за свой говнокод по рукам — работает же, и не падает.
Это же замечательно. Больше людей счастливы.

И>>>>>>>а) есть стэк;
G>>>>>>Стек заставляет копировать объекты чаще, чем нужно.
CC>>>>>С чего бы вдруг?
G>>>>Передача объектов по значению вызывает копирование.
CC>>>Обьясни поподробнее какая связь между аллокацией на стеке и передачей объектов по значению?
G>>А возвращение объектов при выделении памяти на стеке как происходит?
CC>Если объект сколь либо серьезных размеров возвращают то никто его на стеке в здравом уме не станет размещать.
Это каких размеров?

CC>Кстати в случае если все таки размещают то ситуацию несколько спасает RVO.
И сыылку спасают при передаче параметров.
Только все это знания, не нужные для решения задачи.

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

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

NBN>>>Тем не менее, человек владеющий С++ врядли будет предлагать использовать С, когда можно использовать С++.
G>>Поправочка: знающий С++ и незнающий других, более выкосоуровневых языков.
CC>Тогда по твоей логике такой предлагать С вместо С++ уж точно не будет. Так что не отнекивайся.
Так я и предлагаю C для performance-critical кода. В остальных случаях более выкокоуровневые языку рулят.

G>>Много ли у вас кода на C++ (с классами, шаблонами, полиморфизмом, эксепшенами и динамической памятью) в тех местах где нужно высокое быстродействие?
CC>С классами, шаблонами — навалом. На производительности результата они не сказываются.
CC>Полиморфизм через виртуальное наследование и исключения — в HPC используются только тогда, когда без них ну совсем ВАЩЕ никак.
CC>Динамическая память используется, но выделение/освобождение из критического кода выносятся по максимуму — всё выделяется заранее.
Ну так у вас и получается C_с_клссами.

NBN>>>А если вы владеете С++ недостаточно — то исчезает последняя почва для спора С++ — язык сложный и филиграный и использовать его в качестве лома действительно не стоит.
G>>Вообще сложность C++ такова что его использовать почти нигде не стоит.
CC> Это всего лишь твоё мнение.
Да

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

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

CC> NBN>>Помогают — облегчают рефакторинг и читаемость кода.
CC> G>Шаблоны улучшают читаемость только в самых простых случаях.
CC> Шаблоны это не только александреску-стайл. С ними можно писать читабельный и удобный код.

Который невозможно сопровождать и отлаживать?

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

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

NBN>>>А чем мешают шаблоны и классы там где нужна высокая производительность?
G>>Вряд ли они там мешают, но не помогают — это точно.
CC>Код писать с ними удобнее чем в С стиле.
А на более выкогоуровневых языках еще удобнее. Вы с этим спортить будете?

NBN>>>Ага, кроме как для игр, приложений затрагивающих эмбеддед сложнее простейших контроллеров, кроссплатформенных приложений которым требуется шустрая работа.
G>>С играми отдельная песня — там сейчас во всю идет перенос тяжелых вычислений на аппартаные ускорители.
CC>Да ты еще и геймдевелопер я смотрю И спец по переносу расчетов на GPU.
CC>Ну-ка расскажи что там и как в геймдеве, а я послушаю.
Не, я с геймдевом сталкивался всего пару раз и обра раза впечатления неочень.

G>>Кроме того .NET не такой медленный как тут некоторые пытаются показать.
CC>Уже всё всем давно показали: Cellfactor
Думаете нету тормозящего говна, написанного на любом языке?

G>>А многим ли приложениям на десктопе нужная шустрая работа?
CC>По мне так всем.


Я сталкивался с пользователями, которые вполне нормально мирились с генерацияей отчета на 1с (которая на С++) которая длилась двадцать минут.

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

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

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

G>>>>Вряд ли они там мешают, но не помогают — это точно.
NBN>>>Помогают — облегчают рефакторинг и читаемость кода.
G>>Шаблоны улучшают читаемость только в самых простых случаях.
CC>Шаблоны это не только александреску-стайл. С ними можно писать читабельный и удобный код.
Ну я и говорю — с самых простых случаях, но в таких случаях C++ сильно уступает по выразительности C#.

NBN>>>А в шарпе уже появилась возможность с пользой использовать всю доступную память? (а то в текущем проекте пришлось поизвращаться и залазить в узкие рамки
G>>Я нормально выделял на шарпе под 2 гига. Вроде как 32-битная ось больше выделить не позволит.
CC>до 64Gb позволит. Больше современный 32бит проц адресовать не может.
Каким образом имея 32-битный указатель можно обратить за пределы четырех гигов?
Возможно сама ось может увидеть много памяти, а для 32-битного приложения 4 гига — предел.

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

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

G>>И опять приходим к тому что для того случая где нужно быстродействие используем C, а для всего остального высокоуровневые средства.
E>Если тебе из С и С++ больше нравится первый, то никто не мешает тебе использовать первый. Один из существенных его недостатков тот, что на нём реально писать только то, где очень нужно быстродействие, а на плюсах можно и остальное.
Все остальное можно писать на более высокоуровневых языках.

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

G>Для расчетов — большими, матрицы примерно 100х100.
G>Для визуализации — куча маленьких.
Ну, а их много было-то?
Я так понимаю, что объекты по 80 кил уже в GC не играют, так что эти большие куски надо, по чеснаку, из 300 метров вычесть. Остальное -- оверхед на визуализаци....
G>Я вообще говоря не следил за выделением памяти в этой программе.
Ну сколько больших матриц-то было в курсе? Тысяча? Больше? Меньше? Если сильно меньше 1000, то максимум на матрицы 50 -- метров. Ещё пусть 50 -- это то, что нужно на визуализацию в нормальной проге. Это с бо-о-о-ольшим, я тебе скажу, запасом. Ну а 200 метров -- это то, что ты не следил/либо то, что GC съел от большой эффективности

G>Ну если все держать в памяти, то неудивительно что она закончилась.
Ну цель-то была не в памяти держать, или там не в памяти, а результат получить
Но там не совсем в памяти было, на самом деле, но это уже подробности. Результат, тем не менее получить удалось
Прототип на C# не смог ничего... ;(

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

G>>>На C# очень много крупных проектов, с миллионами строк кода.
E>>"Очень много" -- это наверное больше 10? Не затруднит привести 5 C# проектов, которые на миллион строк тянут?
G>MySpace вас устроит?
G>Лениво узнавать сколько где строк
))

MySpace -- это аналог "одноклассников", что ли?
Если аналог, то не устроит. Даже на 30 человеко-лет оно не тянет, IMHO...
Да и на миллионы строк, тоже что-то не очень верится. Разве что они базу данных сами писали.

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

E>> Кстати, миллион строк кода -- это не очень крупный проект...

M>Смотря, на чем писать

Я так понимаю, что на ХиндиСе имелось в виду...

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

E>>Дык данные-то есть? Методика, что и как измеряли? На каких примерах? Какая получилась статистика?
G>Не я мерял, во многих книгах и статьях читал упоминания этого факта.

Я думаю, что это просто PR.
Уж больно факт малоправдоподобный

Неужели вот в этом коде:

inline void foo( int i ) { std::cout << i; }

вероятность ошибки в 5 раз меньше, чем в этом:

inline 
void foo( int i )
{
    std::cout << i;
}

А языки отличаются намного сильнее, чем разные стили кодирования в С++

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

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

E>>>Дык данные-то есть? Методика, что и как измеряли? На каких примерах? Какая получилась статистика?
G>>Не я мерял, во многих книгах и статьях читал упоминания этого факта.

E>Я думаю, что это просто PR.
E>Уж больно факт малоправдоподобный

E>Неужели вот в этом коде:

inline void foo( int i ) { std::cout << i; }

вероятность ошибки в 5 раз меньше, чем в этом:

inline 
E>void foo( int i )
E>{
E>    std::cout << i;
E>}

E>А языки отличаются намного сильнее, чем разные стили кодирования в С++

Вам наверное стоит почитать как считают строки.

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

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

G>>Для расчетов — большими, матрицы примерно 100х100.
G>>Для визуализации — куча маленьких.
E>Ну, а их много было-то?
E>Я так понимаю, что объекты по 80 кил уже в GC не играют, так что эти большие куски надо, по чеснаку, из 300 метров вычесть. Остальное -- оверхед на визуализаци....
Это вообще к чему?

G>>Я вообще говоря не следил за выделением памяти в этой программе.
E>Ну сколько больших матриц-то было в курсе? Тысяча? Больше? Меньше? Если сильно меньше 1000, то максимум на матрицы 50 -- метров. Ещё пусть 50 -- это то, что нужно на визуализацию в нормальной проге. Это с бо-о-о-ольшим, я тебе скажу, запасом. Ну а 200 метров -- это то, что ты не следил/либо то, что GC съел от большой эффективности
А мне то что?
На всех машинах, где програ запускалась она работала отлично, ни тормозняков, ни дерганя, ни своппинга.

G>>Ну если все держать в памяти, то неудивительно что она закончилась.
E>Ну цель-то была не в памяти держать, или там не в памяти, а результат получить
E>Но там не совсем в памяти было, на самом деле, но это уже подробности. Результат, тем не менее получить удалось
E>Прототип на C# не смог ничего... ;(
Это говорит только о вашем неумении писать на C.

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

G>Все остальное можно писать на более высокоуровневых языках.
Конечно можно. Но тлько если оно в вычислительном смысле ничего не делает. Максимум -- тупо считает по формулам.
Если есть сложная логика + много памяти + нужна скорость и компактность, то ХиндиС -- плохой выбор!

E> А языки отличаются намного сильнее, чем разные стили кодирования в С++

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

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

G>Я сталкивался с пользователями, которые вполне нормально мирились с генерацияей отчета на 1с (которая на С++) которая длилась двадцать минут.

1С — УГ.
Я знаю программу — Супермаг 2000, написанную на Оракле, отчет пару часов для небольшого магазина. И причем здесь Оракл? Хреновую программу можно написать на любом языке.

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

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

G>>Я сталкивался с пользователями, которые вполне нормально мирились с генерацияей отчета на 1с (которая на С++) которая длилась двадцать минут.

___>1С — УГ.
___>Я знаю программу — Супермаг 2000, написанную на Оракле, отчет пару часов для небольшого магазина. И причем здесь Оракл? Хреновую программу можно написать на любом языке.
Я про это и говорю.
Самое главное что пользователи могут и пару часов подождать.

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

G>Это вообще к чему?
Я хочу понять насколько 300 метров было скушано по делу.
Для сравнения последний FR, при распознавании всех азиатских языков одновременно жрёт столько же...

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

E>>Прототип на C# не смог ничего... ;(
G>Это говорит только о вашем неумении писать на C.
Правда? Если ты хочешь меня в чём-то убедить, то не надо делать утверждений, в которых ты заведомо менее компетентен, чем я (скажем оценивать моё умение писать на чём бы то ни было)