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

N>>>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK.
O>>Не совсем понял, разве нет враперра для CUDA SDK на дотнете?
C>В нём мало смысла просто. На карте-то выполняется небезопасный код.
Да и тормозной он. По крайней мере по состоянию на весну этого года.

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

N>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Это неверно. Если приложение изначально проектируется как безопасное, то его (я подчеркиваю: ЕГО — приложения) безопасность не будет зависеть от безопасности окружающей его платформы.

N>Согласен, получится безопасный колосс на глиняных ногах. Но разве это приемлемое решение? Тут скорее неправильный выбор платформы (если такой выбор существовал).

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

Но, конечно же, если НЕ выделенное выше, то oops

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

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

И совершенно недостаточно. На базе четырёх железок возможно целое стадо архитектур с разной степенью надёжности. Например, на "Ариан-5" у IRS тоже имелось резервирование, но так как все коробочки были идентичными, и софт был один и тот же, то и баг везде был один и тот же. В результате резерв подох аналогично основной системе, и весь космодром завалило обломками девайса

LVV>Но это как раз и говорит о том, что крах системы — это ЧП.

Вы опять путаете. Речь не о FCS самолёта, или там IRS ракеты — очевидно что их отказ фатален. Речь о компонентах типа рисовалки картографического модуля, рестарт которых ничего страшного не представляет. И нормальные люди такие вещи и не резервируют, и 100% надёжности в требованиях не ставят, бо смысла нет.

LVV>Ну, далеко ходить не будем, возьмем систему продажи билетов... Крах системы — ЧП. Хотя восстанавливается, да... Но лучше — без крахов...

Если консистентность данных сохраняет и рестартует за секунду — в чём проблема ?

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

LVV>>Я писал бортовую ось, поэтому непосредственно знаю, сколько времени уделяется надежности системы. Достаточно сказать, что система с остояла из 4 эвм, один рабочий, два в горячем резерве и один — в холодном...
D>И совершенно недостаточно. На базе четырёх железок возможно целое стадо архитектур с разной степенью надёжности. Например, на "Ариан-5" у IRS тоже имелось резервирование, но так как все коробочки были идентичными, и софт был один и тот же, то и баг везде был один и тот же. В результате резерв подох аналогично основной системе, и весь космодром завалило обломками девайса
Да правильно все. В том — то и дело, что предполагалось разные оси ставитть. Да что-то не сложилось там у руководства. Видитмо не смогли доказать разработку трех одинаковых проектов в разных местах.
LVV>>Но это как раз и говорит о том, что крах системы — это ЧП.
D>Вы опять путаете. Речь не о FCS самолёта, или там IRS ракеты — очевидно что их отказ фатален. Речь о компонентах типа рисовалки картографического модуля, рестарт которых ничего страшного не представляет. И нормальные люди такие вещи и не резервируют, и 100% надёжности в требованиях не ставят, бо смысла нет.
В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...
А мне, как пользователю, обидно терять почти нарисованный рисунок... Если такое произойдет несколько раз, я пошлю и рисовалку, и фирму-разработчика далеко и надолго...
LVV>>Ну, далеко ходить не будем, возьмем систему продажи билетов... Крах системы — ЧП. Хотя восстанавливается, да... Но лучше — без крахов...
D>Если консистентность данных сохраняет и рестартует за секунду — в чём проблема ?
И опять же — что-то не видать систем, которые бы падали...
Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...
Такое поведение надо специально оговаривать с заказчиком...
...

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

LVV>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...

Ну Вам конечно не видно Вы ведь на F-16, или там Eurofighter'е не летаете

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

А почему Вы решили, что что-то потеряется ??? Более того, почему Вы решили, что вообще заметите крэш ??? Будет какой-нибудь секундный фриз, например, и всё поедет дальше.

LVV>И опять же — что-то не видать систем, которые бы падали...

Неправда. Я выше приводил примеры и вполне массовых систем. То что Вы не водитель-дальнобойщик — это Ваши проблемы

