OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 20 Сентябрь, 2020 13:58

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 09:42 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 225
Купил сегодня журнал IT-Спец (за октябрь).
Пока ехал на работу прочел статью "Производительноть .NET миф или реальность?"
Статья начинается цитатой:
<<"Для преобразования символа в нижний регистр мы используем паттерн "Интерпретатор"
реализованный как синглетон и создаваемый с помощью фабрики классов"
- такие фразы нам приходится слышать на семинарах для программистов, которые периодитечски
проводит компания Microsoft. А что будет если сравнить эту фразу вот с такой "для преобразования символов в нижний регистр необходимо вычесть дельту между началами регистровых алфавитов"
Философи
Что по вашему будет работать быстрее? К сожалению, большинство программистов, выросших на Visual Studio 2003 и старше, все реже задают себе вопрос.>>
Далее автор приводит ответы авторитетных программистов, авторов статей и обладателей MVP.
<< Недавно на моем любимом форуме по программированию я увидел сообщение от начинающего программиста на тему "C# и перечисления". Дело в том, что спрашивающий не знал, как выделить определенный бинарный флаг из числа.
....
Расмотрим два ответа:
public enum TaskStatus
{
Terminated = 1,
Stoped = 2,
Idle = 4,
Working = 8,
Stopping = 16
}

Ответ #1:
static bool StatusIn(TaskStatus enm, params TaskStatus[] enms)
{
foreach(a tEnum in enms)
{
if (enum != tEnum) return true;
}
return false;
}

Ответ #2:
static bool StatusIn(TaskStatus enm, params TaskStatus[] enms)
{
return (Array.IndexOf(enms, enm) != -1);
}
Что тут можно сказать? Мне становится не по себе при попытке представить скорость программ, которые пишут эти специалисты, превращая атомарные операции в циклы. Между прочим второй ответ от (MVP), даже МЕНЕЕ производителен не смотря на кажущуюся простоту, поскольку IndexOf вызывает еще одну функцию, где в цикле ведется поиск необходимого значения. Ответ должен, конечно быть таким
TaskStatus s = TaskStatus.Stoped | TaskStatus.Terminated.>>

Теперь понятно откуда у современных программ ноги растут, вернее мегабайты и гигабайты объема.
Особенно у ведущих производителей ПО.

Как же оказывается прав дедушка Вирт, когда вычищал из своих языков весь "синтактический сахар", оставляя то что действительно необходимо. При этом не теряя мощности самого языка. В этой статье tще приводится несколько примеров на основе C# и введенных в язык полезностей типа foreach. Жаль, что я не нашел в инете статью в электронном виде.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 10:30 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8364
Откуда: Троицк, Москва
Принцип Калашникова в действии.

Сфера ИТ -- система без памяти, а так как помногу вовлекается молодежь, которая легко зомбируется, то и вот, имеем гималаи хрени.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 12:25 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 149
Штирлиц писал(а):
проводит компания Microsoft. А что будет если сравнить эту фразу вот с такой "для преобразования символов в нижний регистр необходимо вычесть дельту между началами регистровых алфавитов"

Не всегда это так - правило не работает, например, в кодировке 866 и наверное в KOI8, в UNICODE тоже не всегда. Так что пусть лучше специальный класс делает.

Цитата:
Теперь понятно откуда у современных программ ноги растут, вернее мегабайты и гигабайты объема.
Особенно у ведущих производителей ПО.

Большая программа - значит солидная, тормозит - значит "думает" :lol:

Цитата:
Как же оказывается прав дедушка Вирт, когда вычищал из своих языков весь "синтактический сахар", оставляя то что действительно необходимо.

В данном случае это ни при чём: подобную глупость для флагов (она не только тормозная, но и неверная) можно написать на любом языке.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 13:24 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 225
ScrollLock писал(а):
Как же оказывается прав дедушка Вирт, когда вычищал из своих языков весь "синтактический сахар", оставляя то что действительно необходимо. В данном случае это ни при чём: подобную глупость для флагов (она не только тормозная, но и неверная) можно написать на любом языке.


Это понятно, что такое можно на любом языке сморозить. В статье еще несколько примеров было с примерами на C#,
где высокоуровневые конструкции языка C# дают плохую производительность. Я же не буду всю статью переписывать здесь. Общий лейтмотив статьи такой, что "... чем более высокоуровневая конструкция, тем меньше ее область применения" и приводятся примеры этого. Когда я написало "дедушка Вирт, когда вычищал из своих языков весь "синтактический сахар", я имел ввиду, что надо сохранять баланс низкоуровневых и высокоуровневых конструкций в языке. Мне кажется, что это ему удалось.
А в заключении автор написал "Существует мнение, что программы на С++ получаются более производительными, зато на C# писать их быстрее. Хочу отметить, что разница в языковых конструкциях действительно дает преимущество C#? но если вы решаете действительно сложную задачу, где используется сложные алгоритмы и где производительность имеет первостепенную важность, тогда разница между С++ и C# минимальна... Другими словами - если писать суперкачественно, вам придется выкинуть все фишки C# и использовать для оптимизации те же указатели. В чем тогда разница между С++ и C#?"

