LINUX.ORG.RU

Mono 1.9 Released

 ,


0

0

Сегодня стал доступен для скачивания новый стабильный релиз свободной реализации .NET Framework - Mono 1.9. Это последний релиз ветки 1.х, перед версией 2.0.

Изменения:

  • Полная поддержка generics на уровне VM.
  • Поддержка C# 3.0 по умолчанию.
  • Включена работа с Silverlight по умолчанию.
  • Исправления в подсистеме рефлексии (обязательно обновите Gtk#!).
  • AOT теперь работает и для ARM-процессоров.
  • Добавлена утилита для визуального сравнения API библиотек (с целью выявления регрессий) - GuiCompare.
  • Windows.Forms использует родной бэкенд для Mac OS X (без X11).
  • Оптимизация скорости System.Web.
  • Новая система маппинга конфигураций ASP.NET, которая призвана обеспечить беспроблемный перенос ASP.NET сайтов под Mono.
  • Исправлена кучка ошибок.
Ждем 2.0!

>>> Подробности

Ответ на: комментарий от tailgunner

>> std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов. Такие объемы не один здоровый человек в ОЗУ хранить не будет

>Признайся - ты начинал программировать на PIC'ах? 8)

Нет, у меня коллекции обычно бывают элементов по 10. Данные хранятся в БД обычно. Была работка с большими tiff файлами, там я мапил нужный кусок файла в память.

Absurd ★★★
()
Ответ на: комментарий от Absurd

Абсурд, выражайся подлиннее и попонятней, ибо даже если ты дело говоришь понять тебя очень сложно...

> Нет, у меня коллекции обычно бывают элементов по 10.

The reserve() function sets the capacity of the vector to at least size.

А еще можно свой vector в 10 строчек написать вокруг стд::вектор

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Absurd

>>> std::list начинает обгонять std::vector при объеме коллекции более тысячи элементов. Такие объемы не один здоровый человек в ОЗУ хранить не будет

>>Признайся - ты начинал программировать на PIC'ах? 8)

> Нет, у меня коллекции обычно бывают элементов по 10

А сколько у тебя коллеуций?

> Данные хранятся в БД обычно

Есть куча задач, которые ворочают большими объемами данных, не используя БД; даже без временных файлов.

Ты, наверное, на Яве пишешь? Прикинь, сколько объектов хранит JVM для своих внутренних нужд :D

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> Нет, у меня коллекции обычно бывают элементов по 10

>А сколько у тебя коллеуций?

Какая разница - для коллекций в 10 элементов ничего проме плоского массива не нужно.

>> Данные хранятся в БД обычно

>Есть куча задач, которые ворочают большими объемами данных, не используя БД; даже без временных файлов.

Тут нужен особый подход типа маппинга файла в память по кускам. Я уже писал про это в своем посте.

>Ты, наверное, на Яве пишешь? Прикинь, сколько объектов хранит JVM для своих внутренних нужд :D

Объекты jvm не критичны. Пользователь не боится их потерять. А вот если из-за скачка напряжения пользователь потеряет свои данные из-за того что приложение ими оперирует чисто в ОЗУ, то это плохо.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>> А сколько у тебя коллеуций?

> Какая разница

Просто интересно - сколько объектов у тебя в программе, раз список в 1000 элементов вызывает такие чувства.

>>Есть куча задач, которые ворочают большими объемами данных, не используя БД; даже без временных файлов.

>Тут нужен особый подход типа маппинга файла в память по кускам.

Нет. Напимер, моделирование: там мегабайты (или сотни мегабайт) данных, которые никогда не будут лежать ни в каком файле - они существуют только в момент моделирования. Или задача управления - там очереди из сотен и тысяч элементов - обычное дело.

>>Ты, наверное, на Яве пишешь? Прикинь, сколько объектов хранит JVM для своих внутренних нужд :D

>Объекты jvm не критичны. Пользователь не боится их потерять

lookup-таблицы тоже некритичны. И AST/GIMPLE/RTL, которые достигают десятков и сотен мегабайт - некритичны. И еще много чего - не критично, но много по оъему, и всё это нужно где-то хранить.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>> А сколько у тебя коллеуций?

>> Какая разница

>Просто интересно - сколько объектов у тебя в программе, раз список в 1000 элементов вызывает такие чувства.

Каждый случай когда нужен список в 1000 элементов c большим количеством вставок/удалений из середины отличается, скажем так, индивидуальностью, и штамповка с применением стандартной библиотеки тут не прокатит.

>>Тут нужен особый подход типа маппинга файла в память по кускам.

>Нет. Напимер, моделирование: там мегабайты (или сотни мегабайт) данных, которые никогда не будут лежать ни в каком файле - они существуют только в момент моделирования. Или задача управления - там очереди из сотен и тысяч элементов - обычное дело.

А как это должно масштабироваться? Просто для таких тажелых задач надо предусмотреть работу в кластере. Если кому-то надо сотню мегабайт, то другому клиенту понадобится сотня гигабайт под ту же программу. Как машины в кластере будут между собой шарить память?

Absurd ★★★
()
Ответ на: комментарий от Absurd

>>Просто интересно - сколько объектов у тебя в программе, раз список в 1000 элементов вызывает такие чувства.

>Каждый случай когда нужен список в 1000 элементов c большим количеством вставок/удалений из середины отличается, скажем так, индивидуальностью, и штамповка с применением стандартной библиотеки тут не прокатит.

Сказал - как отрезал. А приводить доводы - не царское это дело.

>>Нет. Напимер, моделирование: там мегабайты (или сотни мегабайт) данных, которые никогда не будут лежать ни в каком файле - они существуют только в момент моделирования. Или задача управления - там очереди из сотен и тысяч элементов - обычное дело.

>А как это должно масштабироваться?

Ы? Причем здесь масштабирование? Я говорю о задачах, в которых длина внутренних списков - тысячи и десятки тысяч элементов, и вполне "здравые люди" хранят их в ОЗУ (блин, ОЗУ для этого и сделано).

> Просто для таких тажелых задач надо предусмотреть работу в кластере. Если кому-то надо сотню мегабайт, то другому клиенту понадобится сотня гигабайт под ту же программу.

Ыыыы... я кластеры сам не программировал, но 1) по нынешним временам сотни мег - это ни разу не тяжелая задача 2) подозреваю, что в кластере такие задачи просто разбиваются на части, а внутренние структуры данных остаются теми же или похожими.

> Как они между собой будут шарить память?

Зачем?

P.S. лехкое масштабирование с единиц мегабайтов до сотен гигабайт - это из области антинаучной фантастики. Наверняка архитектуры программ буду сильно разными... но внутри них всё равно будет STL и списки в много тысяч объектов :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>Каждый случай когда нужен список в 1000 элементов c большим количеством вставок/удалений из середины отличается, скажем так, индивидуальностью, и штамповка с применением стандартной библиотеки тут не прокатит.

>Сказал - как отрезал. А приводить доводы - не царское это дело.

В моей практике это так. Мне всегда удавалось чанки по 1000+ элементов обрабатывать потоковым образом. И очень часто приходилось рефакторить быдлокод сжиравший весь своп из-за того что какой-то Петя Вупкин не видит другого способа работы с данными кроме как загнать все в массив и дальше фигаить свой любимый fot i = 0 to data.size()

>>А как это должно масштабироваться?

>Ы? Причем здесь масштабирование? Я говорю о задачах, в которых длина внутренних списков - тысячи и десятки тысяч элементов

Корректная программа должна сожрать любой массив входных данных и дать правильный результат. При недостатке ОЗУ может страдать перформанс, но программа всегда должна выполнять свою задачу. Давай только не будем выковыривать из носа вопиющие случаи для красного словца.