LVV>Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...

Ерунда. Не нужна система которая валится каждую секунду.

LVV>Такое поведение надо специально оговаривать с заказчиком...

Про то и базар. Такие системы имеют специальные требования и специальную архитектуру. Поэтому с ними и нет проблем.

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

LVV>Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...

Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.

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

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

LVV>>Это ж простая логика — никому не нужна система, которая падает, хотя и восстанавливается быстро... Чисто психологически...

FR>Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.

Так и есть, только вот C++ и fail fast имхо не очень дружат (e.g.: ошибка в 1 процессе не рушит весь эмулятор)

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

FR>>Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.

К>Так и есть, только вот C++ и fail fast имхо не очень дружат (e.g.: ошибка в 1 процессе не рушит весь эмулятор)

Для C++ тоже вполне реально, та же изоляция в системный процесс например.

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

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

FR>>>Ну идеология того же Эрланга именно на этом и построена, притом системы пишут на ней очень надежные.

К>>Так и есть, только вот C++ и fail fast имхо не очень дружат (e.g.: ошибка в 1 процессе не рушит весь эмулятор)

FR>Для C++ тоже вполне реально, та же изоляция в системный процесс например.

Реально == используемый постоянно на практике подход?
Плюс — а что ты будешь делать с диагностикой падения программы на плюсах? Это ведь ключевой момент — понять, что же вылетело, ну и сделать какие-то корректирующие действия в результате (пусть даже это будет "отправить стектрейс разработчикам или в лог").
Понятное дело, что на плюсах можно всё нарисовать, но интересней было бы рассмотреть соотношение цена/качество на разных задачах. Хотя тут, я думаю, у участников дискуссии уже есть субъективные оценки этого, и основной сыр-бор из-за расхождений этих оценок, а также из-за перемешивания их (оценок) на разных задачах.

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

FR>>Для C++ тоже вполне реально, та же изоляция в системный процесс например.

К>Реально == используемый постоянно на практике подход?

Нет конечно, но используется хоть и редко.

К>Плюс — а что ты будешь делать с диагностикой падения программы на плюсах? Это ведь ключевой момент — понять, что же вылетело, ну и сделать какие-то корректирующие действия в результате (пусть даже это будет "отправить стектрейс разработчикам или в лог").

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

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

Зависит от задачи еще.

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


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

Без труда не вытащищь и рыбку из пруда

PD>>Ну а второе — что , не мог занять проц на 60% без написания своей программы ?

KV>"Это не наш метод" (с)



KV>Ну я же лазил пол-дня по git-у в поисках интересующих тебя определений

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

KV>>>Да, меня это тоже удручает. К сожалению, в .NET еще встречаются задачи, когда полностью абстрагироваться от окружающей тебя ОС не получится при всем желании
PD>>И никогда не перестанут встречаться.

KV>Это почему?

Потому что для того, чтобы абстрагироваться от реальной ОС, надо реализовать .NET на абстрактном компьютере

KV>Дык я ж не предлагал переходить на .NET. Я говорил о добровольном ограничении свободы (например, в рамках того С++)

А на С++ мы это и делаем. Свобода — это ответственность. Я могу делать все, что хочу, но это не значит, что я буду делать бог знает как. Если буду — я только себе проблемы создам. В нормальной ситуации я всегда предпочту более безопасные решения, которые мне меньше проблем создадут. Но в случае чего я всегда знаю, что могу взять управление на себя. То есть сказать (самому себе) — я отказываюсь от всех защитных механизмов, полностью беру ответственность на себя и буду делать, что хочу, а если сделаю не так — сам и виноват, сам и плакать буду. Но зато я действительно могу делать что хочу.

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

KV>Во-во. А потом указатели на пайпы в ядрах обнуляться начинают

Бывает. Но!

Я, скорее всего, ошибку там не найду, тем более, что люди, намного лучше меня в Линуксе разбирающиеся, ее найти не могут. Но давай подумаем немного о ее характере.