В древнем номере журнала PC Magazine (по-моему) была как-то статья, где сравнивалась MFC и OWL от Borland.
Известно, что по оптимизации Microsoft C++ превосходит Borland C++, но там приводился примеры, когда по скорости выполнения Borland С++ превосходил Microsoft C++, причем существенно, только из-за того, что OWL была гораздо лучше спроектирована, чем MFC. Не знаю как сейчас, но тогда MFC была похожа на китайскую грамоту.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 13:33 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 225
Вроде бы даже в последнюю версию C# должны войти конструкции типа SQL.
Вопрос - зачем это надо в C#, когда есть язык SQL прекрасно справляющийся
с возложенными на него функциями? Мне, например, не понятно.
Язык всего и вся уже был PL/I. Ничего хорошего.
У нас преподаватель говорил, что PL/I - хороший язык, но надо из него 80% возможностей выкинуть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 17:15 

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 142
Откуда: Нижний Новгород
Штирлиц писал(а):
Вроде бы даже в последнюю версию C# должны войти конструкции типа SQL.
Вопрос - зачем это надо в C#, когда есть язык SQL прекрасно справляющийся
с возложенными на него функциями?

Как зачем? тут же С++ 2009 должен выйти. Стало быть тот у кого стандарт толще -тот и круче. Вот и "набивают вес".
Надо подкинуть им идею включить PL/1 как подмножество. :P


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Ноябрь, 2007 20:52 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2934
Откуда: г. Ярославль
batyrmastyr писал(а):
Штирлиц писал(а):
Вроде бы даже в последнюю версию C# должны войти конструкции типа SQL.
Вопрос - зачем это надо в C#, когда есть язык SQL прекрасно справляющийся
с возложенными на него функциями?

Как зачем? тут же С++ 2009 должен выйти. Стало быть тот у кого стандарт толще -тот и круче. Вот и "набивают вес".
Надо подкинуть им идею включить PL/1 как подмножество. :P


Да-а... Бабло завсегда победит зло... И чего мы тут мучаемся, за какие-то немаркетинговые идеи держимся? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 03 Ноябрь, 2007 01:15 

Зарегистрирован: Среда, 01 Август, 2007 00:13
Сообщения: 149
Да ладно, NET не так уж прожорлив. Я часто работаю с MATLAB, так там откомпилированный HELLO, WORLD тянет за собой 140 мегов библиотек и сходу берёт на себя 50 мегов оперативной памяти.

Цитата:
Хочу отметить, что разница в языковых конструкциях действительно дает преимущество C#? но если вы решаете действительно сложную задачу, где используется сложные алгоритмы и где производительность имеет первостепенную важность, тогда разница между С++ и C# минимальна...

При написании сложных алгоритмов надёжность и наглядность обычно важнее производительности и объёма оперативной памяти (главное ведь чтобы работал правильно, а быстрота - дело наживное). Ради своего удобства не жалко сотен мегабайт памяти (MATLAB), если надо будет быстро - можно переписать отдельные критичные куски кода на Си или Фортран. Человеческий труд тоже денег стоит, бывает проще и дешевле потратиться на "железо".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 14 Ноябрь, 2007 10:45 

Зарегистрирован: Среда, 17 Январь, 2007 03:59
Сообщения: 225
Появилась ссылка на саму статью
http://www.gotdotnet.ru/LearnDotNet/CSharp/513899.aspx


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 14 Ноябрь, 2007 17:04 

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье
Штирлиц писал(а):
В этой статье еще приводится несколько примеров на основе C# и введенных в язык полезностей типа foreach.

А вот в Питоне более высокоуровневый for (аналог шарповского foreach) работает быстрее...

Штирлиц писал(а):
"... чем более высокоуровневая конструкция, тем меньше ее область применения"

И тем более оптимально её можно реализовать в языке. Почему в C# это не так?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Ноябрь, 2007 09:57 

Зарегистрирован: Пятница, 29 Июнь, 2007 12:16
Сообщения: 98
Да.... это конечно не в тему, но все же.
Возможности оптимизации я помнится в полной мере осознал как это не удивительно на компьютерной игрушке. Оказалось, что когда на довольно старой игре пользователи позаменяли все текстуры и модели - графика там оказалась на уровне вполне современных экземпляров, а системные требования соответственно на два порядка ниже. Это могло означать только одно - создатели просто леняться прорабатывать детали и пытаются все это спихнуть на встроенные системы видеокарты и рессурсы компа. Немного поразмышляв на эту тему я пришел к выводу, что им так даже выгоднее. В конце концов, качество фильма у нас поределяют по его стоимости, так почему бы качество програмного продукта не определять по его системным требованиям. Я думаю, что дело не только в том, что руки растут откуда-то не от туда, а в том, что их оттуда активно выращивают. Наверное любой крупный продукт на сегодня - начиная от тех самых игр и кончая мощными базами для разработки ПО типа Delphi, если примитивно отловить глюки и соптимизировать по человечески, то скорость работы возрастет в разы, а то и на порядки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Ноябрь, 2007 11:12 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8364
Откуда: Троицк, Москва
Darksnake писал(а):
... В конце концов, качество фильма у нас поределяют по его стоимости, так почему бы качество програмного продукта не определять по его системным требованиям. Я думаю, что дело не только в том, что руки растут откуда-то не от туда, а в том, что их оттуда активно выращивают. ...


Не столько выращивают, сколько поощряют примитивное восприятие -- известно, что дети до 5 лет определяют количество воды в сосуде просто по высоте.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 18 Ноябрь, 2007 13:52 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4443
Откуда: Россия, Орёл
Darksnake писал(а):
Я думаю, что дело не только в том, что руки растут откуда-то не от туда, а в том, что их оттуда активно выращивают.

Это прямо афоризм получился... :lol:


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB