Где НЕТ места .Net - Философия программирования

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

AVK>Здравствуйте, Волк-Призрак, Вы писали:

AVK>Зачем думать если я сказал что тормозит Jet?

Это мои тормоза спичегенератора

ВП>> то неужели нет например managed DBMS? Со сякими там оптимизациями и по факту embedded (не нужно сидеть проге со словарём sql в руках, исчезают тормоза кучи посредникоф ODBC вообще и access в частности), имхо вам надо если такое есть (managed DBMS) на него "перенести" клиента.

AVK>Managed нет, есть unmanaged, но объем работ по переезду на другую БД очень большой.

Понимаю... Это надо фактически распиливать логику, прятать от неё общение с БД, а потом делать интерфейс логика<->хранилище<->bd. Тут как ни крути, в самом деле объём гигантский. Да и собствено перенос данных ещё та песня....

ВП>>Что касается гуя, то тот грид который есть просто немного тормозит

AVK>Видеокарта какая?

"Я уже устал объяснять..."

GeFource4 Ti4200 128mb

ВП>>>>Но от Ослика ИЕ никак совсем нельзя было отклеиться?

AVK>>>Нельзя.

Даа... Ну Вы писали Янус — Вам виднее....

ВП>>[golosom jvanetckogo]не верю![/gj]
AVK>Твое право.
Это просто намёк на то что если бы я боьше имел сведений об условиях разаработки, то:

Не говорил такихглупостей
Действительно полнимал бы, почему ИЕ используется в Янусе и почему Янус так намертво на нём завязан.
добавьте сюда чегонить по вкусу

