Здравствуйте, kuj, Вы писали:
U>>Например одна из задач которых у меня есть должна обрабатывать картинки. Картинки формата от A5 до A3 с разрешением в 300..600 dpi и цветностью от B/W до True Color прилетают со частотой 2..3 страницы в секунду. За это время надо успеть её обработать (проверить не белая-ли, не загнутые ли углы, нет ли там баркода, не грязная ли ну и т.п.) и положить на хранение. Пока удается укладываться. Медленнее нельзя, при тех объемах которые есть даже 10% процентные тормоза становятся заметными, это уже деньги... Вот я и думаю, если у меня программа будет на C# а не на Delphi, я смогу сохранить скорость?
kuj>Ясное дело. Процессорное время на управление ресурсами в данном случае ничтожно мало в сравнении со временем на обработку собственно самих картинок.
Правильно ли я понял, что управление ресурсами это все таки слабое место C#, но мы типа отбрасываем его потому что якобы оно будет случаться редко?
Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi? Начать с простого, например какой-нибудь фильтр sharpen или despeckle. А что если мне во время анализа опять-же придется распределять кучу всякой памяти, ну и естественно её придется когда-нибудь освобождать? Через пару секунд думаю оно случится само собой.
Здравствуйте, Utruk, Вы писали:
U>>>Например одна из задач которых у меня есть должна обрабатывать картинки. Картинки формата от A5 до A3 с разрешением в 300..600 dpi и цветностью от B/W до True Color прилетают со частотой 2..3 страницы в секунду. За это время надо успеть её обработать (проверить не белая-ли, не загнутые ли углы, нет ли там баркода, не грязная ли ну и т.п.) и положить на хранение. Пока удается укладываться. Медленнее нельзя, при тех объемах которые есть даже 10% процентные тормоза становятся заметными, это уже деньги... Вот я и думаю, если у меня программа будет на C# а не на Delphi, я смогу сохранить скорость?
kuj>>Ясное дело. Процессорное время на управление ресурсами в данном случае ничтожно мало в сравнении со временем на обработку собственно самих картинок.
U>Правильно ли я понял, что управление ресурсами это все таки слабое место C#, но мы типа отбрасываем его потому что якобы оно будет случаться редко?
Не слабое, а сильное место, т.к. почти исключает возможность возникновения утечек памяти (кроме случаев, когда "забыли" отписаться от события объекта в объекте с более длинным lifetime, и редких проблем с фрагментацией кучи в связи с pin`ом объектов, ссылающихся на unmanaged участки памяти).
Я же говорил о том, что временные затраты процессорного времени на управление ресурсами ничтожно малы на фоне других задач. Таких, как обработка картинок в твоем примере или работа с БД/с файловой системой/и т.п.
U>Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi?
Теоретически может работать быстрее, учитывая, что IL компилируется непосредственно на целевой платформе, что дает бОльший простор для оптимизации.
U>Начать с простого, например какой-нибудь фильтр sharpen или despeckle. А что если мне во время анализа опять-же придется распределять кучу всякой памяти, ну и естественно её придется когда-нибудь освобождать? Через пару секунд думаю оно случится само собой.
Естественно случится, но если производительность приложения у тебя упирается в производительность сборки мусора, то пора думать о смене профессии — ибо профнепригоден.
Здравствуйте, Utruk, Вы писали: U>Тезис был "Delphi лучше C# потому что быстрее"...
Это Ваш тезис. Мой тезис — "Дельфи может быть и быстрее, но всем пох... т.е. пофиг". На синтетических тестах на каком-нибудь http://shootout.alioth.debian.org/ даже free pascal показывает очень неплохие результаты. Только вот скорость выполнения кода далеко не главная характеристика языка. Есть еще порог вхождения/кривая обучения, удобство использования, наличие и качество библиотек (в т.ч. возможность использования кода на других языках) и инструментов. Думаете почему нынче довольно большое количество приложений под *nix пишется на питоне? Потому что есть готовые качественные низкоуровневые сишные библиотеки (разработанные за годы развития *nix) и простой способ делать для них обертки на питоне и потом использовать из питонского кода. При этом производительность особенно не просажавается, а программист получает возможность использовать действительно удобный и лаконичный язык.
U>В "других местах" оно даст эффект и с нативным приложением, тут заслуги сишарпа с дотнетом никакой.
Так с этим никто и не спорит.
Hi kuj
kuj>>>Производительность имеет значение только тогда, когда ее не хватает. Вот наш проектик обслуживает примерно 7000-8000 подключений за сутки. Жалоб на производительность нету.
U>>Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
kuj>80 тыс соединений? 1 ггц xeon? и написано на Delphi? "Не верю!"
Я забыл Делфи как страшный сон. Но что в такой цифре странного? Вполне нормальная суточная нагрузка. Не бог весть что.
Здравствуйте, ambel-vlad, Вы писали:
kuj>>>>Производительность имеет значение только тогда, когда ее не хватает. Вот наш проектик обслуживает примерно 7000-8000 подключений за сутки. Жалоб на производительность нету.
U>>>Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
kuj>>80 тыс соединений? 1 ггц xeon? и написано на Delphi? "Не верю!"
AV>Я забыл Делфи как страшный сон. Но что в такой цифре странного? Вполне нормальная суточная нагрузка. Не бог весть что.
С самопальным аппсервером на Делфи? Хочу посмотреть.
Здравствуйте, kuj, Вы писали:
U>>Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
kuj>80 тыс соединений? 1 ггц xeon? и написано на Delphi? "Не верю!"
А что такого? На Kylix, тогда это был Kylix. Ну и немножечко C++. А да... там было два xeon-а.
Впрочем Вас не заинтересовало ни количество одновременно активных/простаивающих/всего, ни количество потребных ресурсов на соединение, ни время обслуживания, ни характер выполняемой работы, ни степень конкуренции. Сами вы тоже подобные параметры не указали, крайне маловероятно чтобы у вас было 7000..8000 одновременных подключений к серверу причем активными были бы ВСЕ и сразу. Это я просто к тому что голые цифры в 7000 или 80000 подключений ни о чем не говорят. Тут можно было бы тоже закатывать глаза и делать многозначительные замечания о ВУЗ-е, годах, длине письки и т.п...
kuj>>>Глобальное преимущество .NET и Java — удобство и скорость разработки. Покажи мне нормальные аналоги для Castle Windsor, MEF, ASP.NET MVC, nHibernate, Rhino Mocks, nServiceBus и т.д. и т.п и покажи мне средства для организации полноценного continuous integration процесса...
U>>Я честно говоря ни одной из этих штук не пользовался... нет нужды. И надеюсь не появится в ближайшем будущем.
kuj>Все ясно. Ты хоть ВУЗ уже закончил?
Не знал что опыт работы с Castle Windsor есть критерий окончания ВУЗ-а... пойду спрашивать знакомых, слышали-ли они про этот самый Castle Windsor хотя-бы краем уха. Надеюсь что хотя бы один наберется. Кстати, а если человек занимается программированием микроконтроллеров, то он тоже должен знать всю эту бодягу чтобы быть удостоенным выпуска из ВУЗа?
Здравствуйте, Utruk, Вы писали:
U>>>Я не знаю что там к чему подключается... но последнее серверное приложение которое мне доводилось писать лет пять назад обслуживало соединений на порядок больше и работало на каком-то там гигагерцовом xeon-е. Я далек от мысли что это является каким-то достижением.
kuj>>80 тыс соединений? 1 ггц xeon? и написано на Delphi? "Не верю!"
U>А что такого? На Kylix, тогда это был Kylix. Ну и немножечко C++. А да... там было два xeon-а.
U>Впрочем Вас не заинтересовало ни количество одновременно активных/простаивающих/всего, ни количество потребных ресурсов на соединение, ни время обслуживания, ни характер выполняемой работы, ни степень конкуренции. Сами вы тоже подобные параметры не указали, крайне маловероятно чтобы у вас было 7000..8000 одновременных подключений к серверу причем активными были бы ВСЕ и сразу.
Читать значит не умеем?
U>Это я просто к тому что голые цифры в 7000 или 80000 подключений ни о чем не говорят. Тут можно было бы тоже закатывать глаза и делать многозначительные замечания о ВУЗ-е, годах, длине письки и т.п...
Смешно слышать про голые цифры от тебя.
kuj>>>>Глобальное преимущество .NET и Java — удобство и скорость разработки. Покажи мне нормальные аналоги для Castle Windsor, MEF, ASP.NET MVC, nHibernate, Rhino Mocks, nServiceBus и т.д. и т.п и покажи мне средства для организации полноценного continuous integration процесса...
U>>>Я честно говоря ни одной из этих штук не пользовался... нет нужды. И надеюсь не появится в ближайшем будущем.
kuj>>Все ясно. Ты хоть ВУЗ уже закончил?
U>Не знал что опыт работы с Castle Windsor есть критерий окончания ВУЗ-а... пойду спрашивать знакомых, слышали-ли они про этот самый Castle Windsor хотя-бы краем уха. Надеюсь что хотя бы один наберется. Кстати, а если человек занимается программированием микроконтроллеров, то он тоже должен знать всю эту бодягу чтобы быть удостоенным выпуска из ВУЗа?
Естественно нет, но судя по твоим постам ты и базовых вещей не знаешь. Продолжай в том же духе. Очень смешно почитать.
Здравствуйте, kuj, Вы писали:
U>>Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi?
kuj>Теоретически может работать быстрее, учитывая, что IL компилируется непосредственно на целевой платформе, что дает бОльший простор для оптимизации.
Э-э-э-э... а практически? То что он теоретически быстрее создает объекты потому что у него "один указатель и одна-две проверки" это мы уже выяснили. Что на практике... я выяснил, у других сразу проблемы возникли. То что он компилируется непосредственно на целевой платформе это тоже в книжке было написано.
U>>Начать с простого, например какой-нибудь фильтр sharpen или despeckle. А что если мне во время анализа опять-же придется распределять кучу всякой памяти, ну и естественно её придется когда-нибудь освобождать? Через пару секунд думаю оно случится само собой.
kuj>Естественно случится, но если производительность приложения у тебя упирается в производительность сборки мусора, то пора думать о смене профессии — ибо профнепригоден.
Злые вы... чуть чо сразу профнепригоден... ещё не начал программировать, а уже записали в дворники.
U>Впрочем Вас не заинтересовало ни количество одновременно активных/простаивающих/всего, ни количество потребных ресурсов на соединение, ни время обслуживания, ни характер выполняемой работы, ни степень конкуренции. Сами вы тоже подобные параметры не указали, крайне маловероятно чтобы у вас было 7000..8000 одновременных подключений к серверу причем активными были бы ВСЕ и сразу. Это я просто к тому что голые цифры в 7000 или 80000 подключений ни о чем не говорят. Тут можно было бы тоже закатывать глаза и делать многозначительные замечания о ВУЗ-е, годах, длине письки и т.п...
Говорилось про 7000-8000 подключений в сутки. то есть где-то одно подключение за 20 секунд. Такую нагрузку практически любая прога выдержит. В десятки раз большая нагрузка — менее секунды на запрос уже серьезная нагрузка. Если запросы обрабатываются достаточно медленно, то производительнось может упереться в количество тредов и открытых подключений.
U>Не знал что опыт работы с Castle Windsor есть критерий окончания ВУЗ-а... пойду спрашивать знакомых, слышали-ли они про этот самый Castle Windsor хотя-бы краем уха.
Уверен что нет. Можешь про IoC и TDD спросить. U>Надеюсь что хотя бы один наберется. Кстати, а если человек занимается программированием микроконтроллеров, то он тоже должен знать всю эту бодягу чтобы быть удостоенным выпуска из ВУЗа?
Видел группу из 10 программистов на делфи, которые ничего из указанного не знают. Уже третий год пишут программу, которую можно написать втроем за полгода.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Utruk, Вы писали:
U>>Придется значит вам поверить мне на слово что Delphi быстрее чем C#.
НС>Простой вопрос — что находится в массивах после вызова SetLength
Как всё плохо оказывается-то... данные находятся. Какие-нибудь данные, и способ получения и заполнения массива этими данными нас не касается. Через N наносекунд после создания этого объекта по нему пройдется визитор и что-нибудь с ним сделает. Может быть заполнит этот массив какими-нибудь осмысленными данными.
Здравствуйте, Utruk, Вы писали:
U>>>Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi?
kuj>>Теоретически может работать быстрее, учитывая, что IL компилируется непосредственно на целевой платформе, что дает бОльший простор для оптимизации.
U>Э-э-э-э... а практически? То что он теоретически быстрее создает объекты потому что у него "один указатель и одна-две проверки" это мы уже выяснили. Что на практике... я выяснил, у других сразу проблемы возникли. То что он компилируется непосредственно на целевой платформе это тоже в книжке было написано.
Мда. Смешно. Ты до сих пор считаешь, что критерий это время на создание какого-то там объекта? Кино и немцы....
U>>>Начать с простого, например какой-нибудь фильтр sharpen или despeckle. А что если мне во время анализа опять-же придется распределять кучу всякой памяти, ну и естественно её придется когда-нибудь освобождать? Через пару секунд думаю оно случится само собой.
kuj>>Естественно случится, но если производительность приложения у тебя упирается в производительность сборки мусора, то пора думать о смене профессии — ибо профнепригоден.
U>Злые вы... чуть чо сразу профнепригоден... ещё не начал программировать, а уже записали в дворники.
Так о чем споришь? Приходи годков через 5, как опыта да знаний наберешься.
Здравствуйте, Utruk, Вы писали:
U>Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi?
При одинаковом алгоритме конечно нет. А если написать хороший алгоритм для .NET, то прога на C# окажется быстрее, а код станет гораздо более удобочитаемый.
Здравствуйте, gandjustas, Вы писали:
U>>Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi? G>При одинаковом алгоритме конечно нет.
Это спорно. В некоторых случаях даже C++ native оказывается медленнее, чем .NET (легко найти в гугле бенчмарки). Что уж говорить про Delphi...
Hi kuj
kuj>>>80 тыс соединений? 1 ггц xeon? и написано на Delphi? "Не верю!"
AV>>Я забыл Делфи как страшный сон. Но что в такой цифре странного? Вполне нормальная суточная нагрузка. Не бог весть что.
kuj>С самопальным аппсервером на Делфи? Хочу посмотреть.
Давно не видел Делфи. И очень рад этому. А что тебя смущает в этом? Если писать аккуратно, то ничего ужасного в этой цифре нет. Учавствовал в разработке AppServer (сейчас несколько отошел от этого). Так тестовые прогоны на следующей задаче — выборка данных из БД (пару тысяч записей), обсчет их, выгонка результатов обсчета в TeX, преобразование TeX в PDF и отдача последнего пользователю — давали необходимую цифру (около 18700-19000 обработанных запросов за чуть больше чем за 2 часа). Тестовая машина — Intel Core 2 Duo то ли 2.0 то ли 1.8 ГГц. Памяти 3 гига. И это не предел. Просто больше не требовалось. Поэтому на более насыщенных нагрузках никто и не гонял. Пока.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Utruk, Вы писали:
G>Говорилось про 7000-8000 подключений в сутки. то есть где-то одно подключение за 20 секунд. Такую нагрузку практически любая прога выдержит. В десятки раз большая нагрузка — менее секунды на запрос уже серьезная нагрузка. Если запросы обрабатываются достаточно медленно, то производительнось может упереться в количество тредов и открытых подключений.
Не понятно-же как оно распределено по суткам. Может все 7000 случаются в пределах получаса, а может размазано равномерно по суткам. Этого автор не написал... Если 7000 равномерно размазано по суткам и это говорится в контексте "посмотрите какой у нас производительный прожект на С#" то блин... ну тогда либо С# просто редкостное, либо автор к написанию сервера отношение имеет крайне посредственное. Потому что на том ксеоне с 80-тью тысячами соединений, сервер приложений написанный на Kylix+Indy+C++ совершенно никого не напрягал по скорости (это было примерно 250 рабочих станций). Сколько максимум одновременно активных соединений за всё время работы сервера я как-то не удосуживался посмотреть, но самое большое которое доводилось видеть было около 120. По потоку на клиента.
U>>Не знал что опыт работы с Castle Windsor есть критерий окончания ВУЗ-а... пойду спрашивать знакомых, слышали-ли они про этот самый Castle Windsor хотя-бы краем уха. G>Уверен что нет. Можешь про IoC и TDD спросить.
Странно, а ВУЗ закончили... Если про TDD спрошу, а человек не ответит то точно ВУЗ не закончил? U>>Надеюсь что хотя бы один наберется. Кстати, а если человек занимается программированием микроконтроллеров, то он тоже должен знать всю эту бодягу чтобы быть удостоенным выпуска из ВУЗа? G>Видел группу из 10 программистов на делфи, которые ничего из указанного не знают. Уже третий год пишут программу, которую можно написать втроем за полгода.
На каких только я языках такого не видел... а когда пили вместе они рассказывали подобную байку про кого-нибудь другого.
Здравствуйте, kuj, Вы писали:
U>>Э-э-э-э... а практически? То что он теоретически быстрее создает объекты потому что у него "один указатель и одна-две проверки" это мы уже выяснили. Что на практике... я выяснил, у других сразу проблемы возникли. То что он компилируется непосредственно на целевой платформе это тоже в книжке было написано.
kuj>Мда. Смешно. Ты до сих пор считаешь, что критерий это время на создание какого-то там объекта? Кино и немцы....
Я до сих пор сравнивал C# и Delphi только в разрезе скорости. Про остальные моменты даже не заикался. Если вы не поняли, я не виноват. Читать внимательнее надо сообщения. Если бы вы сразу сказали: "Не, это не критерий, эдак мы быстро придем к выводу что Delphi лучше чем C#", то я бы счел вопрос закрытым и возможно перешел бы к другой теме.
U>>>>Начать с простого, например какой-нибудь фильтр sharpen или despeckle. А что если мне во время анализа опять-же придется распределять кучу всякой памяти, ну и естественно её придется когда-нибудь освобождать? Через пару секунд думаю оно случится само собой.
kuj>>>Естественно случится, но если производительность приложения у тебя упирается в производительность сборки мусора, то пора думать о смене профессии — ибо профнепригоден.
U>>Злые вы... чуть чо сразу профнепригоден... ещё не начал программировать, а уже записали в дворники. kuj>Так о чем споришь? Приходи годков через 5, как опыта да знаний наберешься.
Здравствуйте, Utruk, Вы писали:
U>>>Э-э-э-э... а практически? То что он теоретически быстрее создает объекты потому что у него "один указатель и одна-две проверки" это мы уже выяснили. Что на практике... я выяснил, у других сразу проблемы возникли. То что он компилируется непосредственно на целевой платформе это тоже в книжке было написано.
kuj>>Мда. Смешно. Ты до сих пор считаешь, что критерий это время на создание какого-то там объекта? Кино и немцы....
U>Я до сих пор сравнивал C# и Delphi только в разрезе скорости. Про остальные моменты даже не заикался. Если вы не поняли, я не виноват. Читать внимательнее надо сообщения. Если бы вы сразу сказали: "Не, это не критерий, эдак мы быстро придем к выводу что Delphi лучше чем C#", то я бы счел вопрос закрытым и возможно перешел бы к другой теме.
Скорости чего? Сферического коня в банаховом пространстве? Самому еще не смешно?
U>>>>>Начать с простого, например какой-нибудь фильтр sharpen или despeckle. А что если мне во время анализа опять-же придется распределять кучу всякой памяти, ну и естественно её придется когда-нибудь освобождать? Через пару секунд думаю оно случится само собой.
kuj>>>>Естественно случится, но если производительность приложения у тебя упирается в производительность сборки мусора, то пора думать о смене профессии — ибо профнепригоден.
U>>>Злые вы... чуть чо сразу профнепригоден... ещё не начал программировать, а уже записали в дворники. kuj>>Так о чем споришь? Приходи годков через 5, как опыта да знаний наберешься.
U>Да я от вас хотел набраться ума... а чо нельзя?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Utruk, Вы писали:
U>>Т.е вы хотите сказать что если я скажем перепишу анализ документа на C#, то при одинаковом алгоритме он будет быстрее чем на Delphi? G>При одинаковом алгоритме конечно нет. А если написать хороший алгоритм для .NET, то прога на C# окажется быстрее, а код станет гораздо более удобочитаемый.
Ну дык и для нативного приложения можно написать хороший алгоритм. Разве не так?