Это ведь логическая ошибка. Да, есть некая вероятность , что зануление i_pipe есть следствие некорректного доступа к памяти откуда-то еще. Но скорее всего это не так. Все корректно, кто-то ставит его в NULL при том, что делать это не должен в этой ситуации (точнее, не должны ему были позволить).
Допустим, это было бы на .NET

inode->i_pipe->readers++;

Здесь вместо доступа по NULL (кстати, я не понял, почему при этом в Линуксе чего-то вроде BSOD не происходит — явно же необработанное исключение в режиме ядра, Windows такое не прощает) было бы исключение. С записью в лог стека и т.д. Отлично. Это дало бы возможность быстро найти ошибку. Но ее и так нашли, как видишь. А вот как .NET помог бы найти причину ошибки ? Кто-то поставил i_pipe в NULL (nul), и что ? И в С поставил, ив С# поставил бы. Само по себе присваивание ему NULL есть действие корректное и никаких возражений вызвать не может. Так что имеем явный повтор того, о чем я пару дней назад писал — логическая ошибка, для обнаружения которой нет иных средств, кроме того органа, что в черепной коробке находится.



PD>>И вообще должен сказать, что до появления .NET этому вопросу (выход индекса), как бы это помягче сказать и никого не обидеть... не уделялось слишком большого внимания при обсуждении проблем программирования.

KV>Ну конечно. А то, что перечислено хотя бы здесь — понапридумывали после выхода .NET?

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

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

KV>Это одна из возможных ошибок, позволяющих изменить поток управления текущего процесса. Любая уязвимость — одна из возможных логических ошибок, разница лишь в уровне абстракции, на котором она совершается

Совершенно верно. Одна из. Не самая главная и не самая важная. Но очень уж на виду и понятная даже младенцу. Вот с i_pipe младенцу не очень понятна. Скорее всего там нет выхода индекса, хотя бы потому, что нет индексов. А результат тот же.

>>>и про то, как именно ты определяешь попытки использования нулевого указателя?

PD>>Запусти

PD>> char* p = NULL;
PD>> *p = 0;

PD>>и все сам увидишь.

KV>Попробовал: собралось, запустилось, крэшнулось на виндовом необработанном исключении доступа к нулевому адресу.

Ну вот и все. Если запустить под отладчиком — покажет строку. Исправляй Чего еще хочешь ?



KV>Потом попробовал переписать это в лоб на C#: не собралось с ошибкой "Указатели и буферы фиксированного размера можно использовать только в небезопасном контексте". Ок, добавим небозопасный контекст:

<skipped> Довольно забавно было читать про твои сражения с unsafe и типами

Но зачем же так сложно ?

Class c = nul;
c.Name = "aaa";

даст тебе в точности то же самое



KV>ну слава богу... собралось, запустилось и упало с CLR'ным NullReferenceException.

Что есть C# представление Access Violation, которое имеет место быть — доступ по нулевому адресу.

KV>Feel the difference, что называется.

А в чем разница-то ? Да, С++ программа не будет тебе выдавать CLR'ные исключения. Там просто исключение по доступу к памяти, EXCEPTION_ACCESS_VOLATION, если не ошибаюсь. Стек получить можно. В C# это же исключение перехватили, завернули в C# exception и выложили тебе. А мне его дают в голом виде. В чем разница-то.

Не хочешь в голом виде — пожалуйста (C++)

__try {
char* p = NULL;
*p = 0;
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
CMyException exc(GetExceptionCode());
throw exc;
}

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

PD>>А я и не говорю, что ты утверждал. Я просто отмечаю, что те ошибки, от которых меня намерены защищать, есть 1-2% моих ошибок. А остальные 98% никакими тулзами и средствами не контролируются в принципе. И за эти 1-2% платить цену, о которой я говорил — не стоит, да и шум вокруг них поднимать такой уж нечего.