... << RSDN@Home 1.1.4 beta 3 rev. 185>> @@J[getWorld.ApplyCheats(unfair.Cheats.IDDQD_AND_IDKFA]

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

VD>Здравствуйте, Волк-Призрак, Вы писали:

VD>Что реально есть, так это большее потребление памяти. Ну, так это и есть плата за то, что нет проблем с битой памятью и не нужно тратить время на планирование и кодирование управления памятью.

Это да — сам в Яве наелся этого

ВП>> Производительность нужна раньше чем выйдет версия фреймворка с реактивным ГЦ на натомном ходу.

VD>Да есть она. Это твои тараканы в голове заставляют тебе рассказывать о выдуманных тормозах. Ты глядишь на медленность загрузки дотнетного приложения (как же 2 секунды вместо .2?) и думаешь, что далее приложение будет работать так же медленно. А это не так.

Выделение и умервщление многих миллионов объектов происходит чертвоски быстро. Даже игрука написанная на дотнете летает и никаких тормозов не заметно.
По выделенному: издеваетесь? Я и пофлеймить могу

Я говорил о 30-60 секундах! А не 2-.02...
С тормозами перехода от мессаги к меммаги уже разобролись ("Спасибо jet за наше тормознутое детство!").

ВП>>И придётся писать "критичные" места на том же C++ или вообще на асьме. А для меня это не выглядит "лёгким" делом. Хотя бы потому что практически ламер в программировании, но и потому что я считаю смешанные архитектуры априори более баговитыми, чем однородные.

VD>1. Как показывает практика не в большинстве приложений ничего делать не нужно. Более того быстрее работает код не "оптимизированны" на С++.
Конечно — ведь к моменту выхода проэкта Х версия дотнета с фичей оптимизации Y получит более широкое распостранение и т. п. и т. д.... Но всеравно, "Выпремляйте кривые руки, товарищи!". Т. е. и на супероптизирующем дотнете версии этак 5-6.0 коматозный алгоритм будет лаговать...

VD>2. Если места содержащие оптимизированный, а значит и потенциально багливый, код локализованы, то и искать ошибки становится проше. Ведь совершенно ясно где будет основаная масса проблем.
Ну да. Тут можно даже того, что я с вами согасен, не говорить.
И всётаки лучше строить дом без таракньих нор.

ВП>>Даёшь Longhorn Drivers Famework!

VD>Ну, все к тому и идет. Модель драйверов в Лонгхорне уже разделена на драйверы режима ядра, и драйверы режима пользователя. А последние уже можно и на подобный фрэймворк подсадить.

Упрощение написания дров = удешевление устройств, имхо. Отсюда вывд что это хорошо

. Правда есть один лол. Не думаю что LDN будет в Mono ввинчен. Отсюда вывод что для остальных платформ картина не меняется. "спасает" только тот процент, который виндозные десктопы занимают в своём кластере рынка.

ВП>>Это сркорее результат внутримикросовтной полтики борьбы за кволити (70%).

VD>Отнюдь. Это именно результат дизайна системы. Код в библиотеках дотнета ни чем не лучше чем в остальных АПИ МС. Там и откровенно ламерские куски встречаются.
Ну значит борьба за кволити сейчас идёт пока внутри отдела дизайна, а до кодеров ещё не добраись.

ВП>> Ну там уход от отсутствия проверок на переполнение буферов итп. . а 30% — автоуправление памятью с регулярным профайлингом (см 70%) на предмет ликофф).

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>> @@J[getWorld.ApplyCheats(unfair.Cheats.IDDQD_AND_IDKFA]

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

VD>Скажи спасибо Jet-у. Тормозит он. Так что твои издевки мимо кассы. А дотнет тебе дает возможность просто использовать эту программу, так как на других сдерствах за нее просто никто бы не взял ся бы.

Jet он и в африке Jet....

Вот сдам сессию и сделаю на Яве "SOAP-клиент" для RSDN, если руки не отвалятся.
По крайней мере, попытка будет.

... << RSDN@Home 1.1.4 beta 3 rev. 185>> @@J[getWorld.ApplyCheats(unfair.Cheats.IDDQD_AND_IDKFA]

Здравствуйте, Волк-Призрак, Вы писали:

AVK>>Видеокарта какая?

ВП>"Я уже устал объяснять..."

GeFource4 Ti4200 128mb

Тогда очень странно что тормозит. У меня на встроенной в 865 чипсет тормозов не заметно. Вот 845 подтормаживал ощутимо.

... << RSDN@Home 1.1.4 beta 3 rev. 268>>

Здравствуйте, Волк-Призрак, Вы писали:

ВП>По выделенному: издеваетесь? Я и пофлеймить могу

Я говорил о 30-60 секундах! А не 2-.02...
ВП>С тормозами перехода от мессаги к меммаги уже разобролись ("Спасибо jet за наше тормознутое детство!").

А с загрузкой тоже не сложно разобратьтся — если поглядеть на загрузку процессора в это время и обращения к винту.

... << RSDN@Home 1.1.4 beta 3 rev. 268>>

Здравствуйте, Волк-Призрак, Вы писали:

ВП>Вот сдам сессию и сделаю на Яве "SOAP-клиент" для RSDN, если руки не отвалятся.
ВП>По крайней мере, попытка будет.

255-ым будешь.

... << RSDN@Home 1.1.4 beta 3 rev. 267>>

Здравствуйте, Волк-Призрак, Вы писали:

ВП>Вот сдам сессию и сделаю на Яве "SOAP-клиент" для RSDN, если руки не отвалятся.
ВП>По крайней мере, попытка будет.

Я тоже на Java делаю (точнее, как плагин к Eclipse), только планы более амбициозные

Т.е чтоб плагинами расширять можно было (три типа плагинов — сайт, синхронизация для сайта и бекенд для сайта).

Сайт проекта пока не готов, информация на sourceforge: http://sourceforge.net/projects/forview

На данный момент есть кривущщая синхронизация с RSDN (Apache Axis), персистенс бэкенд — Hibernate (пока что база — PostgreSQL), GUI — Eclipse. Синхронизуется абы как (сделал как временную затычку). На больших объемах проблем пока нет (брал базу от старшего брата, RSDN@Home).

Вот. Собственно, посмотреть пока это чудо нельзя.

В ближайшую неделю хочу сделать минимальный сайт и выложить имеющийся код в Subversion.

Вполне возможно, что что-нибудь да получится

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

NN>Какой шикарный флейм однако....
NN>Так вот, продолжая популярную мыльную оперу...
NN>.Net, нет, и по-видимому, не будет места при разработке приложений:

NN>1)Критичных к скорости выполнения
NN>2)Оперирующих с большими блоками ( 50-100 Мб и больше) данных
NN>3)Принимающих/передающих эти блоки по коммуникациям с ограниченной пропускной способностью (траффик растет как на дрожжах, а за счет чего ??? )
NN>4) Производящих обсчет данных с плавающей точкой, итерационными алгоритмами и n- методами

