[Serializable, ComVisible(true), AttributeUsage(AttributeTargets.Field, Inherited=false)]
public class ThreadStaticAttribute: Attribute {}
Это и весь код.
>> А если не кодить на плюсах 10 лет, то потом тоже вряд ли вспомнишь что к чему.
>> Какая разница, что забыть: что делает использованный класс на с++ или аттрибут
Вы немного некорректно выразились. Аттрибут не делает ничего. Делает среда, реагируя на атрибут.
>> Или не вспомнить что делает какой то метод из библиотеки, код которой куда то пропал (для с++) или из самого языка (c# например)?
Давайте оставим C++ в покое. Мы сейчас говорим конкрентно о CLR. И рассматриваем два случая: в первом функция реализована в виде библиотеки, во втором — декларативно. Если код работает, значти библиотека на месте, значит нет труда рефлектором, по месту, посмотреть ее устройство.
Все что я хочу сказать, что я предпочел бы среду с более простой базовой машиной, но более развитой библиотекой. И с этой точки зрения CLR для меня лично — не идеал. Возможно им станет C++0x, ведь уважаемый Бьерн Страуструп ведет активную работу по разведению запрошенных улучшений и функций к новому поколению «плюсов» на то, что должно стать частью языка и то, что лучше включить в состав Standard Library.
Я говорю о тех примерах, которые как раз то и нельзя рефлектором посмотреть. Тот же ThreadStatic, это простой декларативный атрибут. Он не имеет кода, который можно было бы проанализировать. Он просто «флажок» для CLR, которая реагирует на него изменением поведения.
>> А уж если хочется иметь полный контоль над кодом, то лучше вообще ничего не подключать и писать все самому.
Помоему Вы немного путаетесь. Использование сторонних библиотек совершенно не означает потерю контроля над кодом. Хотел бы объяснить почему, но это оффтопик.
Я говорил лиш о том, что CLR исповедует декларативный метод. Вы просто должны выучить тот немаленький список ее возможностей, и быть счастливым программистом. Но вот беда, если вы завтра перестанете писать программы под .NET, перейдете на другую платформу, а через 10 лет вам попадется под руку код, написанный декларативным методом с использованием всех функций CLR, вам будет очень тяжело понять поведение кода. Нет возможности по месту изучить поведение, надо опять идти читать базовые книги, чтобы вспоимнать устройство машины (runtime).
А можете привести пример про «это», что нельзя вынести в библиотеки по причине потели межязыковой совместимости?
Я всегда думал, что межязыковая совместимость обеспечивается наличием в .NET промежуточного языка MSIL. Отсюда и свойство — неважно, на каком языке написан исходный код, так как он все равно транслируется в MSIL.
Но как это связано с тем, о чем я написал — о избыточной (чисто на мой личный взгляд, конечно) перегрузке виртуальной машины функциями, которые вполне можно реализовать библиотеками?
С каждой новой версией .NET, программировать под него становится все сложнее. Проблема, на мой взгляд, в том, что слишком много функций возлагается на саму среду и языковые возможности, в то время как их спокойно можно было бы реализовать расширением библиотеками стандартных классов и функций.
Вот взять к примеру, один из самых дьявольских атрибутов — ThreadStaticAttribute. Казалось бы, что плохого, в том что можно легко и быстро сделать переменную уникальной для каждого потока, либо другими словами, из одной переменной сделать хранилище переменных, где каждый поток получает в распоряжение отдельную область из хранилища. А плохо то, что это неявный подход к созданию такого хранилища, и на моем опыте случалась не одна ошибка, что ктото забывал, не замечал, или просто не знал, что некая переменная объявлена как ThreadStatic, сначала долго удивлялся почему все не работает, а потратив порядочно времени на дебаг долго ругался и говорил что «я то думал это обычный статик, в этом потоке запишу, в другом прочитаю». В общем, не знаю как для вас, а для меня ThreadStatic — табу. Я про него знаю (как и о многих других вещах написаных в этой статье) но не использую, и не буду использовать.
Лучше я напишу чуть больше кода, но этот код — явный, его можно открыть и посмотреть как он работает, чем буду использовать мудрености фреймворка со скрытой реализацией. .NET далеко ушел на фронте упрощения и абстракции алгоритмов, но тяжелая виртуальная машина, напичканая встроенными возможностями, сильно усложняет понимание и предсказуемость как будет работать код. В этом плане обычный C++ гораздо проще, где мы имеем дело с простой «реальной» машиной.
Ну протокол может и будет прост. Но я как прикину какой это будет input lag…
Вот например в шутерах от первого лица очень важно иметь очень быстрое изменение картинки на экране при нажатии влево-вправо, прыжок, огонь. Тоже самое в авто симуляторах и аркадах. И я уму не приложу, как возможно получить такую скорость при передаче картинки через инетрнет.
Другими словами. Если в случае рендеринга картинки по «старинке», FPSы ограничивает к примеру скорость передачи данных из системной памяти в видеопамять, то в случае с удаленным рендерингом, FPSы будут ограничивать сетевые задержки, которые просто громадны по сравнению с локальными задержками внутри системного блока.
Хоть 1 FPS то будет, а? :-)
Я думаю что даже в общей своей идее, ремоут рендеринг с быстрым откликом на действия юзера, на данный момент не возможен. Я честно и искренне рад бы был, если бы такая возможность была, ибо это означало бы также что мы с вами можем листать странички в интернете с мгновенным откликом браузера, при переходе по гиперссылке :-)
Ну протокол может и будет прост. Но я как прикину какой это будет input lag…
Вот например в шутерах от первого лица очень важно иметь очень быстрое изменение картинки на экране при нажатии влево-вправо, прыжок, огонь. Тоже самое в авто симуляторах и аркадах. И я уму не приложу, как возможно получить такую скорость при передаче картинки через инетрнет.
Другими словами. Если в случае рендеринга картинки по «старинке», FPSы ограничивает к примеру скорость передачи данных из системной памяти в видеопамять, то в случае с удаленным рендерингом, FPSы будут ограничивать сетевые задержки, которые просто громадны по сравнению с локальными задержками внутри системного блока.
Хоть 1 FPS то будет, а? :-)
Я думаю что даже в общей своей идее, ремоут рендеринг с быстрым откликом на действия юзера, на данный момент не возможен. Я честно и искренне рад бы был, если бы такая возможность была, ибо это означало бы также что мы с вами можем листать странички в интернете с мгновенным откликом браузера, при переходе по гиперссылке :-)
Ну протокол может и будет прост. Но я как прикину какой это будет input lag…
Вот например в шутерах от первого лица очень важно иметь очень быстрое изменение картинки на экране при нажатии влево-вправо, прыжок, огонь. Тоже самое в авто симуляторах и аркадах. И я уму не приложу, как возможно получить такую скорость при передаче картинки через инетрнет.
Другими словами. Если в случае рендеринга картинки по «старинке», FPSы ограничивает к примеру скорость передачи данных из системной памяти в видеопамять, то в случае с удаленным рендерингом, FPSы будут ограничивать сетевые задержки, которые просто громадны по сравнению с локальными задержками внутри системного блока.
Хоть 1 FPS то будет, а? :-)
Я думаю что даже в общей своей идее, ремоут рендеринг с быстрым откликом на действия юзера, на данный момент не возможен. Я честно и искренне рад бы был, если бы такая возможность была, ибо это означало бы также что мы с вами можем листать странички в интернете с мгновенным откликом браузера, при переходе по гиперссылке :-)
>> Байты, мегабайты… похоже вы разбираетесь. Тогда вы должны понимать, что протокол синхронизации игрового процесса и AV-стрим это немного не одно и тоже.
Согласен. AV-стрим считай стабильный по объему за единицу времени поток данных, в то время как объем данных сетевой протокол игры зависит от игрового процесса.
>> А про концентрацию вычеслительных мощностей… я несколько шокирован… вы считаете, что вы в розницу платите меньше чем они оптом закупаю электроэнергию?
Помоему вопрос не «в розницу/оптом». А в невозможности концентрации потребителей энергии в одной точке. Это почти таже причина, по которой мы с вами до сих пор ездим на машинах с двигателями внутреннего сгорания, а не на электрокарах. Даже не смотря на все недостатки ДВС, плюс в том что энергия производится для каждого потребителя индивидуально в объемах необходимых ему, чего нельзя сказать о электромобилях, для которых энергию надо производить централизованно на электростанциях, да еще и хранить где то, а ведь еще не дай бог ктото из водителей решит сегодня пройтись пешком, или поехать на велоспеде! Куда девать заранее выработанную энергию.
Аналогично, в случае таких центров, очень тяжело предсказать количество необходимого оборудования, спланировать уровень энергопотребления и подписать соотвествующие контракты. Ведь нельзя сказать сколько человек решит поиграть через час — может всего 10, а может, как это часто бывает в информационном обществе — сразу миллион игроков, которые захотят посмотреть на какую то игру-новинку!
Я удивляюсь как на эту провокацию повелись известные производители игр. Хотя может повелись их маркетинговые департаменты, потому что, уверен, опытные разработчики знают, как тяжело обеспечить высокую скорость сетевых игр для большого количества игроков из разных частей планеты. Тут идет вопрос не не мегабайты, а на байты — каждый сэкономленный байт на уровне сетевого протокола синхронизации игрового процесса — потенциальный буст к ускорению сетевой игры.
Вторая проблема это конечно концентрация вычислительных мощностей в одном дата центре. Ну вот к примеру в популярных играх может быть одновременно десятки тысяч игроков онлайн. Это же сколько надо серверов, и сколько они будут потреблять электроенергии, и ведь платить за все это надо владельцам серверов, и наверняка эти суммы будут включены в стоимость аренды игр, а цена электроенергии там наверняка выше чем у многих «на местах».
Да и вообще, можно взять туже статистику объемов продаж современных видеокарт за последние год-два, и вуаля, вот сколько потенциальных игроков. Прикинем что в единицу времени может играть в сетевые пусть даже 0.01% а в пиках на порядок больше, и теперь все это поместить в несколько дата центров… вы верите что это реально? :-)
Поэтому имхо, старые добрые PC и приставки могут пока спать спокойно.
> Просто не могут и все тут - заблудятся они там
Слишком категорично. У гугла нормальный, достаточно гибкий подход. Почитайте по ключу "Google’s 70-20-10 Rule".
public class ThreadStaticAttribute: Attribute {}
Это и весь код.
>> А если не кодить на плюсах 10 лет, то потом тоже вряд ли вспомнишь что к чему.
>> Какая разница, что забыть: что делает использованный класс на с++ или аттрибут
Вы немного некорректно выразились. Аттрибут не делает ничего. Делает среда, реагируя на атрибут.
>> Или не вспомнить что делает какой то метод из библиотеки, код которой куда то пропал (для с++) или из самого языка (c# например)?
Давайте оставим C++ в покое. Мы сейчас говорим конкрентно о CLR. И рассматриваем два случая: в первом функция реализована в виде библиотеки, во втором — декларативно. Если код работает, значти библиотека на месте, значит нет труда рефлектором, по месту, посмотреть ее устройство.
Все что я хочу сказать, что я предпочел бы среду с более простой базовой машиной, но более развитой библиотекой. И с этой точки зрения CLR для меня лично — не идеал. Возможно им станет C++0x, ведь уважаемый Бьерн Страуструп ведет активную работу по разведению запрошенных улучшений и функций к новому поколению «плюсов» на то, что должно стать частью языка и то, что лучше включить в состав Standard Library.
>> А уж если хочется иметь полный контоль над кодом, то лучше вообще ничего не подключать и писать все самому.
Помоему Вы немного путаетесь. Использование сторонних библиотек совершенно не означает потерю контроля над кодом. Хотел бы объяснить почему, но это оффтопик.
Я говорил лиш о том, что CLR исповедует декларативный метод. Вы просто должны выучить тот немаленький список ее возможностей, и быть счастливым программистом. Но вот беда, если вы завтра перестанете писать программы под .NET, перейдете на другую платформу, а через 10 лет вам попадется под руку код, написанный декларативным методом с использованием всех функций CLR, вам будет очень тяжело понять поведение кода. Нет возможности по месту изучить поведение, надо опять идти читать базовые книги, чтобы вспоимнать устройство машины (runtime).
Я всегда думал, что межязыковая совместимость обеспечивается наличием в .NET промежуточного языка MSIL. Отсюда и свойство — неважно, на каком языке написан исходный код, так как он все равно транслируется в MSIL.
Но как это связано с тем, о чем я написал — о избыточной (чисто на мой личный взгляд, конечно) перегрузке виртуальной машины функциями, которые вполне можно реализовать библиотеками?
Вот взять к примеру, один из самых дьявольских атрибутов — ThreadStaticAttribute. Казалось бы, что плохого, в том что можно легко и быстро сделать переменную уникальной для каждого потока, либо другими словами, из одной переменной сделать хранилище переменных, где каждый поток получает в распоряжение отдельную область из хранилища. А плохо то, что это неявный подход к созданию такого хранилища, и на моем опыте случалась не одна ошибка, что ктото забывал, не замечал, или просто не знал, что некая переменная объявлена как ThreadStatic, сначала долго удивлялся почему все не работает, а потратив порядочно времени на дебаг долго ругался и говорил что «я то думал это обычный статик, в этом потоке запишу, в другом прочитаю». В общем, не знаю как для вас, а для меня ThreadStatic — табу. Я про него знаю (как и о многих других вещах написаных в этой статье) но не использую, и не буду использовать.
Лучше я напишу чуть больше кода, но этот код — явный, его можно открыть и посмотреть как он работает, чем буду использовать мудрености фреймворка со скрытой реализацией. .NET далеко ушел на фронте упрощения и абстракции алгоритмов, но тяжелая виртуальная машина, напичканая встроенными возможностями, сильно усложняет понимание и предсказуемость как будет работать код. В этом плане обычный C++ гораздо проще, где мы имеем дело с простой «реальной» машиной.
Вот например в шутерах от первого лица очень важно иметь очень быстрое изменение картинки на экране при нажатии влево-вправо, прыжок, огонь. Тоже самое в авто симуляторах и аркадах. И я уму не приложу, как возможно получить такую скорость при передаче картинки через инетрнет.
Другими словами. Если в случае рендеринга картинки по «старинке», FPSы ограничивает к примеру скорость передачи данных из системной памяти в видеопамять, то в случае с удаленным рендерингом, FPSы будут ограничивать сетевые задержки, которые просто громадны по сравнению с локальными задержками внутри системного блока.
Хоть 1 FPS то будет, а? :-)
Я думаю что даже в общей своей идее, ремоут рендеринг с быстрым откликом на действия юзера, на данный момент не возможен. Я честно и искренне рад бы был, если бы такая возможность была, ибо это означало бы также что мы с вами можем листать странички в интернете с мгновенным откликом браузера, при переходе по гиперссылке :-)
Вот например в шутерах от первого лица очень важно иметь очень быстрое изменение картинки на экране при нажатии влево-вправо, прыжок, огонь. Тоже самое в авто симуляторах и аркадах. И я уму не приложу, как возможно получить такую скорость при передаче картинки через инетрнет.
Другими словами. Если в случае рендеринга картинки по «старинке», FPSы ограничивает к примеру скорость передачи данных из системной памяти в видеопамять, то в случае с удаленным рендерингом, FPSы будут ограничивать сетевые задержки, которые просто громадны по сравнению с локальными задержками внутри системного блока.
Хоть 1 FPS то будет, а? :-)
Я думаю что даже в общей своей идее, ремоут рендеринг с быстрым откликом на действия юзера, на данный момент не возможен. Я честно и искренне рад бы был, если бы такая возможность была, ибо это означало бы также что мы с вами можем листать странички в интернете с мгновенным откликом браузера, при переходе по гиперссылке :-)
Вот например в шутерах от первого лица очень важно иметь очень быстрое изменение картинки на экране при нажатии влево-вправо, прыжок, огонь. Тоже самое в авто симуляторах и аркадах. И я уму не приложу, как возможно получить такую скорость при передаче картинки через инетрнет.
Другими словами. Если в случае рендеринга картинки по «старинке», FPSы ограничивает к примеру скорость передачи данных из системной памяти в видеопамять, то в случае с удаленным рендерингом, FPSы будут ограничивать сетевые задержки, которые просто громадны по сравнению с локальными задержками внутри системного блока.
Хоть 1 FPS то будет, а? :-)
Я думаю что даже в общей своей идее, ремоут рендеринг с быстрым откликом на действия юзера, на данный момент не возможен. Я честно и искренне рад бы был, если бы такая возможность была, ибо это означало бы также что мы с вами можем листать странички в интернете с мгновенным откликом браузера, при переходе по гиперссылке :-)
Согласен. AV-стрим считай стабильный по объему за единицу времени поток данных, в то время как объем данных сетевой протокол игры зависит от игрового процесса.
>> А про концентрацию вычеслительных мощностей… я несколько шокирован… вы считаете, что вы в розницу платите меньше чем они оптом закупаю электроэнергию?
Помоему вопрос не «в розницу/оптом». А в невозможности концентрации потребителей энергии в одной точке. Это почти таже причина, по которой мы с вами до сих пор ездим на машинах с двигателями внутреннего сгорания, а не на электрокарах. Даже не смотря на все недостатки ДВС, плюс в том что энергия производится для каждого потребителя индивидуально в объемах необходимых ему, чего нельзя сказать о электромобилях, для которых энергию надо производить централизованно на электростанциях, да еще и хранить где то, а ведь еще не дай бог ктото из водителей решит сегодня пройтись пешком, или поехать на велоспеде! Куда девать заранее выработанную энергию.
Аналогично, в случае таких центров, очень тяжело предсказать количество необходимого оборудования, спланировать уровень энергопотребления и подписать соотвествующие контракты. Ведь нельзя сказать сколько человек решит поиграть через час — может всего 10, а может, как это часто бывает в информационном обществе — сразу миллион игроков, которые захотят посмотреть на какую то игру-новинку!
Я удивляюсь как на эту провокацию повелись известные производители игр. Хотя может повелись их маркетинговые департаменты, потому что, уверен, опытные разработчики знают, как тяжело обеспечить высокую скорость сетевых игр для большого количества игроков из разных частей планеты. Тут идет вопрос не не мегабайты, а на байты — каждый сэкономленный байт на уровне сетевого протокола синхронизации игрового процесса — потенциальный буст к ускорению сетевой игры.
Вторая проблема это конечно концентрация вычислительных мощностей в одном дата центре. Ну вот к примеру в популярных играх может быть одновременно десятки тысяч игроков онлайн. Это же сколько надо серверов, и сколько они будут потреблять электроенергии, и ведь платить за все это надо владельцам серверов, и наверняка эти суммы будут включены в стоимость аренды игр, а цена электроенергии там наверняка выше чем у многих «на местах».
Да и вообще, можно взять туже статистику объемов продаж современных видеокарт за последние год-два, и вуаля, вот сколько потенциальных игроков. Прикинем что в единицу времени может играть в сетевые пусть даже 0.01% а в пиках на порядок больше, и теперь все это поместить в несколько дата центров… вы верите что это реально? :-)
Поэтому имхо, старые добрые PC и приставки могут пока спать спокойно.
Слишком категорично. У гугла нормальный, достаточно гибкий подход. Почитайте по ключу "Google’s 70-20-10 Rule".