Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да дело даже не в видео-памяти.
Пример оказался неудачным? Я так понимаю, насчет уровня абстракции и прямого доступа к памяти больше вопросов нет?
ВВ> Если даже рассматривать только PC как платформу, то мне кажется
А мне нет.
ВВ> Мне кажется, в таком случае выжать соки из железа совсем не получится.
А мне нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
FR>>>Утверждалось то что выделено, а это неправда. G>>В контексте разработки 3d движков очень даже правда. FR>В этом контексте тоже неправда, доступ к видеопамяти без проблем доступен и из D3D FR>IDirect3DVertexBuffer9::Lock
Это память вертекс-буффера. Из .NET можно с такими буфером работать.
FR>>> FR>>>Я писал эти алгоритмы так что не надо теоретических ихвышлений, одна только оптиизация мапов под память у меня дала больше 50% выигрыша. G>>Значит до этого алгоритм далеко неоптимальный был. FR>Тут уже выше был аналог моей ситуации суммирование массива по строкам и столбцам занимает разное время. FR>Алгоритм при этом не меняется. У меня менялись аллокоторы памяти и была сделана локализация доступа. G>>Я имел счатье один раз оптимизировать на ассемблере код, скомпилированный на C. При всех выкрустах удалось вытянуть только 20% процентов. Потом поменяли алгоритм и получили прирост в 2 с чем-то раза. FR>Алгоритм не всегда можно поменять.
G>>>>Уже сейчас есть возможность написать на F# код, который будет выполняться как на CPU, так и на видеокарте. В неуправляемой среде можно сделать такое? FR>>>Конечно какая разница управляемый код или нет, это ничем ни отличается от написания любого транслятора. G>>Ну напишите транслятор С++ или его подмножества в язык шейдеров. FR>А зачем мне писать подмножество C++ на C++ может мне инетереснее подмножество Ocaml'ана этом же самом Ocaml'е. FR>И давай не виляй покажи преимущества именно управляемого кода в этом вопросе.
Еще раз: сейчас таких преимуществ не увидете. Большенство технологий, позволяющих получить значителньный прирост производительности, еще сырые. Но потенциал очень большой, надеюсь его будут использовать.
FR>>>Угу, вот поэтому успеха NET там долго не будет. G>>Да, только "там" постоянно сокращается. FR>В этом конкретном "там" и не думает сокращатся.
Цифры в студию.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А теперь представим, что мы не только хотим написать движок на дотнете, но и сделать его более "абстрактным", упростить модификацию и добавление новых фич... Мне кажется, в таком случае выжать соки из железа совсем не получится.
Почему?
Здравствуйте, gandjustas, Вы писали:
ВВ>>А теперь представим, что мы не только хотим написать движок на дотнете, но и сделать его более "абстрактным", упростить модификацию и добавление новых фич... Мне кажется, в таком случае выжать соки из железа совсем не получится. G>Почему?
Ну соки-то ты, конечно, выжмешь, но результат может оказаться не таким уж впечатляющим. Зачем вводить дополнительный оверхед, прямым образом влияющий на ресурс, которого и так не хватает?
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Да дело даже не в видео-памяти. AVK>Пример оказался неудачным?
Да как скажете. Хотя вопрос, каким образом будет осуществляться эффективная работа с видео-девайсом без MDX, по-прежнему остался.
AVK>Я так понимаю, насчет уровня абстракции и прямого доступа к памяти больше вопросов нет?
Здравствуйте, gandjustas, Вы писали:
G>Это память вертекс-буффера. Из .NET можно с такими буфером работать.
Конечно можно только это уже будет unsafe или будет оверхед
FR>>А зачем мне писать подмножество C++ на C++ может мне инетереснее подмножество Ocaml'ана этом же самом Ocaml'е. FR>>И давай не виляй покажи преимущества именно управляемого кода в этом вопросе. G>Еще раз: сейчас таких преимуществ не увидете. Большенство технологий, позволяющих получить значителньный прирост производительности, еще сырые. Но потенциал очень большой, надеюсь его будут использовать.
Угу все ясно
FR>>В этом конкретном "там" и не думает сокращатся. G>Цифры в студию.
NET доступен на одной приставке которая отнюдь не доминирует на рынке, при этом даже на этой приставке он позиционируется как средство разработки небольших малобюджетных проектов. Срок жизни приставок 5 — 7 лет, так что ближаюшую пятилетку вряд-ли что существенно поменяется.
Здравствуйте, Воронков Василий, Вы писали: ВВ>Я никогда и не писал, что "теоретического ассемблерщик" всех порвет по производительности. А писал, кстати, прямо противоположное. Ни с кем меня не путаете?
Ну вот я и удивился, что это ты вдруг переключился с критики ассемблера на критику abstraction.
ВВ>А может, стоит вообще забыть об ассемблере? Речь изначально о том, всегда ли есть abstraction gain, как вы говорите.
Я еще раз повторяю: изначально о "всегдашности" abstraction gain никто, кроме тебя, не говорил. Очень удобно приписать собеседнику ложное утверждение и потом его развеивать.
ВВ>"Программирование мышкой" — это практика, которая неизбежно влияет на квалификацию программиста.
Ничего подобного. На квалификацию программиста влияет не способ программирования, а те задачи, которые он решает.
Я провел под Delphi несколько не самых плохих лет. Никаких тяжких последствий VCL на себе не ощущаю. Что я делал не так?
Наверное, я мало пользовался стандартными контролами, зато много писал своих. Много читал исходников VCL и занимался отладкой.
ВВ>А объем кода, который необходимо писать вручную, в случае с АСП.НЕТ все равно остается немаленький, стоить лишь только отойти от стандартного способа работы с компонентами, что случается довольно часто.
Это у вас от незнакомства с предметом. Вся прелесть аспнета — в его сквозной интегрированности и расширяемости. Совершенно необязательно выбрасывать его целиком: можно расширять его ровно в нужном месте. Вот, к примеру, тот же MVC Framework. Он совершенно не требует отказа от WebForms. У тебя полприложения может быть написано на говнопостбеках, а половина — на MVC. И всё вместе будет прекрасно работать; будут работать SiteMapProviders, MembershipProvider, безопасность, логгирование, и прочее.
Вот, в частности, если у тебя вырисовывается свой фреймворк, к примеру, основанный на XML/XSLT, то можно наколбасить BuildProvider и вместо того, чтобы лепить однообразные хэндлеры, получить минимум лишнего кода, и при этом прекрасную производительность. Что там PHP от жизни хотел?
ВВ>При этом получается забавная ситуация, что среднестатистический асп.нет-чик может не знать ни базовые вещи по работе с HTTP, не уметь работать с джава-скриптом и пр. Я человек сто наверное прособеседовал, так что можно уже статистику составлять.
Меня совершенно не волнуют проблемы среднестатистических дотнетчиков. Меня волнуют возможности, предоставляемые движком тем, кто знает HTTP и умеет работать с JavaScript, DOM, CSS и так далее.
ВВ>А в чем проблема? Ты пробовал и получилось слишком медленно? ВВ>А то!
И что являлось "бутылочным горлышком"?
Как что? То, что в PHP невозможно закэшировать XsltCompiledTransform, конечно же. ВВ>Типа база летала, странички были заоптимизированы, скрипты клиентские не тормозили, а тормозил конкретно интерпретируемый PHP? ВВ>А что с "количеством" кода? Надо много писать, чтобы вызвать XSLT-преобразование? В каких конкретно частях системы, при решение каких задач пришлось писать много кода?
Отсутствие Build Providers требует всякий раз приседать вручную для вызова XSLT. Отлаживать всё это крайне неудобно, особенно когда есть цепочка из XSLT преобразований. ВВ>>>Я так смотрю хамство — это нынче модный тренд на RSDN.
S>>При том, что ASP.NET — лучший в мире фреймворк для веб-приложений. ВВ>Угу, при архитектуре, которая ущербна изначально. В каком страшном мире мы живем
А какие претензии к архитектуре ASP.NET? Вот только не надо мне рассказывать про мышку и стандартные контролы. Это не архитектура, а самый верхний её слой.
Вон какой-нибудь супермодный Джанго в Питоне архитектурно на порядок хуже ASP.NET, именно из-за чрезмерной жесткости и заточенности под конкретное убогое применение.
ВВ>Даже если он и лучший, это никак не отменяет того факта, что ASP.NET — [censored].
С таким фактом я не знаком.
Демагогия поскипана.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Это память вертекс-буффера. Из .NET можно с такими буфером работать. FR>Конечно можно только это уже будет unsafe или будет оверхед
Тем не менее это не видеопамять.
FR>>>В этом конкретном "там" и не думает сокращатся. G>>Цифры в студию.
FR>NET доступен на одной приставке которая отнюдь не доминирует на рынке, при этом даже на этой приставке он позиционируется как средство разработки небольших малобюджетных проектов. Срок жизни приставок 5 — 7 лет, так что ближаюшую пятилетку вряд-ли что существенно поменяется.
Ну-ну, за последние 7 лет много чего изменилось.
Здравствуйте, Sinclair, Вы писали:
ВВ>>А может, стоит вообще забыть об ассемблере? Речь изначально о том, всегда ли есть abstraction gain, как вы говорите. S>Я еще раз повторяю: изначально о "всегдашности" abstraction gain никто, кроме тебя, не говорил. Очень удобно приписать собеседнику ложное утверждение и потом его развеивать.
ВВ>>"Программирование мышкой" — это практика, которая неизбежно влияет на квалификацию программиста. S>Ничего подобного. На квалификацию программиста влияет не способ программирования, а те задачи, которые он решает. S>Я провел под Delphi несколько не самых плохих лет. Никаких тяжких последствий VCL на себе не ощущаю. Что я делал не так? S>Наверное, я мало пользовался стандартными контролами, зато много писал своих. Много читал исходников VCL и занимался отладкой.
Инструмент создается под задачи, а задачи придумываются для инструмента. И речь, наверное, не конкретно о тебе, а об общей картине, которую я себе представляю.
ВВ>>А объем кода, который необходимо писать вручную, в случае с АСП.НЕТ все равно остается немаленький, стоить лишь только отойти от стандартного способа работы с компонентами, что случается довольно часто.
S>Это у вас от незнакомства с предметом.
А может быть наоборот? Излишняя лояльность к ASP.NET от недостаточно полного знакомства с ним?
Кстати, мне интересно, переключение на личность собеседеника теперь "узаконенный" прием? Я теперь могу в дискуссии писать в стиле — "Любишь ООП? Это от незнакомства с предметом"?
S>Вся прелесть аспнета — в его сквозной интегрированности и расширяемости.
Расширяемость хороша, когда сама по себе платформа архитектурно удачна. Если платформа архитектурно неудачна, что мне от ее расширяемости?
S>Совершенно необязательно выбрасывать его целиком: можно расширять его ровно в нужном месте. Вот, к примеру, тот же MVC Framework. Он совершенно не требует отказа от WebForms.
А должна бы требовать.
Потом я не понимаю — зачем нужен очередной велосипед? Microsoft никак не может опуститься до реализации уже существующих стандартов?
S>У тебя полприложения может быть написано на говнопостбеках, а половина — на MVC.
А зачем это? Зачем мне "говнопостбеки"? Я должен устроить зоопарк в своем приложении, только потому что технология эта позволяет?
Сама архитектура WebForms ушербна для веб-приложения, что весьма живописно себя показывает в более или менее сложных проектах. Потому что, я уже сотый раз повторяю, веб-приложение не должно иметь архитектуру аналогичную вин-приложению. То, что хорошо в вин-формах и служит прекрасной замене какой-нибудь карте сообщений, на вебе может оказаться не такой уж и хорошей идеей.
Сама концепция контролов вообще — а не какие-то контролы в частности — ущербна. На вебе не нужны контролы, нужен гибкий метаязык для описания представления веб-страницы. Сама концепция построения веб-страниц кардинально отличается от вин-формс, и использовать те же принципы по крайней мере странно. "Шаблоны", которыми пытаются казаться веб-контролы, быстро превращаются в кучу HTML-разметки, стоить лишь чуть-чуть сойти с проторенной дорожки.
Модель сохранения состояния ущербна.
Модель событий, завязанная на состоянии, так хорошо работающая в вин-формс, ущербна также. Про аякс, прикрученный к веб-формах, даже говорить не хочется.
Что есть в веб-формах такого ценного, что стоило бы "сохранять"?
А, кстати, еще представь как расширяется стандартное такое веб-форм приложение. У тебя есть иерархия мастер-пейджей, внутри них стандартный "понос" из контролов и разметки — и того и другого много, т.е. есть ценный функционал который никаким образом нельзя поломать, а есть тупая разметка, которую нужно выкинуть. И соответственно, задача полностью перекрутить дизайн.
S>И всё вместе будет прекрасно работать; будут работать SiteMapProviders, MembershipProvider, безопасность, логгирование, и прочее.
Давай не будет "растекаться мыслью по древу", ок? Тот же RoleProvider вообще ортогонален WebForms — неудивительно, что ты сможешь его использовать, даже если пошлешь WebForms куда подальше. А то так можно всю BCL к достоинствам WebForms приписать.
S>Вот, в частности, если у тебя вырисовывается свой фреймворк, к примеру, основанный на XML/XSLT, то можно наколбасить BuildProvider и вместо того, чтобы лепить однообразные хэндлеры, получить минимум лишнего кода, и при этом прекрасную производительность.
"Однообразный хэндлер" обычно получается в единственном числе, и кода лишнего там совсем немного. Значительно меньше чем на средней aspx-страничке.
ВВ>>При этом получается забавная ситуация, что среднестатистический асп.нет-чик может не знать ни базовые вещи по работе с HTTP, не уметь работать с джава-скриптом и пр. Я человек сто наверное прособеседовал, так что можно уже статистику составлять. S>Меня совершенно не волнуют проблемы среднестатистических дотнетчиков.
А меня волнуют.
S>Меня волнуют возможности, предоставляемые движком тем, кто знает HTTP и умеет работать с JavaScript, DOM, CSS и так далее.
Возможности предоставляются низкоуровневой архитектурой ASP.NET. Все, что начинается от реализации конкретного обработчика запроса к *.aspx в виде класса Page — это именно реализация этих возможностей. Причем далеко не самая удачная.
ВВ>>А в чем проблема? Ты пробовал и получилось слишком медленно? ВВ>>А то! S>И что являлось "бутылочным горлышком"? S>Как что? То, что в PHP невозможно закэшировать XsltCompiledTransform, конечно же.
Да вот прям в этом вся проблема. В 1.0 да и 1.1, кажется, XSLT-преобразование, построенное еще на основе старой версии MSXML работало где-то раза в 4 медленнее, чем в 2.0 — и никаких проблем не было даже близко. Упирались как все нормальные люди в перформанс БД.
А в PHP прям так сразу отсутствие XsltCompiledTransform убивает весь перформанс. Может стоит действительно сравнить, сколько времени уходит на преобразование, а сколько на все остальное?
Я вот делал преобразование прямо на клиенте, и знаешь во что приложение упиралось на страничках с большим количеством контента? В скорость, с которой браузер это дело отрисовывал.
ВВ>>Типа база летала, странички были заоптимизированы, скрипты клиентские не тормозили, а тормозил конкретно интерпретируемый PHP? ВВ>>А что с "количеством" кода? Надо много писать, чтобы вызвать XSLT-преобразование? В каких конкретно частях системы, при решение каких задач пришлось писать много кода? S>Отсутствие Build Providers требует всякий раз приседать вручную для вызова XSLT. Отлаживать всё это крайне неудобно, особенно когда есть цепочка из XSLT преобразований.
Ты серьезно? "Приседать", блин. Ты представляешь работу с XSLT в PHP? Там примерно то же количество приседаний, что и в .NET, даже чуть меньше.
И да, если тупо копипастить весь код, то наверное будут проблемы, причем далеко не только в PHP.
Это называется — давайте придумаем проблемы, а потом покажем для нее красивое решение.
И кстати, что ты собрался отлаживать? XSLT? И какое это имеет вообще отношение к PHP/WebForms?
S>>>При том, что ASP.NET — лучший в мире фреймворк для веб-приложений. ВВ>>Угу, при архитектуре, которая ущербна изначально. В каком страшном мире мы живем S>А какие претензии к архитектуре ASP.NET? Вот только не надо мне рассказывать про мышку и стандартные контролы. Это не архитектура, а самый верхний её слой.
ВВ>То, что творится в небольших компаниях одному богу известно. Я вот завтра организую фирмы и поставлю сотрудникам 386-е.
Разбегутся
ВВ>>>Вторая компания — нефтяной гигант с английскими корнями. PD>>Так гигант все же . Я не спорю, есть и такие задачи. Но увы, большинство все же не работает с гигантами в 100000 человек
ВВ>А с какими "гигантами" работает большинство? Это крупные предприятия, банки и пр. Ну не 100, но тысячи человек.
Маловато
ВВ>А любая фирма поступит также. Мы что ли свою уникальную нишу нашли? Или уж по крайней мере вендоры софта и железа будут рука об руку. Потому что, ты представляешь, вендорам железа тоже надо как-то свои железки продавать.
Сорри, но мы о чем-то ? Похоже, от обсужденяи проблем написания кода ты как-то к маркетингу перешел. Здесь я не специалист, обсуждать не буду.
PD>>>>Это раз. Но есть и два. Отношение к сопровождаемости и поддержке вообще зависит от того, о чем речь идет. В одном случае (те же сайты) — это очень важно, так как , действительно, кому нужен сайт. в котором нельзя произвести легко даже простое изменение при том. что автор давно уволился. Но есть и другие задачи, в которых это далеко не так важно. Иногда задача формулируется так, что по сути не предполагает модификаций, иногда модификации в ней легко предсказуемы и могут быть заложены как TODO еще при ее разработке. Мне кажется. что и в этом многие перегибают палку — пытаются распространить принципы, хорошо себя зарекомендовавшие, скажем, при разработке www-сайтов, на весь остальной программистский мир. Да, вас большинство, но из этого отнюдь не следует, что ваши боги есть боги для всех остальных ВВ>>>Честно, ни разу не встречался с "сайтами", которые не предполагают модификаций.
PD>>Василий, прочти внимательно. что я написал. Я же именно это и сказал — что такой сайт не нужен.
ВВ>Тогда я не понял. Ты говоришь, что есть задачи, в которые не обязательно должна закладываться возможность модификаций, и масштабируемость для них не так важна?
Именно, но отнюдь не сайты. См. выделенное выше.
ВВ>>>>>И такие ситуация происходят очень часто. А часто бывают и ситуации когда дешевле купить железо, а не заниматься оптимизацией криво спроектированного приложения. PD>>>>Я же тебе предлагал посчитать, что будет, если программа работает на сотне компьютеров, а ее работу удастся ускороить хотя бы в 5 раз. Ладно, посчитаю сам. Это значит, что вместо 100 компьютеров можно поставить 20. Считая стоимость компьютера за $1000, имеем 80 тыс долларов. Кому это 80 тыс за месяц работы платят ? ВВ>>>Компания-интегратор далеко не такие счеты тебе выставит И далеко не месяц насчитает PD>>И что ? Это как-то опровергает мой расчет ?
ВВ>Железо купить дешевле.
Ну это я уже не понимаю. Я тебе привел конкретный числовой пример, где дополнительное железо стоит $80К, а я (допустим) могу сделать так, чтобы оно не потребовалось. А ты опять — железо дешевле. Если так — бери меня на работу и плати $80K в месяц
ВВ>Да не выгоднее. Никто не разрабатывает "уникальные" программы с повышенными требованиями к железу.
Я. И еще какие повышенные требования!
>99% решений для корпоративного обладают такими требованиями. Эксчендж-сервер, шарепоинт и пр.
Почему ты считаешь, что бизнес — это только задачи обмена информацией ? Там еще и обработка ее есть. И она порой намного сложнее, чем форматирование текста
>Ты предлагаешь весь софт переделывать под древние железки?
Ну если P4 Quad 4 Гб или NVidia 8,9 серий это древняя железка — тогда найди поновее . А и их не хватает.
>И считаешь, что это будет дешевле?
Я же привел расчет. Ты его опровергнуть можешь ?
PD>>>>А если их не 100 ? А если вообще число компьютеров увеличить нельзя ? Под 1000 компьютеров придется ведь здание новое строить... ВВ>>>Здание не надо строить. Купил сервера у IBM, ну там и запарковал их. У IBM места хватит, это их бизнес. PD>>Психология web-программирования неистребима . Предложи Газпрому поставить свои компьютеры в IBM
ВВ>Ну да. BP вот религия позволяет сервера у IBM парковать. Видимо, там "веб-программисты" руководящие посты занимают
Религия может что угодно позволять, но то, что Газпром свои конфиденциальные данные разместит на сервере , находящемся в США — извини, не поверю.
Здравствуйте, gandjustas, Вы писали:
G>Тем не менее это не видеопамять.
Самая что ни на есть видео да еще и с прямым доступом по указателю.
FR>>>>В этом конкретном "там" и не думает сокращатся. G>>>Цифры в студию.
FR>>NET доступен на одной приставке которая отнюдь не доминирует на рынке, при этом даже на этой приставке он позиционируется как средство разработки небольших малобюджетных проектов. Срок жизни приставок 5 — 7 лет, так что ближаюшую пятилетку вряд-ли что существенно поменяется. G>Ну-ну, за последние 7 лет много чего изменилось.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> Спроецируйся назад на 10 лет (1998г) и попробуй предсказать будущее. Я не уверен, что в этом предсказании .Net вообще бы оказалась.
AVK>Java в 98 уже три года как была доступна
И в 1998 именно мы сайт с апплетом делали, он и посейчас жив
>в 97 уже началась ругачка между Саном и МС по поводу нее
И это помню.
>, а два года спуста уже была доступна первая бета-версия, так что появление в 2001 году дотнета, вобщем то, предсказать было вполне реально.
мб.
PD>>1. Сольются ли мобильные девайсы и настольные системы ?
AVK>Они уже слились.
PD>>2. Сольются ли телевидение и персональные компьютеры ?
AVK>Уже слилось.
Я, видимо, неточно выразился. Я имел в виду, не то, сольются ли они технически, а сольются ли в массовом масштабе. Иными словами, закончится ли зоопарк ОС на мобильниках переходом к некоей ОС, единой для мобильников и настольных (или как минимум неким интеграционным пакетом). А про телевидение — — останется ли вариант "вещания" или выживет только вариант "запроса" ?
Здравствуйте, Pavel Dvorkin, Вы писали:
ВВ>>То, что творится в небольших компаниях одному богу известно. Я вот завтра организую фирмы и поставлю сотрудникам 386-е. PD>Разбегутся
Почему? Как разница на чем в "солитер" играть?
ВВ>>>>Вторая компания — нефтяной гигант с английскими корнями. PD>>>Так гигант все же . Я не спорю, есть и такие задачи. Но увы, большинство все же не работает с гигантами в 100000 человек ВВ>>А с какими "гигантами" работает большинство? Это крупные предприятия, банки и пр. Ну не 100, но тысячи человек. PD>Маловато
Да уж, прям так маловато
Для того, чтобы заниматься многогодовыми внедрениями какой-нибудь очередной хреновины обычно хватает.
ВВ>>А любая фирма поступит также. Мы что ли свою уникальную нишу нашли? Или уж по крайней мере вендоры софта и железа будут рука об руку. Потому что, ты представляешь, вендорам железа тоже надо как-то свои железки продавать. PD>Сорри, но мы о чем-то ? Похоже, от обсужденяи проблем написания кода ты как-то к маркетингу перешел. Здесь я не специалист, обсуждать не буду.
Разработка софта — это коммерческий продукт. Такой же как тушь для ресниц или автомобили. Разве нет? Ты в любом случае упрешься в маркетинг, это нормально.
Даже как человек не слишком-то близкий к собственно бизнесу я в первую очередь определяю, что нам выгоднее будет продать. А потом уже идет архитектура, проблемы написания кода и проч.
ВВ>>>>>>И такие ситуация происходят очень часто. А часто бывают и ситуации когда дешевле купить железо, а не заниматься оптимизацией криво спроектированного приложения. PD>>>>>Я же тебе предлагал посчитать, что будет, если программа работает на сотне компьютеров, а ее работу удастся ускороить хотя бы в 5 раз. Ладно, посчитаю сам. Это значит, что вместо 100 компьютеров можно поставить 20. Считая стоимость компьютера за $1000, имеем 80 тыс долларов. Кому это 80 тыс за месяц работы платят ? ВВ>>>>Компания-интегратор далеко не такие счеты тебе выставит И далеко не месяц насчитает PD>>>И что ? Это как-то опровергает мой расчет ? ВВ>>Железо купить дешевле.
PD>Ну это я уже не понимаю. Я тебе привел конкретный числовой пример, где дополнительное железо стоит $80К, а я (допустим) могу сделать так, чтобы оно не потребовалось. А ты опять — железо дешевле. Если так — бери меня на работу и плати $80K в месяц
Ты сам себе человек-оркестр что ли? Я тебе говорю, стандартный такой скромный интегратор высосет из клиента куда больше денег на оптимизации, чем тот заплатил бы за железо. Ты один может быть и составишь конкуренцию альтернативе "поменять все железо".
Потом, что за программа такая? Клиентское приложение, разворачивается на всех компах фирмы? Мы опять получается о какой-нибудь специфической нише говорим. Я тебе много раз уже говорил, что согласен с тем, что такие задачи есть, что есть такие приложение и пр. Только есть и другие приложения. И это не только всякие там веб-сайты да хоум-пейджи.
А в общем случае мне вообще сложно представить, что за приложение должно быть такое, что у него требования будут зашкалировать по сравнению, скажем, с Office 2007
ВВ>>Да не выгоднее. Никто не разрабатывает "уникальные" программы с повышенными требованиями к железу. PD>Я. И еще какие повышенные требования!
Ну да ради бога, только ты в меньшистве.
>>99% решений для корпоративного обладают такими требованиями. Эксчендж-сервер, шарепоинт и пр. PD>Почему ты считаешь, что бизнес — это только задачи обмена информацией ? Там еще и обработка ее есть. И она порой намного сложнее, чем форматирование текста
И что? Какие в большинстве случаев ты представляешь задачи для обработки информации, что с ними никак не справляется железо?
>>Ты предлагаешь весь софт переделывать под древние железки? PD>Ну если P4 Quad 4 Гб или NVidia 8,9 серий это древняя железка — тогда найди поновее . А и их не хватает.
P4 Quad — это что? Четырехядерный пентиум 4?
Упоминание NVidia 8,9 — это или 3D или [censored] математика. Ну по поводу 3D я и сам согласен, а [censored] математика она на то и [censored].
>>И считаешь, что это будет дешевле? PD>Я же привел расчет. Ты его опровергнуть можешь ?
Я тебе еще раз говорю — компания за месячную разработку возьмет больше.
ВВ>>Ну да. BP вот религия позволяет сервера у IBM парковать. Видимо, там "веб-программисты" руководящие посты занимают PD>Религия может что угодно позволять, но то, что Газпром свои конфиденциальные данные разместит на сервере , находящемся в США — извини, не поверю.
И правда — IBM периферийная контрола с одним офисом в США. И весь небось серверами завален.
Здравствуйте, fmiracle, Вы писали:
F>Sinclair говорит тебе, что ASP.NET и WebForms — это отнють не синонимы, и WebForms это только составная, но не обязательная часть ASP.NET. F>У тебя же претензии к WebForms, но при этом упорно утверждаешь, что ASP.NET вообще — полнейший отстой. F>Это как-то вроде того, что аргументировать ущербность архитектуры Windows тем, что explorer — далеко не самый мощный файловый менеджер...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я, видимо, неточно выразился. Я имел в виду, не то, сольются ли они технически, а сольются ли в массовом масштабе. Иными словами, закончится ли зоопарк ОС на мобильниках переходом к некоей ОС, единой для мобильников и настольных (или как минимум неким интеграционным пакетом). А про телевидение — — останется ли вариант "вещания" или выживет только вариант "запроса" ?
Вставлю свои пять копеек — думаю, вещание таки умрет все-таки. Хотя, возможно, и не через десять лет. Через десять лет у нас дай бог HDTV появится.
Вариант "запроса" вообще значительно удобнее и позволяет решить много проблем, связанных с вещанием. Кстати, уже сейчас есть варианты реализации такого телевидения "по запросу" — XBox 360.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я, видимо, неточно выразился. Я имел в виду, не то, сольются ли они технически, а сольются ли в массовом масштабе.
Смотря что понимать под массовым масштабом.
PD> Иными словами, закончится ли зоопарк ОС на мобильниках переходом к некоей ОС, единой для мобильников и настольных (или как минимум неким интеграционным пакетом).
При чем тут ОС? И что такое интеграционный пакет? Давным давно проблемы написания разного софта определяются не ОС и загадочными пакетами (и линух для мелких дивайсов давно доступен, и WM твой любимый Win32 предоставляет в очень приличном объеме), а принципиальными ограничениями железа, размером экрана прежде всего и разными моделями применения (наличие тачскринов, GPS, но при этом отсутствие быстрых и скоростных дисков).
PD> А про телевидение — — останется ли вариант "вещания" или выживет только вариант "запроса" ?
Останется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, IT, Вы писали:
Y>>STL, Boost.
IT>Это библиотеки, а не языковые конструкции. Если там и есть претензии на FP, то дальше претензий оно никуда не ушло.
FP — это стиль, ничего больше. ООП — тоже. В принципе, функциональную абстракцию можно воплотить и средствами структурного программирования. Будет сложновато, спору нет, но можно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я так понимаю, насчет уровня абстракции и прямого доступа к памяти больше вопросов нет?
Я тебе много раз уже говорил, что согласен с тем, что такие задачи есть, что есть такие приложение и пр. Только есть и другие приложения. И это не только всякие там веб-сайты да хоум-пейджи.
Если нам не помогут, то мы тоже никого не пощадим.
