Здравствуйте, AndrewVK, Вы писали:
AVK>Все это правильно, вот только что то мне кажется что меньше всего меня волнует скорость работы на шарпе алгоритма сжатия в mp3 или ogg. Потому как это мизерный процент решаемых с его помощью задач.
Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, я не буду пользваться винампом, который перепишут полностью на дотнете.
Кстати, а игрушки нынче все аппартаные ?
Процент мизерный, а используется повсеместно. Даже на твоем крутом ноутбуке весом в 2.8 кг.
PE>>Кстати, а рары, зипы, тары — тоже аппаратно жмут ?
AVK>Ты часто рары и зипы пишешь? Я нет.
С помощью раров и зипов меряется реальный перформанс процессоров.
Со временем конечно начнут писать ужималки, математику, моделирование, игры и тд и тд на дотнете полным ходом. Но не потому, что перформанс выше. Потому, что дешевле. Как только PI-PII-PIII устареют на столько, что самы распространенным процом будет PIV, тогда и рванет дотнет в небо. Ну и на 64битах конечно. Портировать на 64 бита гораздо проще дотнет и прилы под него, чем несколько миллионов прилаг.
Здравствуйте, AndrewVK, Вы писали:
AVK>Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?
Вот предложи свой вариант на C# без дженериков.
PE>>IConnectionPointContainer/IConnectionPoint AVK>Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия.
Дело не в COM а в спосое взаимодействии клиентов.
PE>>Выписывать такой код самоубийство.
AVK>Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.
В том то и дело что генерим мы только коллекции. А тут придется писать еще и генератор наших классов.Хорошего в этом мало — генереный код периодически приходится перегенерировать, чтобы внести изменения.
PE>>Жирным я выделил то, что пишу с использованием делегатов и эвентов. PE>>Есть разница ?
AVK>Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?
Класс, который реализует интерфейс обратной связи с другим объектом.
Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова.
PE>>Но это не все. В методе set каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !
AVK>Опять не понял. Эвент на самом деле просто приватное поле класса с двумя функциями для подписки и отписки. С использованием интерфейсов ты можешь сделать ровно тоже самое. Не так красиво как операторы +-=, но больше ничем не оличается. Просто вместо подписки определенного метода ты тем же классом реализуешь интерфейс и передаешь не делегата, а сам класс.
Я имею в виду, что вначале нужно оптисаться от пары тройки уведомлений, а потом подписаться на все заново у другого объекта.
PE>>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!! AVK>Значит что то не так. Причем явно не так.
Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда.
AVK>Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет.
Легко на маленьгких прилах. А если алгоритм сутки работает ?
В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм. PE>Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...
Десериализация графа проблема вроде изученная. Делается на банальной хэштаблице. Вам вообще можно написать ручной механизм и бует все летать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Еще нужно писать механизм, который в COM реализуется с помощью PE>IConnectionPointContainer/IConnectionPoint
Не нужно. Не приплитай сюда еще и ком. Там борьба с ЭддРефами коих в дотнете нет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Короче, где-то на следующей недели будет готов парсер R#-а. Там и до генератора не долего. Думаю, с его помощью все что тебе нужно можно будет сделать влет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ты по ссылке то ходил? Это по твоему подтверждение. Ну, тогда вот опровержение: www.rsdn.ru
K>Вся работа с памятью сделана ручками, ибо не хватает ее родимой. Все 1.5 гига которые можно реально урвать на процесс расписаны и поделены. Плюс решатель в отдельном процессе 800МБ кушает.
2003-ий этерпрайз не пробовали ставить? Там можно урвать 3 гига вроде.
K>Пул он при любых условиях пул. А ГЦ с какогото момента уже не пул, а проклятье.
С точки зрения расхода памяти пул проклятье еще то...
VD>>Согласен, но велика ли разница? И так ли часто ты пользуешся пулом и другими тонкими оптимизациями? K>дальше продолжать?
На вопрос ты так и не ответил.
K>А если не хватает?
Ну, если твои задачи и в правду на рпеделе 32-х бытных технологих живут, то тебе даже над ассемблерной оптимизацией подумать не грех. Только это очень редкое исключение. 90% людей имеют несколько менее масштабные задачи.
Да и несколько смущает, то что есть и другие кады и им хватает куда меньше памяти.
VD>>Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул. K>Это наверное, шутка?
Отнюдь.
K>А если эти фрагменты 80% кода. Можно конечно остальные 20 (ГУЙ и прочее) на НЕТ перевести, но какой смысл? Я не вижу.
Сомневаюсь я как-то. Скорее это уже дизайн.
K>То что показал бокс — это какая-то пародия на тест. Могу написать реальный на котором ГЦ заткнется. А С++ будет летать.
Я и сам могу. Но в среднем он очень даже ничего.
K>Это когда же он будет свободен если алгоритм несколько дней работает?
Значит несколько минут из этих нескольких дней потарахтит. Тут это вообще не критично.
K>Для кого-то теория, а для меня обычная повседневность жизни. А фичи эти не используют пока все устраивает.
Так большинство как раз все и устраиват. Мы говорим о непримененмости дотнета в редких экстримальных случаях или в массовмо производстве софта?
K> А как только появляется узкое место, то прикрутить пул пустяковое дело. Тогда все начинает летать. Что и видно невооруженным глазом.
Несколько дней — это "летать"? Странная логик.
K>А если нет особой разницы то зачем куда-то переходить? Только ради ГУЯ? А во всем остальном иметь мучения.
Так разницы нет только в скорости работы программы. А в скорости ее разработки она очень даже есть.
K>З.Ы. Кстати еще про пул. (Исходник здесь: http://rsdn.ru/File/16157/mem_mgr.h)
Здравствуйте, Plutonia Experiment, Вы писали:
VD>>Она и в С++ на асме написана обычно. МемМув лучше всего реализуется командой mov ассемблера.
PE>Угу. В файле strcat.c из CRT есть такое PE>... PE>Такого ассемлера я не знаю.
Хорошо у тебя еще не хватило воображения по *.cpp поискать.
Смотри crt\src\intel\strcat.asm или меняй компилятор.
page
;***
;char *strcpy(dst, src) - copy one string over another
;
;Purpose:
; Copies the string src into the spot specified by
; dest; assumes enough room.
;
; Algorithm:
; char * strcpy (char * dst, char * src)
; {
; char * cp = dst;
;
; while( *cp++ = *src++ )
; ; /* Copy src over dst */
; return( dst );
; }
;
;Entry:
; char * dst - string over which "src" is to be copied
; const char * src - string to be copied over "dst"
;
;Exit:
; The address of "dst" in EAX
;
;Uses:
; EAX, ECX
;
;Exceptions:
;*******************************************************************************
CODESEG
% public strcat, strcpy ; make both functions available
strcpy proc
push edi ; preserve edi
mov edi,[esp+8] ; edi points to dest string
jmp short copy_start
strcpy endp
align 16
strcat proc
.FPO ( 0, 2, 0, 0, 0, 0 )
mov ecx,[esp+4] ; ecx -> dest string
push edi ; preserve edi
test ecx,3 ; test if string is aligned on 32 bits
je short find_end_of_dest_string_loop
dest_misaligned: ; simple byte loop until string is aligned
mov al,byte ptr [ecx]
add ecx,1
test al,al
je short start_byte_3
test ecx,3
jne short dest_misaligned
align 4
find_end_of_dest_string_loop:
mov eax,dword ptr [ecx] ; read 4 bytes
mov edx,7efefeffh
add edx,eax
xor eax,-1
xor eax,edx
add ecx,4
test eax,81010100h
je short find_end_of_dest_string_loop
; found zero byte in the loop
mov eax,[ecx - 4]
test al,al ; is it byte 0
je short start_byte_0
test ah,ah ; is it byte 1
je short start_byte_1
test eax,00ff0000h ; is it byte 2
je short start_byte_2
test eax,0ff000000h ; is it byte 3
je short start_byte_3
jmp short find_end_of_dest_string_loop
; taken if bits 24-30 are clear and bit
; 31 is set
start_byte_3:
lea edi,[ecx - 1]
jmp short copy_start
start_byte_2:
lea edi,[ecx - 2]
jmp short copy_start
start_byte_1:
lea edi,[ecx - 3]
jmp short copy_start
start_byte_0:
lea edi,[ecx - 4]
; jmp short copy_start
; edi points to the end of dest string.
copy_start::
mov ecx,[esp+0ch] ; ecx -> sorc string
test ecx,3 ; test if string is aligned on 32 bits
je short main_loop_entrance
src_misaligned: ; simple byte loop until string is aligned
mov dl,byte ptr [ecx]
add ecx,1
test dl,dl
je short byte_0
mov [edi],dl
add edi,1
test ecx,3
jne short src_misaligned
jmp short main_loop_entrance
main_loop: ; edx contains first dword of sorc string
mov [edi],edx ; store one more dword
add edi,4 ; kick dest pointer
main_loop_entrance:
mov edx,7efefeffh
mov eax,dword ptr [ecx] ; read 4 bytes
add edx,eax
xor eax,-1
xor eax,edx
mov edx,[ecx] ; it's in cache now
add ecx,4 ; kick dest pointer
test eax,81010100h
je short main_loop
; found zero byte in the loop
; main_loop_end:
test dl,dl ; is it byte 0
je short byte_0
test dh,dh ; is it byte 1
je short byte_1
test edx,00ff0000h ; is it byte 2
je short byte_2
test edx,0ff000000h ; is it byte 3
je short byte_3
jmp short main_loop ; taken if bits 24-30 are clear and bit
; 31 is set
byte_3:
mov [edi],edx
mov eax,[esp+8] ; return in eax pointer to dest string
pop edi
ret
byte_2:
mov [edi],dx
mov eax,[esp+8] ; return in eax pointer to dest string
mov byte ptr [edi+2],0
pop edi
ret
byte_1:
mov [edi],dx
mov eax,[esp+8] ; return in eax pointer to dest string
pop edi
ret
byte_0:
mov [edi],dl
mov eax,[esp+8] ; return in eax pointer to dest string
pop edi
ret
strcat endp
end
PE>Да при том, что С# и дотнет не является панацеей. Универсальность и дешевизна разработки. Но в некоторых областях производительность важнее.
Так оно и есть. Вот только оценка этих областей за частую не верная.
PE>>>Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.
VD>> 8 милисекунд будет более точной цифрой. Просто там кроме отслеживания еще много чего делается. А 8 сек. ЖЦ я в жизни не видел.
PE>Так профайлер говорит.
PE>>>Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф. PE>>>Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.
VD>>И есть эквивалентные реализации для дотнета и С++?
PE>Есть. Все писали мы. Искренне жаль, но конкурентов до прошлого года у нас не было.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Жирным отмечены точки, которые невозможно оптимизировать в силу некоторых особенностей. PE>SetValidatableProperty — автоматическая валидация. Тут рефлексия. PE>GetPropertyDescriptionMapInternal — создаются тучи делегатов. PE>set_Name — имя объекта должно быть уникальным, следовательно нужно сообщеть буде это не так.
А что означают в конкретные колонки?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение. PE>А нам чу что придется написать примерно такой же форматтер.
Это очень сложно. Он там на мертво врос.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
VD>>Вы их генерируете что ли?
PE>А как еще ? Из УМЛ в C# и вперед.
Да только генераторами можно зафигачить такое количество кода. При ручной реализации его на порядок меньше будет.
PE>С этого нужно было и начинать А то завеи разговор про панацею.
Да про панацею никто и не говорит. Но дать совет не зная внутренних проблем невозможно. А разбираться для этого еще с одной наукой — это крыза.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует,
Осталось определится в процентном соотношении таких как я и ты
PE> я не буду пользваться винампом, который перепишут полностью на дотнете.
Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.
AVK>>Ты часто рары и зипы пишешь? Я нет.
PE>С помощью раров и зипов меряется реальный перформанс процессоров.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?
PE>Вот предложи свой вариант на C# без дженериков.
Вариант не предложу, это все таки работа немаленькая, а вот какие то прикидки можно. Вот два примера простого мультикаст события и его аналога на интерфейсах. Вариант с событием разверну чтобы идея была понятнее.
public delegate SomeEventHandler(object sender, SomeEventArgs e);
public class EventProvider
{
private SomeEventHandler _someEvent;
public event SomeEventHandler SomeEvent
{
add
{
_someEventHandler += value;
}
remove
{
_someEventHandler -= value;
}
}
protected void OnSomeEvent(SomeEventArgs e)
{
if (_someEvent != null)
_someEvent(this, e);
}
}
public class EventConsumer
{
private EventProvider _eventProvider;
public EventConsumer(EventProvider ep)
{
_eventProvider = ep;
_eventProvider.SomeEvent += new SomeEventHandler(Handle);
}
~EventConsumer()
{
_eventProvider.SomeEvent -= new SomeEventHandler(Handle);
}
private void Handle(object sender, SomeEventArgs e)
{
// ...
}
}
Вариант с интерфейсом
public interface ISomeEventHandler
{
void Handle(object sender, SomeEventArgs e);
}
public class EventProvider
{
private ArrayList _eventConsumers = new ArrayList();
public void AddSomeEventHandler(ISomeEventHandler h)
{
_eventConsumers.Add(h);
}
public void RemoveSomeEventHandler(ISomeEventHandler h)
{
_eventConsumers.Remove(h);
}
protected void OnSomeEvent(SomeEventArgs e)
{
foreach (ISomeEventHandler h in _eventConsumers)
h.Handle(this, e);
}
}
public class EventConsumer : ISomeEventHandler
{
private EventProvider _eventProvider;
public EventConsumer(EventProvider ep)
{
_eventProvider = ep;
_eventProvider.AddSomeEventHandler(this);
}
~EventConsumer()
{
_eventProvider.RemoveSomeEventHandler(this);
}
void ISomeEventHandler.Handle(object sender, SomeEventArgs e)
{
// ...
}
}
В варианте с интерфейсом есть еще один плюс — ArrayList можно заменить на список с WeakReference, тем самым подписка на событие не будет блокировать работу GC.
PE>>>IConnectionPointContainer/IConnectionPoint AVK>>Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия. PE>Дело не в COM а в спосое взаимодействии клиентов.
Вот и давай про СОМ забудем.
AVK>>Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.
AVK>>Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?
PE>Класс, который реализует интерфейс обратной связи с другим объектом.
Не надо там никаких дополнительных классов. Класс-потребитель должен сам этот интерфейс реализовать.
PE>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова.
Это практически равносильно написанию обработчика события.
PE>Я имею в виду, что вначале нужно оптисаться от пары тройки уведомлений, а потом подписаться на все заново у другого объекта.
Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
PE>>>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!! AVK>>Значит что то не так. Причем явно не так.
PE>Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда.
Ах вон оно что. Значит навязали, а мы все равно пишем по старому .
AVK>>Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет. PE>Легко на маленьгких прилах. PE> А если алгоритм сутки работает ?
Ты что думаешь, один ты тут большие программы пишешь? У нас вот тоже сервер 24х7. Только там не один алгоритм а целое их море.
PE>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку.
AVK>В варианте с интерфейсом есть еще один плюс — ArrayList можно заменить на список с WeakReference, тем самым подписка на событие не будет блокировать работу GC.
Интересный момент. Где про это почитать можно ?
PE>>Дело не в COM а в спосое взаимодействии клиентов. AVK>Вот и давай про СОМ забудем.
А при чем здесь COM ? Я описываю в дотнете интерфейсы, который диктуют аналогичную функциональность. Вот и все. А с COM скрещивать я ничего не собираюсь.
PE>>Класс, который реализует интерфейс обратной связи с другим объектом. AVK>Не надо там никаких дополнительных классов. Класс-потребитель должен сам этот интерфейс реализовать.
Вот это я тебе и хотел показать.
PE>>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова. AVK>Это практически равносильно написанию обработчика события.
Вовсе нет. Интерфейс нужно объявлять полностью. А обработчики ты можешь вовсе опустить.
Еще нужна инициализация хитрая в конструкторах. С обработчиками этого нет.
PE>>Я имею в виду, что вначале нужно оптисаться от пары тройки уведомлений, а потом подписаться на все заново у другого объекта.
AVK>Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
А конструкторы ?
PE>>Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда. AVK>Ах вон оно что. Значит навязали, а мы все равно пишем по старому .
Нет. Мы пишет так, что бы избежать копипейста и генерации текста(коллекции, интерфейсы). Это самая главная проблема.
копи
ошибках нет. PE>>Легко на маленьгких прилах. PE>> А если алгоритм сутки работает ?
AVK>Ты что думаешь, один ты тут большие программы пишешь? У нас вот тоже сервер 24х7. Только там не один алгоритм а целое их море.
PE>>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку. AVK>К счастью на шарпе не сильно.
Что бы воспроивести ошибку может понадобиться писать скрипт на саксе ии руками кликать полчаса. Есть выход — винраннер подключить. Но для него тож скрипт нужен.
Здравствуйте, AndrewVK, Вы писали:
PE>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, AVK>Осталось определится в процентном соотношении таких как я и ты
Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
Видео — туда же. Математика — это, конечно, узкая область.
PE>> я не буду пользваться винампом, который перепишут полностью на дотнете. AVK>Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.
Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных. Ибо тормозное глюкало писать не хочется.
PE>>С помощью раров и зипов меряется реальный перформанс процессоров. AVK>И при чем тут перформанс процессора?
При том, что алгоритмы реальные и работают повсеместно, в отличие он синтетических шустриков.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, AVK>>Осталось определится в процентном соотношении таких как я и ты PE>Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
А причем тут пользователи? Речь о программистах.
AVK>>Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.
PE>Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных.
Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.
PE> Ибо тормозное глюкало писать не хочется.
Т.е. какие то компиляторы всегда делают тормозное глюкало?
PE>>>С помощью раров и зипов меряется реальный перформанс процессоров. AVK>>И при чем тут перформанс процессора?
PE>При том, что алгоритмы реальные и работают повсеместно,
Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>все это отлично. Только непонятно, что я буду делать вот в таком случае.
Честно говоря не понял в чем проблема.
PE>Интересный момент. Где про это почитать можно ?
В MSDN. Класс WeakReference
PE>>>Дело не в COM а в спосое взаимодействии клиентов. AVK>>Вот и давай про СОМ забудем.
PE>А при чем здесь COM ?
Вот и я о том же.
PE> Я описываю в дотнете интерфейсы, который диктуют аналогичную функциональность. Вот и все. А с COM скрещивать я ничего не собираюсь.
Тогда какое это имеет отношение к замене событий интерфейсами?
PE>>>Класс, который реализует интерфейс обратной связи с другим объектом. AVK>>Не надо там никаких дополнительных классов. Класс-потребитель должен сам этот интерфейс реализовать.
PE>Вот это я тебе и хотел показать.
При помощи еще одного класса? Странный однако ты выбрал способ сделать это.
PE>>>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова. AVK>>Это практически равносильно написанию обработчика события.
PE>Вовсе нет. Интерфейс нужно объявлять полностью.
Что значит объявлять полностью?
PE> А обработчики ты можешь вовсе опустить.
Не, чего то я тебя не пойму. Если тебе обработчики нужно опустить ты и интерфейс не реализуй.
PE>Еще нужна инициализация хитрая в конструкторах.
Что то в моем примере никакой хитрой инициализации нет. Ты о чем вобще?
AVK>>Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
PE>А конструкторы ?
Что конструкторы?
PE>>>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку. AVK>>К счастью на шарпе не сильно.
PE>Что бы воспроивести ошибку может понадобиться писать скрипт на саксе ии руками кликать полчаса.
Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.
PE> Есть выход — винраннер подключить.
Не знаю кто такой.
PE> Но для него тож скрипт нужен.
А вы как вобще отлаживаетесь? Или вы сразу без ошибок пишете?
Здравствуйте, AndrewVK, Вы писали:
PE>>>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, AVK>>>Осталось определится в процентном соотношении таких как я и ты PE>>Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
AVK>А причем тут пользователи? Речь о программистах.
Т.е. пользователи сук и быдло и не могут интесеваться производительностью ПО за которое платят деньги ?
Программисты пишут не просто так, а для конкретных людей.
PE>>Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных.
AVK>Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.
Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед.
Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?
PE>> Ибо тормозное глюкало писать не хочется. AVK>Т.е. какие то компиляторы всегда делают тормозное глюкало?
Конечно. Но не только компилеры. Среда тоже может "помочь".
PE>>При том, что алгоритмы реальные и работают повсеместно,
AVK>Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
Нужно перегнать DVD в MPEG4.
Ты платишь за время бабло — 3$ в час допустим.
И есть выбор в железе, в компилерах, в среде, в джите, если есть.
Задача — определить, на какой конфигурации можно получить минимальные временные затраты.
Вот и выбирай (P3, P4) (пямяти 256) (прага нативная, дотнетовская, жава)
1. Процессор кривой — время большое будет.
2. Среда кривая — время большое.
3. Компилер кривой — время большое.
4. Джит кривой — время большое.
Спасибо за просветление