NN>А для всего остального .Нет подходит так же, как и другое средство программирования...

NN>Есть возражения ?

Также нет места .NET в проектах типа такого:

Есть исходные тексты написанные на C++.
С помощью этих текстов можно скомпилить приложения и драйвера файловых систем
FAT12/16/32,NTFS,EXT2,SYSV,HTFS,ReiserFs,IsoFS и т.д.
для следующих OS:
DOS,Linux,Windows 9x,Windows NT/2K/XP.
для разных платформ как с little endian memory model, так и для big endian memory model.

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

A>>Как-как. Написали аналогичный алгоритм на C# (там работа с матрицами, заполнение одних ячеек по другим, по тригонометрическим функциям) и охерели. Считает правильно, но медленно.

VD>Так показал бы. Глядишь и найдем где у тебя собака порылась.

Что-то типа такого:

void Calc(object[][] m)
{
    int sum=0;
    foreach(object[] ar in m[1])
        foreach(int n in ar)
            sum+=n;
    //...
}

...Отсюда вывод — не подходит .NET для матричных вычислений.

"Silver_s" <7870@users.rsdn.ru> wrote in message
news:968016@news.rsdn.ru
> Здравствуйте, VladD2, Вы писали:
>
>>> Как-как. Написали аналогичный алгоритм на C# (там работа с
>>> матрицами, заполнение одних ячеек по другим, по тригонометрическим
>>> функциям) и охерели. Считает правильно, но медленно.
>
>> Так показал бы. Глядишь и найдем где у тебя собака порылась.
>
> Что-то типа такого:
>
>

> void Calc(object[][] m)
> {
> int sum=0;
> foreach(object[] ar in m[1])
> foreach(int n in ar)
> sum+=n;
> //...
> }
>

>
> ...Отсюда вывод — не подходит .NET для матричных вычислений.

Ёлки палки, что же ты foreach используешь здесь? Для высокопроизводительных циклов только for(). Иначе плата за абстракцию foreach слишком велика. Попробуй вот так:

for ( int i = 0; i < m.Length; ++i ) {
    object [] mm = m[ i ];
    for ( int j = 0; j < mm.Length; ++j ) {
        sum += (int) mm[ j ];
    }
}

А то, что ты jagged массивы используешь, это хорошо. Они побыстрее multi-dimmensional массивов будут.

Posted via RSDN NNTP Server 1.9 delta

Я бы сказал, что сильно снижает производительность упаковка и распаковка типов. Этот процесс хорошо описан в книге Джефри Рихтера. Думаю, прежде, чем писать критические алгоритмы на .NET языках, стоит ее прочесть.

Кстати, зачем массив передавать как объект? Я недавно занимаюсь .NET, но оптимизирующий компилятор может представить массив int как базовый тип, а не как класс. Кто-нибудь, кстати, сравнивал IL код этих двух кусков?

ForEach тут и правда не подходит. И еще момент. Не лучше ли размеры массивов вычислять отдельно? В цикле for сравнение с величиной можент происходить на кажой итерации (это ведь не Дельфи).

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

A>"Silver_s" <7870@users.rsdn.ru> wrote in message
A>news:968016@news.rsdn.ru
>> Здравствуйте, VladD2, Вы писали:
>>
>>>> Как-как. Написали аналогичный алгоритм на C# (там работа с
>>>> матрицами, заполнение одних ячеек по другим, по тригонометрическим
>>>> функциям) и охерели. Считает правильно, но медленно.
>>
>>> Так показал бы. Глядишь и найдем где у тебя собака порылась.
>>
>> Что-то типа такого:
>>
>>

