Здравствуйте, IT, Вы писали:
IT>Это не совсем так. Есть вещи, которые невозможно сделать без поддержки компилятора/среды. Например, в ООП это перегрузка методов, в FP замыкания.
Оба эмулируются даже на си.
И к тому и замыкания и перегрузка методов это не более чем вкусности, они не являются необходимыми чтобы программировать в соответствующем стиле.
Здравствуйте, IT, Вы писали:
ГВ>>FP — это стиль, ничего больше. ООП — тоже.
IT>Это не совсем так. Есть вещи, которые невозможно сделать без поддержки компилятора/среды. Например, в ООП это перегрузка методов, в FP замыкания.
Я бы сказал так: невозможно так же компактно записать, как при наличии компилятора с соответствующими возможностями.
Но я имел в виду другое. FP, ООП, СП — это всё стили структурирования предметной области. Если хочешь — подходы. Можно даже "парадигмами" назвать. От возможностей компилятора реализация этих подходов до какой-то степени зависит, но только до какой-то.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Тем не менее, мне ты продолжаешь твердить, что ASP.NET в целом — отстой. Мне как-то не очень хочется следить за раздвоениями личности и пытаться скомпоновать удобные мне утверждения из нескольких независимых постингов.
Вот ты там поправился, с этим все согласились. Потом ты продолжаешь сравнивать ASP.NET с PHP, при этом, похоже, имеешь в виду WebForms против XSLT.
Напомню, что ASP.NET всплыл не потому, что вебФормз. А потому, что Рихтер прикрутил к дотнету Power Threading Library, которая позволяет писать офигенно высокопроизводительный код, не слишком жертвуя читаемостью. И потому, что использование IO Completion Ports, которое Рихтер облегчил, крайне важно как раз в серверах массового обслуживания, в частности в веб серверах. В десктопном приложении лишний десяток потоков — тьфу, семечки. А в сервере каждый поток на счету; неэффективные примитивы синхронизации способны убить производительность куда быстрее, чем проверки выхода за границы массивов.
В свете этого набор используемых контролов не имеет никакого значения. Речь идет о том, что легко построить реализацию IHttpHandler, которая не блокирует поток из пула на время выполнения асинхронных операций. И вообще никакой не блокирует, в отличие от предлагаемой в MSDN реализации "Async Handler".
Здесь, конечно, никакого abstraction gain нету.
Аналогичную реализацию теоретически можно получить "на ассемблере". Вот только из местных апологетов микрооптимизаций ни один чего-то не спешит представить доказательство в студию. Всё больше рассуждают о теории. Поэтому я настаиваю на эквивалентной честности к обеим сторонам.
Потому, что теоретически abstraction gain таки не сводится к "голове". Я писал тут неподалеку, каким именно способом абстрактный код может обгонять ассемблер.
Суперкомпилятор, кстати, к этой теории отношения не имеет (в отличие от HotSpot). Потому, что результат суперкомпилятора — это один хрен некоторая "жесткая" программа, которую можно превратить в ассемблер и забыть про суперкомпилятор. А супероптимизатор обязан работать в рантайме, чтобы подстроиться под фактическую платформу и условия задачи и обогнать ассемблер.
Да, опять же к слову: всякие предположения типа "а если платформа ровно одна и заведомо не изменится" нужно делать очень осторожно. Ты как-то задавал такой вопрос. Ну так надо уточнить, что понимается под "одной платформой". Если это встраиваемый контроллер — то да, перспективой смены платформы нужно пренебречь. Ну, и, для супероптимизатора может тупо не хватить ресурсов, и придется все оптимизации делать статически (что, в свою очередь, возможно вручную).
А если мы говорим об этом в том смысле, как имеет в виду Дворкин ("платформа у нас одна — win32"), то это просто ламерство. Потому, что оптимальные алгоритмы синхронизации сильно отличаются для, к примеру, одноядерного процессора, HT, и многопроцессорной машины. В итоге, код, скомпилированный в расчете на одну архитектуру, будет сосать на другой. А код, оборудованный рантайм-проверками, будет сливать коду, который динамически компилируется с высокого уровня в низкий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Почему? Как разница на чем в "солитер" играть?
В Quake не поиграешь
ВВ>>>А с какими "гигантами" работает большинство? Это крупные предприятия, банки и пр. Ну не 100, но тысячи человек. PD>>Маловато
ВВ>Да уж, прям так маловато
Не мои масштабы
ВВ>Разработка софта — это коммерческий продукт. Такой же как тушь для ресниц или автомобили. Разве нет? Ты в любом случае упрешься в маркетинг, это нормально.
Да, но это не ко мне. Пусть заказчик этим занимается, а с меня и программирования хватит
ВВ>Даже как человек не слишком-то близкий к собственно бизнесу я в первую очередь определяю, что нам выгоднее будет продать. А потом уже идет архитектура, проблемы написания кода и проч.
Это все не мои проблемы. Я получаю задачу и решаю ее. Все. Я только программист
ВВ>>>Железо купить дешевле.
PD>>Ну это я уже не понимаю. Я тебе привел конкретный числовой пример, где дополнительное железо стоит $80К, а я (допустим) могу сделать так, чтобы оно не потребовалось. А ты опять — железо дешевле. Если так — бери меня на работу и плати $80K в месяц
ВВ>Потом, что за программа такая? Клиентское приложение, разворачивается на всех компах фирмы?
Почти
>Мы опять получается о какой-нибудь специфической нише говорим.
И даже очень
>Я тебе много раз уже говорил, что согласен с тем, что такие задачи есть, что есть такие приложение и пр. Только есть и другие приложения. И это не только всякие там веб-сайты да хоум-пейджи.
А я и не спорю, что они есть. И ты согласен, что и другие есть. Мы оба согласны друг с другом
ВВ>А в общем случае мне вообще сложно представить, что за приложение должно быть такое, что у него требования будут зашкалировать по сравнению, скажем, с Office 2007
Ну я же тебе привел пример с обработкой матриц 5000 * 5000. Куда там офису, у него загрузка процессора большую часть времени близка к 0, а у меня (вот сейчас как раз смотрел — около 60%-70% на двухядерном проце все время. Мало. Буду думать, как до 90 хотя бы довести.
ВВ>>>Да не выгоднее. Никто не разрабатывает "уникальные" программы с повышенными требованиями к железу. PD>>Я. И еще какие повышенные требования!
ВВ>Ну да ради бога, только ты в меньшистве.
А мне в меньшинстве совсем не плохо . Во всяком случае конкурентов гораздо меньше — это у вас можно заменить ну пусть не любого, но многих. А меня гораздо труднее заменить
ВВ>И что? Какие в большинстве случаев ты представляешь задачи для обработки информации, что с ними никак не справляется железо?
Я же тебе говорил про матрицы уже не раз. Ну не хочу я раскрывать суть задачи
ВВ>P4 Quad — это что? Четырехядерный пентиум 4?
Да. У заказчика есть еще и 8-ядерный.
ВВ>Упоминание NVidia 8,9 — это или 3D или [censored] математика.
Нет, это не математика. Это распараллеливание обработки. Под видом видеокарты там фактически матричный процессор на 512 аппаратных потоков. См. CUDA.
>Ну по поводу 3D я и сам согласен, а [censored] математика она на то и [censored].
К 3D моя задача отношения не имеет, а математика там простенькая.
>>>И считаешь, что это будет дешевле? PD>>Я же привел расчет. Ты его опровергнуть можешь ?
ВВ>Я тебе еще раз говорю — компания за месячную разработку возьмет больше.
За разработку какого-нибудь простенького сайта , используя существующий фреймворк и посадив 2-3 программиста на месяц, компания получит >80 K ? Из них она пусть $10K заплатит программистам, а остальное себе возьмет ? Если так, то это грабеж среди бела дня. Но что-то сомнительно...
А впрочем, компания — ладно, ты лучше мне $80K заплати
ВВ>>>Ну да. BP вот религия позволяет сервера у IBM парковать. Видимо, там "веб-программисты" руководящие посты занимают PD>>Религия может что угодно позволять, но то, что Газпром свои конфиденциальные данные разместит на сервере , находящемся в США — извини, не поверю.
ВВ>И правда — IBM периферийная контрола с одним офисом в США. И весь небось серверами завален.
Не понял юмора. Хоть где у них офисы, даже в России, все равно там Газпром ИМХО свои конфиденциальные данные хранить не будет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я, видимо, неточно выразился. Я имел в виду, не то, сольются ли они технически, а сольются ли в массовом масштабе.
AVK>Смотря что понимать под массовым масштабом.
Ну хотя бы общедоступность в городах с населением от 200,000. Общедоступность на том же уровне, как сейчас в них доступно обычное ТВ.
PD>> Иными словами, закончится ли зоопарк ОС на мобильниках переходом к некоей ОС, единой для мобильников и настольных (или как минимум неким интеграционным пакетом).
AVK>При чем тут ОС? И что такое интеграционный пакет? Давным давно проблемы написания разного софта определяются не ОС и загадочными пакетами (и линух для мелких дивайсов давно доступен, и WM твой любимый Win32 предоставляет в очень приличном объеме), а принципиальными ограничениями железа, размером экрана прежде всего и разными моделями применения (наличие тачскринов, GPS, но при этом отсутствие быстрых и скоростных дисков).
Что такое интеграционный пакет -я и сам не знаю, а имею в виду я просто следующее. Сажусь я за любую машину с Windows — и мне сразу ясно, что делать. Вот и на мобильниках должно быть то же самое. А сейчас каждый из них изучать надо. И, скажем, связь между ними и PC — тоже не всегда тривиальна. Я для своего мобильника кабель по всему Омску искал, нет, говорят, под такой разъем,а когда наконец нашел — он инсталлироваться не захотел
1. Не суди по своему уровню, а суди по уровню массового пользователя.
2. Не суди по Москве.
PD>> А про телевидение — — останется ли вариант "вещания" или выживет только вариант "запроса" ?
AVK>Останется.
Опять-таки вопрос — соотношение между. Если только для медвежьих уголков (впрочем, спутники есть) — это одно. Если оно останется в массовом масштабе — другое.
Здравствуйте, gandjustas, Вы писали:
G>Пустая риторика, низачот.
. Зачеты я только сам ставлю, от других не принимаю
G>Напряги свои знания WinAPI, может впомнишь что есть функция считывание всего битмапа из DC, что будет гораздо быстрее считывания отдельных пикселей.
Нет функции считывания битмапа из DC. Нету такой, уважаемый. Есть функция, выбирающая битмап в DC (SelectObject). Есть функция, возвращающая текущий в DC битмап (GetCurrentObject). И знаешь почему нет ? Потому что в DC нет битов, а есть они в битовой карте только.
Ну а если речь шла о том, что можно , имея HDC, получить HBITMAP и GetBitmapBits, то это верно. И действительно будет быстрее. Но посмотри мой исходный постинг с первоначальной программой, я там извинился за использование GetPixel. Это специально было сделано, чтобы продемонстрировать распараллеливание при одновременном обращении потоков к нулевому кольцу.
G>Меня эти понятия. Мне достаточно сравнить два числа. G>Если тебе для сравнения двух чисел надо привлекать матстатистику, то мне тебя очень жаль.
Уф! Ну как еще объяснять ? Не знаю. Не хватает моих педагогических способностей. Человеку говоришь — для сравнения двух приближенных чисел, полученных как результаты измерений, необходимо учитывать точность измерений. А он в ответ — да не надо, и так можно. В общем, 8.000001 всегда больше чем 8.00000, даже если точность измерения плюс-минус 0.001
Здравствуйте, Константин Б., Вы писали:
PD>>Можно ссылочку на источник, где говорится, что они вызывают BitBlt ? Куда она копирует ? Где второй HDC ? КБ>http://www.rsdn.ru/res/book/mmedia/yuan.xml
Ссылку дают на конкретный текст, а не на оглавление какой-то книги. Пожалуйста, ссылку на то место, где сказано, что GetPixel вызывает BitBlt. Дело в том. что это чушь.
>>>Напрямую получить весь массив с той же BitBlt гораздо быстрее.
PD>>BitBlt все-таки копирует битовую карту , а вовсе не возвращает биты. А получить биты можно, GetBitmapBits / GetDIBIts, но это совсем другая история КБ>Вот копируем на off-screen DC и оттуда забираем биты. Вы что первый раз c GDI работаете?
Я с ним лет так 20 работаю, а вот ты, похоже, даже с понятиями не разобрался как следует. Нет на DC битов. Они есть в битовой карте, выбранной в этом DC (а впрочем, и в битовой карте, не выбранной ни в каком DC). Поэтому биты карты (если уж не через GetPixel работать), можно получить из этой карты (GetBitmapBits,GetDIBits или даже GetObject с DIBSECTION, если, конечно, это дибсекция). Что же касается BitBlt, то она копирует эти биты из битовой карты, выбранной в одном DC, в битовую карту, выбранную в другом DC, и при этом никакие биты не возвращает (нам), поскольку не ее дело. Вот и все. Учите матчасть!
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Да не выгоднее. Никто не разрабатывает "уникальные" программы с повышенными требованиями к железу. PD>>Я. И еще какие повышенные требования! ВВ>Ну да ради бога, только ты в меньшистве.
О! Вот она — сила логики!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
PD>>Очень дешевый прием, ты уж меня извини.
AVK>Дешевый примем это свалить в кусты вместо признания собственной неправоты.
М-да. Сначала мне предлагают в ультимативном порядке написать некоторую программу, что само по себе не есть особо вежливое действие. Когда я этого не делаю, мне заявляют, что я , мол, и не мог ее написать, а вместо этого свалил в кусты. Чудная логика.
Впрочем, спроецируй на себя. Представь себе, что я что-то утверждаю , а ты с этим не согласен (было такое ? . Ну вот, в ответ я требую от тебя в ультимативной форме что-то написать. Будешь ?
А вообще-то раньще в этом отношении нравы были более разумными. Когда вызывали на дуэль — право выбора оружия предоставлялось всегда тому, кого вызывали. Так что уж если от меня требуют участия в каком-то соревновании — право выбора теста за мной .
Здравствуйте, IT, Вы писали:
M>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ? IT>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.
Докажи.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Константин Б., Вы писали:
PD>>>Можно ссылочку на источник, где говорится, что они вызывают BitBlt ? Куда она копирует ? Где второй HDC ? КБ>>http://www.rsdn.ru/res/book/mmedia/yuan.xml
PD>Ссылку дают на конкретный текст, а не на оглавление какой-то книги. Пожалуйста, ссылку на то место, где сказано, что GetPixel вызывает BitBlt.
Когда вам дают ссылку, надо сказать "Спасибо, обязательно ознакомлюсь.". А если вы решили что я собираюсь с вами спорить, то вы ошиблись. Можете и дальше писать тормозной код с использованием GetPixel.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>Напряги свои знания WinAPI, может впомнишь что есть функция считывание всего битмапа из DC, что будет гораздо быстрее считывания отдельных пикселей.
PD>Нет функции считывания битмапа из DC. Нету такой, уважаемый. Есть функция, выбирающая битмап в DC (SelectObject). Есть функция, возвращающая текущий в DC битмап (GetCurrentObject). И знаешь почему нет ? Потому что в DC нет битов, а есть они в битовой карте только. PD>Ну а если речь шла о том, что можно , имея HDC, получить HBITMAP и GetBitmapBits, то это верно.
Это и надо, детали не волнуют.
PD>И действительно будет быстрее. Но посмотри мой исходный постинг с первоначальной программой, я там извинился за использование GetPixel. Это специально было сделано, чтобы продемонстрировать распараллеливание при одновременном обращении потоков к нулевому кольцу.
На любом надуманном примере можно показать что угодно.
G>>Меня эти понятия. Мне достаточно сравнить два числа. G>>Если тебе для сравнения двух чисел надо привлекать матстатистику, то мне тебя очень жаль.
PD>Уф! Ну как еще объяснять ? Не знаю. Не хватает моих педагогических способностей. Человеку говоришь — для сравнения двух приближенных чисел, полученных как результаты измерений, необходимо учитывать точность измерений. А он в ответ — да не надо, и так можно. В общем, 8.000001 всегда больше чем 8.00000, даже если точность измерения плюс-минус 0.001
Не надо разводить демагогию без конкретных чисел. Какова погрешность измерения Time Stamp Counter? Какая разница значений будет на измеряемом коде?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Константин Б., Вы писали:
PD>>>Можно ссылочку на источник, где говорится, что они вызывают BitBlt ? Куда она копирует ? Где второй HDC ? КБ>>http://www.rsdn.ru/res/book/mmedia/yuan.xml
PD>Ссылку дают на конкретный текст, а не на оглавление какой-то книги. Пожалуйста, ссылку на то место, где сказано, что GetPixel вызывает BitBlt. Дело в том. что это чушь.
Глава 7. Пикселы.
Страница 417
Разобраться в том, как реализованы функции вывода пикселов, особенно интересно, поскольку речь идет о самой простой графической операции. Кроме
того, это поможет вам лучше понять, с какими затратами связано выполнение некоторых графических команд в GDI.
В Windows NT/2000 обе функции, SetPixel и SetPixelV, обслуживаются одной и той же системной функцией _NtGdiSetPixel@16, вызываемой после проверки параметров по манипулятору контекста устройства. Имя _NtGdiSetPixel016 означает, что при вызове функции передаются четыре параметра. При этом инициируется программное прерывание, которое обрабатывается одноименной функцией механизма GDI режима ядра (win32k.sys). Функция ядра NtGdiSetPixel блокирует контекст устройства, отображает логические координаты в физические, выполняет простую проверку границ, при необходимости преобразует COLORREF в индекс и вызывает функцию драйвера DrvBitBlt (если она поддерживается) или функцию EngBitBlt. При необходимости цветовое значение транслируется в формат RGB. Перед возвращением из функции контекст устройства разблокируется.
Функция GetPixel обрабатывается системной функцией _NtGdiGetPixel012. Эта функция создает временный растр и копирует в него пиксел вызовом DrvCopyBits/EngCopyBits.
Главное, на что необходимо обратить внимание в этой процедуре — это быстродействие. Для каждого вызова GetPixel, SetPixel или SetPixelV графическая система должна инициировать программное прерывание, переключиться в режим ядра и обратно, отобразить координаты, преобразовать индекс палитры, постро
ить временный растр и затем вызвать функцию блиттинга драйвера устройства. Для одного пиксела объем работы получается довольно большим.
Да память меня немного подвела. Это SetPixel работает через BitBlt. GetPixel работает через CopyBits.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну хотя бы общедоступность в городах с населением от 200,000. Общедоступность на том же уровне, как сейчас в них доступно обычное ТВ.
Россия в этом плане понятие отдельное ввиду территории, но и в ней услуги triple play доступны во многих городах уже сейчас.
PD>Что такое интеграционный пакет -я и сам не знаю, а имею в виду я просто следующее. Сажусь я за любую машину с Windows — и мне сразу ясно, что делать. Вот и на мобильниках должно быть то же самое.
Что "то же самое"? Наличие небольшого количества стандартных операционок? Так уже давно. Наличие идентичных с десктопом программ? Невозможно в принципе.
PD> И, скажем, связь между ними и PC — тоже не всегда тривиальна. Я для своего мобильника кабель по всему Омску искал, нет, говорят, под такой разъем,а когда наконец нашел — он инсталлироваться не захотел
У тебя смартфон? Если нет, то при чем тут компьютеры?
PD>1. Не суди по своему уровню, а суди по уровню массового пользователя.
Масовый пользователь в этом плане намного круче меня. У меня мобильнику 2.5 года и менять ы обозримом будущем я его не собираюсь.
PD>2. Не суди по Москве.
У меня в профиле город, вроде как, указан.
PD>Опять-таки вопрос — соотношение между. Если только для медвежьих уголков (впрочем, спутники есть) — это одно.
Нет, не только для них. Старые телепреемники есть в огромных количествах. За 10 лет полного изменения ситуации не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Константин Б., Вы писали:
КБ>Когда вам дают ссылку, надо сказать "Спасибо, обязательно ознакомлюсь.". А если вы решили что я собираюсь с вами спорить, то вы ошиблись. Можете и дальше писать тормозной код с использованием GetPixel.
Мне кажется споришь именно ты, человек уже десять раз объяснил зачем именно он использовал GetPixel
А, ну так это ж бубль-гум!
Классический пример того, что Lazy Load — великое зло. Если бы парни воспользовались именно Join, а не дурацкими хинтами "дай мне всё", то всё получилось бы гораздо лучше
_>Когда есть join'ы надо быть с LINQ очень аккуратным.
Точнее, когда их нет. Когда начинаются игры с навигационным доступом — велкам ту хелл.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Тем не менее, мне ты продолжаешь твердить, что ASP.NET в целом — отстой. Мне как-то не очень хочется следить за раздвоениями личности и пытаться скомпоновать удобные мне утверждения из нескольких независимых постингов. S>Вот ты там поправился, с этим все согласились.
Тем не менее продолжается обсуждение в защиту веб-формс.
S>Потом ты продолжаешь сравнивать ASP.NET с PHP, при этом, похоже, имеешь в виду WebForms против XSLT.
А ты под АСП.НЕТ понимаешь все прелести, которые дает стандартная библиотка? Для меня если я разрабатываю приложение используя лишь низкоуровневые надстройки над ИЗАПИ — то не АСП.НЕТ. А АСП.НЕТ для меня эквивалентен веб-формс. Возможно, это неверное утверждение, но тогда это уже получается спор о терминах, который бесперспективен.
Большинство асп.нет приложений сейчас разрабатываются именно на веб-формс. И веб-формс как раз пример той самой абстракции, — по сравнению с более "традиционными" технологиями вроде ПХП (к-й кстати не столь уж и убог как может показаться) — которая не только не помогает, но — если задачи несколько отличаются от тривиальных — только усложняют жизнь. Для меня это пример случая, когда abstraction gain очевидно нету.
К тому же МС сама ведь не позиционирует веб-формс (по кр. мере до недавнего времени) как средство для конструирования хоум-пейджей — это блин энтерпрайз левел технология. И сама разрабатывает на ней приложения именно такого "левела". Что из этого получается, я уже неоднократно писал.
У меня вот перед глазами есть два примера — МОСС внедренный в одной немаленькой компании и портал собственной разработки, внедренный в совсем не маленькой компании, архитектуру которого я разрабатывал 3.5 года назад. Да, там дотнет 1.1, а не ПХП. Решают они примерно одинаковые задачи, хотя конечно же совокупные возможности МОСС заметно превосходят нашу разработку — "лицо интранета", быстрое конструирование портальных сайтов, CMS, всякие там орг. структуры, простенькое хранилище документов ну и разумеется интеграция в портал существующих и новых веб-приложений. И я прекрасно вижу во что это выливается в одном и другом случае. И сколько времени уходит на МОСС.
S>Напомню, что ASP.NET всплыл не потому, что вебФормз. А потому, что Рихтер прикрутил к дотнету Power Threading Library, которая позволяет писать офигенно высокопроизводительный код, не слишком жертвуя читаемостью. И потому, что использование IO Completion Ports, которое Рихтер облегчил, крайне важно как раз в серверах массового обслуживания, в частности в веб серверах. В десктопном приложении лишний десяток потоков — тьфу, семечки. А в сервере каждый поток на счету; неэффективные примитивы синхронизации способны убить производительность куда быстрее, чем проверки выхода за границы массивов.
Все это прямого отношения к вебу не имеет. И почему казалось бы тут "всплыл" асп.нет?
S>Здесь, конечно, никакого abstraction gain нету. S>Аналогичную реализацию теоретически можно получить "на ассемблере". Вот только из местных апологетов микрооптимизаций ни один чего-то не спешит представить доказательство в студию. Всё больше рассуждают о теории. Поэтому я настаиваю на эквивалентной честности к обеим сторонам. S>Потому, что теоретически abstraction gain таки не сводится к "голове". Я писал тут неподалеку, каким именно способом абстрактный код может обгонять ассемблер.
Это как раз и говорит о том, что в голове. В голове не значит, что его нет. В голове значит, что это "человеческий" фактор. Конечно же, если упираться в "крайние" примеры — то тут можно сказать только то, что "на ассемблере" их не только нельзя сделать более эффективно, но вообще чисто физически нельзя сделать.
А вот интересные примеры появляются, когда речь далеко не об ассемблере и не о разработке на нем асп.нет приложения, а о куда более приземленных вещах вроде веб-формс.
S>А если мы говорим об этом в том смысле, как имеет в виду Дворкин ("платформа у нас одна — win32"), то это просто ламерство.
Здравствуйте, FR, Вы писали:
IT>>Это не совсем так. Есть вещи, которые невозможно сделать без поддержки компилятора/среды. Например, в ООП это перегрузка методов, в FP замыкания.
FR>Оба эмулируются даже на си.
Эмулируй.
FR>И к тому и замыкания и перегрузка методов это не более чем вкусности, они не являются необходимыми чтобы программировать в соответствующем стиле.
А этот топик о чём? Именно о вкусностях. А ты о чём думал?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Но я имел в виду другое. FP, ООП, СП — это всё стили структурирования предметной области. Если хочешь — подходы. Можно даже "парадигмами" назвать. От возможностей компилятора реализация этих подходов до какой-то степени зависит, но только до какой-то.
От компилятора это зависит ровно до той степени будут эти стили использоваться или нет. Те же лямбды в C# 3.0 являются чистым сахаром над анонимными методами C# 2.0. И надо же, о чудо, их стали использовать широко и повсеместно. Делегаты таким похвастаться не могли. Ещё пример про стиль? Пожалуйста. Сейчас много говорят о параллельном программировании, о том, что если писать в соответствующем стиле, то компиляторы смогут автоматически распараллеливать выполнение задачи. Я об immutable стиле написания кода. Так вот. В C# нет средств заставить программиста писать код в таком стиле, а в том же Nemerle это делается по умолчанию. В результате после небольшой настройки мозгов immutable код на Nemerle получается сам собой. А вот на C# так стараться делать не будет никто и никогда. Компилятору по барабану, а уж программистам тем более.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