> и вполне "здравые люди" хранят их в ОЗУ (блин, ОЗУ для этого и сделано)

Когда ОЗУ не существовало, уже были аппараты для цифрового масштабирования фотографий, на кратные порядки разумеется. ОЗУ всегда было окном для текущего scope данных, необходимых алгоритму + кэш чтобы слишком часто диском не трещать. Все остальное всегда писали на диск. Даже в видеоиграх, где дан целый город или страна для исследования типа Ultima 9 данные в фоне подсасываются с диска.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Когда ОЗУ не существовало, уже были аппараты для цифрового масштабирования фотографий, на кратные порядки разумеется.

Эт... если у тебя BMP 4Кх4К пикселей, и тебе надо получить ВМР 2Кх2К, то без 2К ОЗУ ты ниче не сможешь... а если мне дать 2К ОЗУ, то я тебе уменьшу и НЕ на кратный порядок, причем за один проход :-)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> если у тебя BMP 4Кх4К пикселей, и тебе надо получить ВМР 2Кх2К, то без 2К ОЗУ ты ниче не сможешь

я имел в виду один проход конечно

_________________________________

А stl написана совсем не в стиле "глотаем все и фигачим for"

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Absurd

> ОЗУ всегда было окном для текущего scope данных, необходимых алгоритму + кэш чтобы слишком часто диском не трещать.

Поправь меня, если я ошибаюсь, но ОЗУ появилось раньше диска :D А потом появилась виртуальная память.

По-любому, ОЗУ нужно использовать в полной мере.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Поправь меня, если я ошибаюсь, но ОЗУ появилось раньше диска :D А потом появилась виртуальная память.

Вначале была такая память, *одновременно* ОЗУ и диск -- матрица из магнитных колечек. У одного моего знакомого сохранилась :-)

> По-любому, ОЗУ нужно использовать в полной мере.

Это точно. И даже можно компилятор писать по принципу "все исходники и инклюды засосал в ОЗУ, а потом..."

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>> Поправь меня, если я ошибаюсь, но ОЗУ появилось раньше диска :D А потом появилась виртуальная память.

> Вначале была такая память, *одновременно* ОЗУ и диск -- матрица из магнитных колечек

ОЗУ на ферритах была не «вначале» :) И никогда не была «диском». Откуда там диски, когда это были кубы? :D

KRoN73 ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Вначале была такая память, *одновременно* ОЗУ и диск -- матрица из магнитных колечек. У одного моего знакомого сохранилась :-)

Все возвращается обратно, скоро тоже будет ОЗУ и диск одно и то же. http://forum.ixbt.com/topic.cgi?id=11:35827

>Ты можешь обоснованно высказать претензии к .net? Не можешь. Убейся.

.NET маркетинговая шелуха Microsoft. Nuff said. Убейся

Ни на соляре, ни на ARM, ни на AIX .NET не запустится. Этого достаточно. Nuff said

anonymous
()
Ответ на: комментарий от anonymous

>Ни на соляре, ни на ARM, ни на AIX .NET не запустится. Этого достаточно. Nuff said

вполне достаточно чтобы она запустилась у 90 процентов вантузятников, хотя я с тобой согласен - это инструмент в руках MS.

anonymous
()
Ответ на: комментарий от anonymous

> Открой для себя DotGNU!

Открой для себя мануал по дотгну и почитай. а потом почитай что такое .net от мс. и можешь смело утопиться в ванной.

anonymous
()
Ответ на: комментарий от anonymous

Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

anonymous
()
Ответ на: комментарий от anonymous

>Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

Mono!=MS.NET

anonymous
()
Ответ на: комментарий от anonymous

>Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

Mono!=MS.NET

anonymous
()
Ответ на: комментарий от anonymous

MS.NET = mono + $$$

mono = MS.NET - $$$

mono < MS.NET

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.