Ну, поэтому я и написал VRAM, обращая внимание на то, что физическая память под это дело не будет расходоваться.
Уход в своп можно ускорить, не спорю :) Тока мне вот не нравится «мастурбировать» Working Set вверх-вниз, чтобы таки сработало — однозначно это свидетельствует о том, что дизайн подсистемы вынуждает заниматься сексом в гамаке на лыжах.
Впрочем, среднему пользователю подсистемы памяти (имея в виду прикладного программиста) и не придется этим заниматься — алгоритмы управления в VRAM в Windows достаточно хороши.
Имеется в виду, что виртуальная память, отобранная у системы под LOH, ей (системе) не возвращается, и не может быть задействована под работу обычного generational GC.
Грубо говоря: если ваше приложение разместило в LOH, скажем, 100MB, а затем полностью его освободило, затем стало размещать не больше ~10M только в пуле поколений, то приложение отнимет у системы 100MB VRAM дополнительно к тому, что будет затрачено на пул поколений и код.
На самом деле выпускается не сам процессор, а его ядро в составе различных SoC. В этом плане 80186 вышел крайне удачным: он достаточно просто реализуем в базисе ПЛИС и БМК, включает в себя основные узлы для embedded — таймеры, контроллер прерываний, DMA-контроллер, имеет скалярную архитектуру (а значит, тайминги известны) фон Неймана, работает с единым пространством данных и команд, содержит развитой набор инструкций, имеет крайне малое тепловыделение.
Нет, это не очень хорошо.
Назвать одинаково не удалось, т.к. это было не единовременным решением, а эволюционным — Win-ядро сначала не было Unicode. Потом добавили Unicode, но чтобы а) не ломать совместимость пришлось городить весь этот огород.
Случаи использования — были в ранних версиях Win, когда ядро было не-юникодным, и при вызове API юникодные строки приходилось перекодировать в не-юникод и обратно. В настоящее время это атавизм, и все реализованно наоборот — ядро использует юникод, а перекодирование перед вызовом и после используется для не-юникодных строк. Т.е. функции с окончанием A на самом деле макросы, подставляющие аналоги с W. Но к счастью, для большинства задач вызов не-юникодного API — это ненужный атавизм
Хм, ну если вы писали в вики, то вопросов нет, своими словами. Если же нет — незасчитано, это не ваши слова :)
>>структура взаимосвязи компонентов системы
Окэ. Вы одно определяете через другое, не давая определения другого. Риторические вопросы — что такое «структура»? Что такое «компоненты»? Почему в ваше определение не входит цель построения этих взаимосвязей и решаемая ими задача — такое ощущение, что они сами по себе, просто чтобы были.
Также по-вашему выходит, что внутренний состав компонент в архитектуру приложения не входит — связи входят, а устройство компонент — нет. А если в приложении нет компонент, или компонент — один, т.е. у него нет связей с другими — выходит, нет и архитектуры?
По поводу WinAPI не в ту степь — CreateWindowA и CreateWindowW названы так не потому, что это влияет на архитектуру (даже на озвученную «структуру взаимосвязи»)-- просто так удобнее подставлять при помощи макроса конкретное имя функции в зависимости от unicode/non-unicode окружения.
В общем, мой вам совет — попробуйте для себя найти краткое непротиворечивое определение архитектуры ПО — будет проще выразить мысль, узнаете много интересного.
Давайте по пунктам, чтобы не было обидно (а то меня так всегда воспринимают, как будто я издеваюсь)
>>Именование глобальных переменных и классов оказывает непосредственное влияние
>>на архитектуру. Когда в проекте полсотни похожих имен, могут возникнуть проблемы.
Мне кажется, проблемы возникнут с чем-то другим, но явно не с архитектурой системы. Можете дать определение архитектуры приложения своими словами?
Позабавило же меня то, что вы обращаетесь к нам, как к людям, которые никогда не пробовали программировать. Вот, например: «новые функции, похожие на старые». Что значит «похожие»? А сильно похожие или нет, только первой половиной?
Вы про сигнатуру функций говорили? Так и пишите, тут поймут.
«Может-должен-должны-могут-надо»… Никто никому не должен, максимум — обязан, и то, потому что существует рациональная причина. У вас же в тексте — заповеди Моисея, практики в форме аксиом. Поймите, это бесполезно — оно все одно не запоминается. Про cargo cult слышали? Вот именно оно.
select count(«должны»|«должна»|«должен»|«нужно»|«нужен») from text;
go;
> over 9000…
select count(«можно»|«может»|«могут») from text;
go;
> over 9000…
Архитектура — это не стиль кода и не отступы, не именование переменных. Очень порадовали: «использовать SQL тоже нужно через ядро». «Связи должны быть не прямые, а в виде дерева». «Можно просто создавать новые функции, похожие на старые».
Совершенно бесполезная статья — каша наизнанку. Это реферат старшеклассника?
У вас есть опыт промышленной разработки?
>> В ОС будет эквивалент .NET Compact Framework, встроенный в Silverlight
Очень странное заявление, если учесть, что Silverlight и есть ветка от Compact Framework, продолжившая развиваться отдельно. А вот про XNA вполне вероятно — XNA также является адаптированным Compact Framework-ом, «притормозившим» в районе 2ой версии .net
В общем, если и остальные новости носят такой же характер, то мое мнение состоит в том, что рано кричать или делать выводы, а настоятельно следует подождать официальных вестей — эти же крайне противоречивые.
А я у вас спрашивал, что ли? Откуда у вас в сети взялся DNS, настроенный админом на well-known?
Я вот что не понимаю — автор тщательно описал постановку задачи. И решает _его_ задачу.
Конечно, по уму если делать, вы все правильно говорите — велосипеды в топку, следует пользоваться рабочим стабильным решением. Я так и написал первым комментарием.
Но это уже решение другой задачи, понимаете — не той, что была в топике, с другими ограничениями и другой вводной. В топике — домашняя сеть и минимум телодвижений до, после и во время.
Как-то так.
Уход в своп можно ускорить, не спорю :) Тока мне вот не нравится «мастурбировать» Working Set вверх-вниз, чтобы таки сработало — однозначно это свидетельствует о том, что дизайн подсистемы вынуждает заниматься сексом в гамаке на лыжах.
Впрочем, среднему пользователю подсистемы памяти (имея в виду прикладного программиста) и не придется этим заниматься — алгоритмы управления в VRAM в Windows достаточно хороши.
Грубо говоря: если ваше приложение разместило в LOH, скажем, 100MB, а затем полностью его освободило, затем стало размещать не больше ~10M только в пуле поколений, то приложение отнимет у системы 100MB VRAM дополнительно к тому, что будет затрачено на пул поколений и код.
class MyList<U> : Dictionary<int/long, U> {… }
То ли ie7 проглючило, то ли Хабр виноват. Еще раз извините.
Назвать одинаково не удалось, т.к. это было не единовременным решением, а эволюционным — Win-ядро сначала не было Unicode. Потом добавили Unicode, но чтобы а) не ломать совместимость пришлось городить весь этот огород.
Случаи использования — были в ранних версиях Win, когда ядро было не-юникодным, и при вызове API юникодные строки приходилось перекодировать в не-юникод и обратно. В настоящее время это атавизм, и все реализованно наоборот — ядро использует юникод, а перекодирование перед вызовом и после используется для не-юникодных строк. Т.е. функции с окончанием A на самом деле макросы, подставляющие аналоги с W. Но к счастью, для большинства задач вызов не-юникодного API — это ненужный атавизм
>>структура взаимосвязи компонентов системы
Окэ. Вы одно определяете через другое, не давая определения другого. Риторические вопросы — что такое «структура»? Что такое «компоненты»? Почему в ваше определение не входит цель построения этих взаимосвязей и решаемая ими задача — такое ощущение, что они сами по себе, просто чтобы были.
Также по-вашему выходит, что внутренний состав компонент в архитектуру приложения не входит — связи входят, а устройство компонент — нет. А если в приложении нет компонент, или компонент — один, т.е. у него нет связей с другими — выходит, нет и архитектуры?
По поводу WinAPI не в ту степь — CreateWindowA и CreateWindowW названы так не потому, что это влияет на архитектуру (даже на озвученную «структуру взаимосвязи»)-- просто так удобнее подставлять при помощи макроса конкретное имя функции в зависимости от unicode/non-unicode окружения.
В общем, мой вам совет — попробуйте для себя найти краткое непротиворечивое определение архитектуры ПО — будет проще выразить мысль, узнаете много интересного.
>>Именование глобальных переменных и классов оказывает непосредственное влияние
>>на архитектуру. Когда в проекте полсотни похожих имен, могут возникнуть проблемы.
Мне кажется, проблемы возникнут с чем-то другим, но явно не с архитектурой системы. Можете дать определение архитектуры приложения своими словами?
Позабавило же меня то, что вы обращаетесь к нам, как к людям, которые никогда не пробовали программировать. Вот, например: «новые функции, похожие на старые». Что значит «похожие»? А сильно похожие или нет, только первой половиной?
Вы про сигнатуру функций говорили? Так и пишите, тут поймут.
«Может-должен-должны-могут-надо»… Никто никому не должен, максимум — обязан, и то, потому что существует рациональная причина. У вас же в тексте — заповеди Моисея, практики в форме аксиом. Поймите, это бесполезно — оно все одно не запоминается. Про cargo cult слышали? Вот именно оно.
www.amazon.co.uk/Object-oriented-Software-Construction-Prentice-Hall-Resource/dp/0136291554
go;
> over 9000…
select count(«можно»|«может»|«могут») from text;
go;
> over 9000…
Архитектура — это не стиль кода и не отступы, не именование переменных. Очень порадовали: «использовать SQL тоже нужно через ядро». «Связи должны быть не прямые, а в виде дерева». «Можно просто создавать новые функции, похожие на старые».
Совершенно бесполезная статья — каша наизнанку. Это реферат старшеклассника?
У вас есть опыт промышленной разработки?
Очень странное заявление, если учесть, что Silverlight и есть ветка от Compact Framework, продолжившая развиваться отдельно. А вот про XNA вполне вероятно — XNA также является адаптированным Compact Framework-ом, «притормозившим» в районе 2ой версии .net
В общем, если и остальные новости носят такой же характер, то мое мнение состоит в том, что рано кричать или делать выводы, а настоятельно следует подождать официальных вестей — эти же крайне противоречивые.
Я вот что не понимаю — автор тщательно описал постановку задачи. И решает _его_ задачу.
Конечно, по уму если делать, вы все правильно говорите — велосипеды в топку, следует пользоваться рабочим стабильным решением. Я так и написал первым комментарием.
Но это уже решение другой задачи, понимаете — не той, что была в топике, с другими ограничениями и другой вводной. В топике — домашняя сеть и минимум телодвижений до, после и во время.
Как-то так.