KV>Наличие цифры 1-2% говорит о твоей осведомленности по части общего числа всех ошибок в твоем коде, включая необнаруженные, вообще-то

Не понял. Почему ты так уверен, что я делаю гораздо больше, чем 1-2 % ошибок, связанных именно с выходом индекса, по сравнению с общим числом ошибок ? Вообще-то я помню считанное количество раз, когда я делал ошибку IndexOutOfRange, гораздо больше было иных. На порядок больше.

KV>Чисто в перемножении, действительно что-то придумать тяжело. Но оно же где-то используется? А тогда, навскидку, уязвимости арифметического переполнения еще никто не отменял

Арифметическое переполнение с плавющей точкой вызывает исключение.


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

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

KV>>>Неужели оно того стоит?

PD>>Стоит.

KV>Да не

Таки да

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

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

К>>Плюс — а что ты будешь делать с диагностикой падения программы на плюсах? Это ведь ключевой момент — понять, что же вылетело, ну и сделать какие-то корректирующие действия в результате (пусть даже это будет "отправить стектрейс разработчикам или в лог").

FR>Если писать с прицелом на это дело, никаких проблем. И какой еще стектрейс если система спроектирована с ожиданием падения некоторых ее частей, я тут никакой разницы с эрлангом не вижу кроме того что там уже многое делает среда.
Про стектрейс не понял (типа мы на него забиваем, т.к. нафиг не надо?), так и про некоторые части (в Эрланге считается, что упасть может всё, что угодно).
А по-моему как раз в среде и есть разница, т.к. в плюсах ты можешь получить недиагностируемый крэш, тогда как в эрланговом эмуляторе он практически всегда будет содержать информацию о том, что же случилось (хотя иногда даже её бывает недостаточно).

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

FR>Зависит от задачи еще.

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

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

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

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

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

F>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? .
F> Напомни мне, плиз!

Мой ответ

http://rsdn.ru/forum/education/2813653.1.aspx

Автор: Pavel Dvorkin
Дата: 28.01.08

ну и немного выше, ниже, правее и левее для полноты картины

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

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

Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.

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

Давай точки над i расставим.

Я не пытаюсь распространить свой крайний случай на всё программирование в мире. Ни в коем разе!
Я не пытаюсь доказать, что С++ нужно использовать для написания сайтов.
И т.д. я не пытаюсь.

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

А часто ли нужен Питон, С, С# или Хаскель — так ли это важно ? Для конкретной задачи и будем решать. А для другой будем решать заново.

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

Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.

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

Так кто из нас терпимее к чужим мнениям ?

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


IT>А при чём здесь ты? Твои задачи — это капля в море и почему на эту каплю должно равняться всё море.

См. выше.

PD>>В теории совершенно верно, а практически не всегда возможна. Например, обработка производится 3dparty lib, свою написать — годы понадобятся, да и будет ли лучше... а вот оптимизировать то, что от меня зависит, я могу. Даже если это 1-2%.

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

Мне сегодня надо чтобы работало. Завтра видно будет. Завтра будут другие задачи и другие деньги.


PD>>Не согласен. Они определяются тем, насколько инструмент близок по своему духу машинному языку. Чем ближе — тем больше у меня возможностей, не переходя или почти не переходя на асм, написать наилушим образом. Что же касается выразительных и простых конструкций иных языков, то эта простотоа и ясность, вполне приемлемые в иных случаях, здесь проигрывают. По той простой причине, что высокоуровненвые конструкции неизбежно компилируются неким стандартным образом, без учета конкретной специфики. Ее полностью можно учесть в идеале на асме, а в реальности — на очень низкоуровневом ЯВУ.

IT>Под оптимизацию стандартных высокоуровневых конструкций, если ты не знал, затачиваются внутренности процессоров.

Расскажи подробнее, какие именно внутренности процессора заточены под ваш любимый SELECT из Linq.

>Ещё год назад ты говорил о 5%, сегодня уже об 1-2%, а что будет ещё через пару лет?

О чем речь идет-то ? В предыдущей моей фразе про проценты ни слова.

PD>>С точностью до наоборот.

IT>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории?

C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.

IT>>>До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет.

PD>>А что поможет ?

IT>Поможет пересмотр архитектуры.

А если ее нельзя пересмотреть ?

PD>>Задачи разные бывают.

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

Ни из чего, что я сказал, это не следует. Если это только впечатление — значит, оно неверно. Если я такое говорил — ссылку в студию!


PD>>Если не трудно, расскажи, как можно оптимизировать эти матричные сложения на порядок по скорости. Я тебе благодарен буду до предела.

IT>Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.

Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?

IT>Напомни. А тебя тем временем ещё больше огорчу. С появлением Linq сегодня этот код у меня выглядел бы вот так:

IT>

IT>File.ReadAllLines("filename").Last();
IT>

IT>Свой оптимизированный вариант можешь не приводить, мне он не интересен.

Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза


http://rsdn.ru/forum/education/2813653.1.aspx

Автор: Pavel Dvorkin
Дата: 28.01.08

А здесь, я думаю, побольше. Судя по тому, что нахождение простой суммы чисел проигрывает в 4-5 раз отнюдь не С++, а C# без Linq

IT>Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.

А почему же ты тогда, предлагая свое решение (тогда еще, да и сейчас) не оговорился — оно хорошо будет работать для малых файлов, но для достаточно больших его применять не следует ? Если бы ты это сделал — я и возражать бы не стал, если там 120 байт — все равно, что делать. Но ты ведь предлагаешь свое решение как универсальное, не так ли ?


PD>>Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.

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

М-да, ну и аргументы...

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

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

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

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

Есть ощущение, что есть некоторое взаимное недопонимание
Я-то тебе как раз говорил, о том, что вариант с "причинами смерти" (в данном случае в Эрланге), скорее всего, будет выгодней, чем просто "заметание мусора под ковёр". Но, как бычно, абстрактно говорить смысла особого нет, всё определяет задача и её условия.

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

К>Есть ощущение, что есть некоторое взаимное недопонимание

Угу

К>Я-то тебе как раз говорил, о том, что вариант с "причинами смерти" (в данном случае в Эрланге), скорее всего, будет выгодней, чем просто "заметание мусора под ковёр". Но, как бычно, абстрактно говорить смысла особого нет, всё определяет задача и её условия.

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

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

LVV>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...

А Word восстанавливает документ после краха. Open Office тоже. И более или менее успешно. FireFox после краха восстанавливает все табы.

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

SC>>Джон Бентли. Жемчужины программирования. 2-е изд. стр. 248 перевода (в пункте 6, вверху):

SC>>"В этой программе, как в любой другой большой системе, есть ошибки. На данный момент их известно 10 штук, они все не слишком серьёзны. В следующем месяце, возможно, будет обнаружено ещё 10 таких же ошибок. Если бы вы могли выбирать между устранением 10 известных на данный момент ошибок или увеличением скорости работы программы в 10 раз, что бы вы выбрали?"
LVV>Устранение ошибок.

См выделенное мной выше. И тратить на это время , м.б. не стоит, потому что

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

LVV>Если скорость заказчика устраивает — то и нефиг ее повышать.

Заказчик и не догадывается, что это могло бы в 10 раз быстрее работать. Откуда ему знать ? Хорошо, если аналогичный продукт есть, а если нет. AuthoCad — он расчеты проводит максимально быстро ? Или могло бы быть раз в 5 быстрее ? Поди скажи... А за ПО с теми же возможностями, но в 5 раз быстрее работающим, озолотили бы.

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

Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз

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

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

LVV>>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха...

PD>А Word восстанавливает документ после краха. Open Office тоже. И более или менее успешно. FireFox после краха восстанавливает все табы.

А IE после краха восстанавливает NTFS и побитые системные библиотеки

"Простите, не удержался" (с)