>> void Calc(object[][] m)
>> {
>> int sum=0;
>> foreach(object[] ar in m[1])
>> foreach(int n in ar)
>> sum+=n;
>> //...
>> }
>>

>>
>> ...Отсюда вывод — не подходит .NET для матричных вычислений.

A>Ёлки палки, что же ты foreach используешь здесь? Для высокопроизводительных циклов только for(). Иначе плата за абстракцию foreach слишком велика. Попробуй вот так:
A>

A>for ( int i = 0; i < m.Length; ++i ) {
A>    object [] mm = m[ i ];
A>    for ( int j = 0; j < mm.Length; ++j ) {
A>        sum += (int) mm[ j ];
A>    }
A>}
A>

A>А то, что ты jagged массивы используешь, это хорошо. Они побыстрее multi-dimmensional массивов будут.

И еще кстати

Все ведь зависит от того, как Microsoft Реализовала JIT. Ведь, например, компилятор может решить, что на данном процессоре данную IL команду можно транслировать в код, использующий MMX, SSE и т.д. Обычный же компилятор без указания этого делать не будет, поскольку полученный код может не работать на всех процессорах.

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

A>The stars so gaily glistened... (Fri, 06 Feb 2004 08:27:42 GMT @394)
A>...while the fading voice of g_i whispered through the darkness:

g>> Имеем большой проект, в котором небольшой блок связан
g>> с интенсивными вычислениями.

A>Кстати, в рамках виртуальных машин (.Net, JVM и т.д.), если их код это
A>поддерживает, можно автоматически использовать разные SIMD: MMx, 3DNow, SSE,
A>SSE3, AltiVec — все что на конкретном железе найдется.
A>Так что это не факт что VM и вычисления друг другу противопоказаны — когда
A>как.
A>--
A>WinAMP://none: WinAMP is suffocated
A>http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Arioch<at>nm<dot>ru

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

Постарайся в дальнейшем цитировать в меньшем объеме и так, как это принято на сайте.

... << RSDN@Home 1.1.4 beta 3 rev. 268>>

Сама среда .NET Runtime написана на C++, в критических по быстродействию местах на asm. Если не ошибаюсь, именно так утверждает Рихтер.

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

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

is>>>Куда ж она денется? .net ведь не написан на .net?

R>>не факт.

M>Это смотря что понимать по .NET. Если рантайм, то на С++, а если Framework, то на С#.

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

FR>Сама среда .NET Runtime написана на C++, в критических по быстродействию местах на asm. Если не ошибаюсь, именно так утверждает Рихтер.

Для меня Асм и C++ давно уже не различимые понятия — unmanaged

Я прошу прощения, но, кажется, ваши высказывания немного не точны.

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

Языки высокого уровня типа Фортрана ускоряют написание программы за счет своих библиотек. Так, например, Фортран — математический

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

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

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

R>>а если переписать на ассемблер обсчет задачи, которая написана на С++ и выполняется 2 месяца, то она будет выполняться полмесяца. Сколько денег экономим. А теперь если посчитать, сколько времени и денег обойдется написание нам этой задачи, то нет уж, лучше пусть считает 2 месяца

R>Не факт. Совсем не факт. Вычислительные программы писали на ассемблере вполне успешно и успели набить руку. Тем не менее, с приходом Фортрана, на него перешли очень быстро -- код, который генерировал компилятор, выполнялся быстрее ассемблерного. А С++ по скорости выполнения кода уже догнал Фортран, а в некоторых областях и перегнал.
R>ЗЫ. Я этих событий не застал, так что могу ошибаться. Но по словам людей, с которыми работаю, происходило всё именно так.

R>>ЗЫ. Под .НЕТ есть С++.NET, тот же unfase код
R>Замечание дельное, готовлю ответ.

Этот вопрос на RSDN обсуждается с удручающей регулярностью.
Воспользуйтесь поиском по форумам, почитайте что-нибудь об
оптимизирующих компиляторах.

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

FractalizeR wrote:

> Как это код, генерируемый компилятором Фортрана может быть быстрее
> ассемблерного, если все равно программа на Фортране транслируется в
> ассемблерный код. Ассемблер сам по себе по определению самый быстрый
> язык, поскольку это не язык даже, а просто символическое обозначение
> машинного кода, разве не так?

Posted via RSDN NNTP Server 1.9

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

Не топ-пость. Неудобно читать и отвечать поже.

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

A>>"Silver_s" <7870@users.rsdn.ru> wrote in message
A>>news:968016@news.rsdn.ru
>>> ...Отсюда вывод — не подходит .NET для матричных вычислений.

A>>Ёлки палки, что же ты foreach используешь здесь? Для высокопроизводительных циклов только for(). Иначе плата за абстракцию foreach слишком велика. Попробуй вот так:
A>>

A>>for ( int i = 0; i < m.Length; ++i ) {
A>>    object [] mm = m[ i ];
A>>    for ( int j = 0; j < mm.Length; ++j ) {
A>>        sum += (int) mm[ j ];
A>>    }
A>>}
A>>

FR>Кстати, зачем массив передавать как объект? Я недавно занимаюсь .NET, но оптимизирующий компилятор может представить массив int как базовый тип, а не как класс.

Он и так является внутренним CLR типом. JIT применяет некоторые оптимизации к массивам.

> Кто-нибудь, кстати, сравнивал IL код этих двух кусков?

IL в моем примере будет эффективней. Но IL здесь еще не все определяет. JIT распознает определенные паттерны, такие, например, как при проходе по всему массиву не нужна проверка диапазона в доступе к его элементам.

FR>ForEach тут и правда не подходит. И еще момент. Не лучше ли размеры массивов вычислять отдельно? В цикле for сравнение с величиной можент происходить на кажой итерации (это ведь не Дельфи).

Length все равно инлайнится. Проверено на практике, что вынос его за приделы массива ничего не дает.

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

FR>Сама среда .NET Runtime написана на C++, в критических по быстродействию местах на asm. Если не ошибаюсь, именно так утверждает Рихтер.

Есть Моно на 99% написанный на Шарпе. В нем только базовые части рантайма написаны на С. Ассемблера нет вообще.

... << RSDN@Home 1.1.4 beta 3 rev. 267>>

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

FR>Я бы сказал, что сильно снижает производительность упаковка и распаковка типов. Этот процесс хорошо описан в книге Джефри Рихтера. Думаю, прежде, чем писать критические алгоритмы на .NET языках, стоит ее прочесть.

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

FR>Кстати, зачем массив передавать как объект?

Чтобы небыло граблей. В ансэйфе ты волен создавать массивы в стэке, но отвечать за проблемы будшь сам.

FR> Я недавно занимаюсь .NET, но оптимизирующий компилятор может представить массив int как базовый тип, а не как класс.

Понятия "базовый тип" не существует в природе. Объект — это нечто размещаемое в стэке и имеющие 8 байт объектного оврехэда. В остальном же массив это такая же неприрывная область памяти. Никаких серьезных накладных расскходов не несущая.

FR> Кто-нибудь, кстати, сравнивал IL код этих двух кусков?

Каких?

FR>ForEach тут и правда не подходит.

Почему?

FR> В цикле for сравнение с величиной можент происходить на кажой итерации (это ведь не Дельфи).

Какой величиной? Зачем сравнивать?

... << RSDN@Home 1.1.4 beta 3 rev. 267>>

От:	Волк-Призрак	http://ghostwolf.newmail.ru
Дата:	27.12.04 06:57
Оценка:

От:	Волк-Призрак	http://ghostwolf.newmail.ru
Дата:	27.12.04 06:57
Оценка:

От:	Волк-Призрак	http://ghostwolf.newmail.ru
Дата:	27.12.04 07:52
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	27.12.04 08:50
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	27.12.04 08:50
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	27.12.04 11:35
Оценка:

От:	Mika Soukhov	Stock#
Дата:	30.12.04 11:25
Оценка:

	От:	Silver_s
	Дата:	28.12.04 10:21
	Оценка:

	От:	alexeiz
	Дата:	28.12.04 10:34
	Оценка: