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

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

G>>>>Я неправльно вопрос задал. На было так: Где использование cuda необходимо?
CC>>>Там, где надо ускорить вычисления, которые могут быть ускорены на CUDA
G>>Ну и парочку примеров где это необходимо, так что без cuda-ускорения не будут выполняться задачи.
CC>Пример из жизни: пришел биг босс и сказал что заказчик хочет и платит.
CC>Всё. Все остальные рассуждалки "да каму ета наааада" в сад.
Ну тогда вообще что угодно сделать можно. Даже ОС написать.
Но это совершенно не связано с быстродействием.

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

G>Но это совершенно не связано с быстродействием.
Связано напрямую.
Надо посчитать большой объем аналитики за ограниченное время. Грубо говоря за ночь.

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

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

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

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

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

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

N>Я рассказываю как раз о том, что знаю и что сам разрабатывал. Если угол обзора будет широким (фокусное расстояние небольшое), то качество распознавания номера будет очень низкое.
Да ну? Сам лично видел как статически висячая камера с углом в 45 градусов распозновала 99% номеров.
Учитывая что 100% снимков должны смотреть люди, то исключить все ошибки вполне возможно.


N>А положение автомобиля предсказывают на основании вида нарушения, характера предыдущего движения автомобиля + другие эвристики. Сейчас такая система проходит испытания в нашем городе.
А у нас тупо камер везде понавешали.

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

AVK>>>Радар на аппаратном уровне выдает конкретное число.
N>>Радар приемлем только для определения скорости. Я же говорю про широкий спектр нарушений.
AVK>А про прочий спектр — берут меня сомнения.
Многих берут, сейчас проводятся испытания. В случае их успеха, возможно, появится всё на улицах.

N>>С каких это пор все стали ездить по прямым с постоянной скоростью?
AVK>На интервале между измерением скорости и отработкой камеры — чуть более чем все.
Нарушители чаще ездят с ускорением (особенно на запрещённых поворотах), причём по каждой из координат x и y ускорение разное.

N>> Но я и не говорю, что это такой вычислительно сложный этап, а лишь перечислил все действия, которые должны выполниться с максимальной скоростью.
AVK>Максимальности не видно. Максимально нужно только снять картинку и прочие параметры и скинуть в устройство хранения.
Надо сначала обнаружить нарушение, навести камеру, а только потом снять картинку.

AVK>>>А они и уезжают по факту. В реальном времени распознавать не нужно.
N>>Надо успеть сделать снимок его номера.
AVK>В некоторый дивайсах просто стоит видеокамера, они снимает все. И сделать снимок — это несколько не то, что ты перед этим расписал.
Я и не описываю эти "некоторые девайсы". Есть конторы, которые предлагают решение, например для определения пересечения сплошной: ставится камера, наводится на сплошную и при обнаружении любого номера автоматически записывает его в нарушители. Всё просто и надёжно, но с "маленьким" недостатком: для охвата более-менее протяжённой территории необходимо ставить туеву хучу камер. Возможно ты видел на перекрёстках целые "ежи" из камер — это оно и есть. ГИБДД'шникам такой вариант не очень нравится. Я описываю совсем другой вариант: сложней по структуре, но требующий гораздо меньше оборудования.

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

N>>Я рассказываю как раз о том, что знаю и что сам разрабатывал. Если угол обзора будет широким (фокусное расстояние небольшое), то качество распознавания номера будет очень низкое.
G>Да ну? Сам лично видел как статически висячая камера с углом в 45 градусов распозновала 99% номеров.
G>Учитывая что 100% снимков должны смотреть люди, то исключить все ошибки вполне возможно.
Если камера мегапиксельная, то очень может быть. В некоторых продаваемых библиотеках по распознаванию номеров есть возможность выделять зоны анализа, дабы не просматривать весь кадр. Но на расстоянии 100 метров вероятность распознавания номера будет всё равно очень мала. Поворотная камера с быстрым зумом тут выигрывает.

N>>А положение автомобиля предсказывают на основании вида нарушения, характера предыдущего движения автомобиля + другие эвристики. Сейчас такая система проходит испытания в нашем городе.
G>А у нас тупо камер везде понавешали.
Подходов к безопасности много. Я описал один из них.

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

IT>>Это всё домыслы. В решении бизнес задач царит принцип эффективности.
PD>Эффективности чего ? Работы программиста или конечного кода ?

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

>>Писать сегодня код на C дорого
PD>Да
>>медленно
PD>Да
>>не эффективно
PD>С точки зрения времени работы программиста — да. С точки зрения эффективности рабочей программы — наоборот.

Эффективной можно спокойно считать программу, эффективность которой приемлема. К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут. Такие оптимизации вредны, они усложняют приложение не давая ничего в замен. В данном случае гораздо полезней поработать над оптимизацией структуры и алгоритмов обработки данных. Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент. A здесь C сливает современным языкам со страшной силой.

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

PD>Да. Но только когда ресурсы мало кого интересуют.

До определённого момента они и не должны никого интересовать. Если же приложение слишком прожорливо, то здесь уже никакой C не поможет. Экономия ресурсов в разы и десятки раз никогда не достигалась с помощью низкоуровневых оптимизаций на C. Нужно пересматривать архитектуру и алгоритмы. Если сравнивать эффективное с точки зрения потребления ресурсов приложение, написанное на C и на C#, то на C можно сэкономить проценты, десяток процентов, но не порядки. А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.

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

G>>Ну я писал такое, и что?
N>Не верю. Безопасности нет в самой платформе, следовательно нет и в твоём приложении.

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

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

KV>>Намек, думаю понятен...

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

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

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

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

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

Насколько я понимаю, сами задачи — мне увидеть не судьба, поэтому остается лишь поверить на слово

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

KV>>А можно взглянуть на реальную (не надуманную задачу) где быстродействие, достижимое на управляемых платформах является неприемлемым, из твоей практики? А десяток таких задач?
PD>Ничего себе заявление! Я, значит, должен был десяток задач решить на .NET, чтобы удовлетворить твое любопытство ?

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

PD>Э нет, не пойдет. Безопасность — дело серьезное, даже если специалист по ней не программист вообще.

Да я не безопасность имел ввиду. Ок, забыли

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

Это почему?

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

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

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

PD>А вообще — не надо. Он и так выходить не должен.

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

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

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

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

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

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

PD>Запусти

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

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

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

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

unsafe
{
        char* p;
        *p = 0;
}

— не собралось с ошибкой "Постоянное значение "0" не может быть преобразовано в "char"", ok, не вопрос, переделаем так:

unsafe
{
        char* p;
        *p = '0';
}

— не собралось с ошибкой "Использование локальной переменной "p", которой не присвоено значение", ok, я упорный по натуре, присвоим p null явным образом:

unsafe
{
        char* p = null;
        *p = '0';
}

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

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

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

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

PD>>>Тот код, который ты показал, при определенных условиях вполне безупречен.

PD>А меня логические ошибки беспокоят, а безопасность — абсолютно нет. Ну какая может быть безопасность в задаче перемножения матриц, например ? Индексы пусть где попало не бегают, NULL вместо матриц не используй и не будет никаких угроз

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

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

PD>Стоит.

Да не

Глюк какой-то , причем видимо у меня в голове

Вот это:

полученных производительности сравним с достаточными требованиями для данной задачи

нужно читать как

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

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

PD>>Эффективности чего ? Работы программиста или конечного кода ?

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

Не уходи от ответа. Что, если затраты не столь существенны, а качество продукта на первом месте ?

IT>Эффективной можно спокойно считать программу, эффективность которой приемлема.

Это все слова. От меня требуют — как можно быстрее. Все остальное мне простят. И если тактовая будет 20 GHZ, то от меня все равно будет требовать то же. Иными словами, выжать из железа все, что можно. Ты допускаешь, что такая постановка вопроса возможна ?


>К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут.

Если запрос будет выполняться десятки минут, со мной перестанут разговаривать. А вот если запро выполняется 100 мсек, а остальное — 5 мсек, а я сделаю 4 — мне за это скажут спасибо.

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

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

>Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент.

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


>A здесь C сливает современным языкам со страшной силой.

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


PD>>Да. Но только когда ресурсы мало кого интересуют.

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

А что поможет ? Он же все-таки дает самый быстрый код. На асм перейти — возможно, будет быстрее, но не очень. Может, иногда и стоит.

>Экономия ресурсов в разы и десятки раз никогда не достигалась с помощью низкоуровневых оптимизаций на C. Нужно пересматривать архитектуру и алгоритмы.

Задачи разные бывают. И алгоритмы тоже. Пересмотри, например, алгоритм сложения матриц (только без разговоров о многопоточности, от этого ничего не изменится — мне проще разным потокам разные матрицы дать, и все дела). Что не делай, а складывать придется, и от двойного цикла никуда не денешься. И когда матрицы так примерно 5000 * 5000, то весело будет, я тебе обещаю. А заказчик говорит — давай-давай, матриц много, быстрее, быстрее, не успеваешь.

P.S. Это весьма похоже на одну мою работу. Только вместо сложения матриц там кое-что иное, но тоже матрицы и циклы.

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

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


>А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.

Исходный код — будет, не спорю, а эффективность — наоборот. Тебе про чтение последней строки из файла напомнить ? . Кстати. если уж ты так ратуешь за использование эффективных алгоритмов, почему же ты там пошел на чтение файла целиком, если вполне достаточно прочитать маленький кусочек с конца, да даже и не читать (проблемы будут), а просто открытьт мэппинг — и задним ходом! Вот тебе и пример насчет эффективного алгоритма. Для того, чтобы его сделать, надо как можно пониже уровнем спуститься. Не оперировать абстракциями как-то реализованными, а использовать те средста, которые требуют минимальных действий. А для этого надо работать не с высокоуровневыми, а наоборот, низкоуровневыми средствами. Иными словами, Fine Tuning.

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

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

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

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

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

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

LVV>>Я, например, не могу...
D>Развивайте воображение Ну там в LEGO играйте, например

LVV>>Во всех конторах, где я работал, крах... считался ЧП.
D>Такие конторы значится А вот бортовое военное ПО специально проектируется исходя из требований мгновенного рестарта в случае отказа. Известнейший эпизод — F-16 и высота 0 футов над уровнем моря Ну деление на ноль, ну и что Рестарт, и через секунду всё опять работает.
D>Более того, не редкость вообще построение системы на схеме с постоянным рестартом, например, у спутникового ПО. Менеджер памяти в таких штуках, например, умеет её только выделять. Когда же память заканчивается, то приложение сохраняет своё состояние в постоянную память, и рестартуется.
Я писал бортовую ось, поэтому непосредственно знаю, сколько времени уделяется надежности системы. Достаточно сказать, что система с остояла из 4 эвм, один рабочий, два в горячем резерве и один — в холодном...
Но это как раз и говорит о том, что крах системы — это ЧП.
LVV>>А в производстве ИМХО НЕЛЬЗЯ НИКОГДА!
D>Нельзя только в очень узком сегменте, например, в последней линии защиты исполнительных механизмов. Но там кода с гулькин нос, и его вполне реально сделать надёжным за разумные средства.
Ну, далеко ходить не будем, возьмем систему продажи билетов... Крах системы — ЧП. Хотя восстанавливается, да... Но лучше — без крахов...
Поэтому тут компромисс между эффективностью и надежностью должен быть... ИМХО это очевидно...
Сначала программа должна работать, а потом уж работать быстро...

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

SC>Здравствуйте, Валерий!


LVV>>...постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!!


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

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

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

LVV>> И устаканить в мозгах постулат: НАДЕЖОСТЬ ВАЖНЕЕ ЭФФЕКТИВНОСТИ!!!!!!!!!
S>А вот здесь уже спорно... Надежность безусловно важна, но если программеры-профессионалы, то надежность будет и так.
Надежность "и так" — не будет! Если этим специально не заниматься в процессе разработки...
S>Следовательно надо делать ставку на эффективность.
По этому поводу — читайте первоисточники.
Э. Йодан Структурное проектирование и конструирование программ.
Издательство: М.: Мир
Переплет: твердый; 415 страниц; 1979 г.

Приветствую, LaptevVV, вы писали:

LVV> S>А вот здесь уже спорно... Надежность безусловно важна, но если программеры-профессионалы, то надежность будет и так.
LVV> Надежность "и так" — не будет! Если этим специально не заниматься в процессе разработки...
А кто говорил, что заниматься никто не будет?

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

PD>>>Эффективности чего ? Работы программиста или конечного кода ?
IT>>Эффективность затрат, необходимых для получения конечного результата.
PD>Не уходи от ответа. Что, если затраты не столь существенны, а качество продукта на первом месте ?

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

IT>>Эффективной можно спокойно считать программу, эффективность которой приемлема.

PD>Это все слова. От меня требуют — как можно быстрее. Все остальное мне простят. И если тактовая будет 20 GHZ, то от меня все равно будет требовать то же. Иными словами, выжать из железа все, что можно. Ты допускаешь, что такая постановка вопроса возможна ?

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

>>К тому же программа чаще всего — это комплекс алгоритмов. Бессмысленно, например, выжимать миллисекунды при построении текста SQL запроса, если потом сам запрос выполняется десятки минут.

PD>Если запрос будет выполняться десятки минут, со мной перестанут разговаривать. А вот если запро выполняется 100 мсек, а остальное — 5 мсек, а я сделаю 4 — мне за это скажут спасибо.

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

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

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

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

>>Но такие оптимизации не зависят от языка программирования... хотя я не прав — зависят. Зависят от того насколько выразителен и прост в обращении используемый инструмент.

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

Под оптимизацию стандартных высокоуровневых конструкций, если ты не знал, затачиваются внутренности процессоров. Ещё год назад ты говорил о 5%, сегодня уже об 1-2%, а что будет ещё через пару лет?

>>A здесь C сливает современным языкам со страшной силой.

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

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

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

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

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

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

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

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

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

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

>>А вот сложность решения будет в точности наоборот — код на C# будет на порядки проще кода на C при незначительном увеличении потребления ресурсов.

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

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

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

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

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

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

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

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

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

N>Для разнообразия предлагаю тебе, gandjustas, написать безопасное приложение, которое будет работать на видеокарте с CUDA SDK.
Не совсем понял, разве нет враперра для CUDA SDK на дотнете?

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

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