Здравствуйте, Andy77, Вы писали:
A>По сравнению с Дартом, Тайпскрипт у меня не вызывает никакого энтузиазма по следующим причинам:
... A>- ДжетБрейновский WebStorm поддерживает дарт.
Здравствуйте, VladD2, Вы писали:
VD>Похоже на то, что Гугл открыл для себя не точный GC. VD>Интересно сколько времени им понадобиться чтобы открыть для себя точный GC
Точный GC у них есть внутри V8. Но внутри С++ кода самого браузера точный GC сделать или нельзя, или он будет сильно тормозить.
VD>и понял, что С++ и GC плохо совместимы?
C++ без GC они уже пробовали, получилось плохо. Что предлагаешь, GC без С++? Насколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.
Здравствуйте, D. Mon, Вы писали:
DM>Насколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.
А что, есть какие-то принципиальные проблемы сделать браузер на managed? по-моему это просто никому не надо вот и все.
Здравствуйте, Visor2004, Вы писали:
V>А что, есть какие-то принципиальные проблемы сделать браузер на managed? по-моему это просто никому не надо вот и все.
Скорость.
Здравствуйте, Visor2004, Вы писали:
V>А что, есть какие-то принципиальные проблемы сделать браузер на managed?
Никаких. Когда-то давно Сан чуть ли не с Явой такой поставлял.
V>по-моему это просто никому не надо вот и все.
Маразм сией ситуации в том, что единственным сдерживающим фактором при применении Явы и Дотнета (упрвляемых сред) являются накладные расходы связанные с GC. И вот Google на очередном витке эволюции переизобретает старое новое.
После перехода на точный GC смысла использовать С++ уже не будет никакого. Накладные расходы будут такими же как в случае Дотнета.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
V>>А что, есть какие-то принципиальные проблемы сделать браузер на managed? по-моему это просто никому не надо вот и все. А>Скорость.
Вот точный GC эту скорость и сожрет. Результат будет точно таким же как если бы код был написан на Яве или Дотнете.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Маразм сией ситуации в том, что единственным сдерживающим фактором при применении Явы и Дотнета (упрвляемых сред) являются накладные расходы связанные с GC. И вот Google на очередном витке эволюции переизобретает старое новое. VD>После перехода на точный GC смысла использовать С++ уже не будет никакого. Накладные расходы будут такими же как в случае Дотнета.
Не все так однозначно. Есть еще разница в качестве кодогенераторов. Плюс, С++ дает больше контроля над размещением в памяти, там есть почти бесплатная (де)аллокация на стеке и в аренах. С другой стороны, сейчас там у них использовались смартпоинтеры — по сути медленный и глючный reference counting GC. Сложно предсказать, какой из трех подходов в целом эффективней в их случае:
1) Как было: хороший кодогенератор + медленный и глючный RefCounting GC.
2) Как будет с Oilpan: хороший кодогенератор + пошустрее и не такой глючный tracing GC.
3) Java/Net: слабый кодогенератор и write barriers + эффективный generational tracing GC.
Здравствуйте, VladD2, Вы писали:
VD>Вот точный GC эту скорость и сожрет. Результат будет точно таким же как если бы код был написан на Яве или Дотнете.
Производительность они уже померяли и сошлись на том, что она приемлема (чуть быстрее в одних сценариях, на 10% медленнее в других). Уж насколько я люблю дот-нет, но хром я на нем представить не могу никак, даже оставив в стороне то, что его практически не существует на платформах, отличных от винды. Нафиг-нафиг.
Здравствуйте, D. Mon, Вы писали:
DM> асколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.
Разве раст менеджед?
Здравствуйте, D. Mon, Вы писали:
DM>C++ без GC они уже пробовали, получилось плохо. Что предлагаешь, GC без С++? Насколько я знаю, никому еще пока не удалось сделать браузер на managed языке. Мозилла вон собирается со своим Растом, но она уже много лет собирается, да никак не соберется.
Rust — это не managed-язык. Точнее, он managed, но совсем не в стиле Java/.NET
Из всех претендентов у Rust шансы сделать что-то реальное самые высокие. Уже есть прототип engine'а: https://github.com/mozilla/servo
Sapienti sat!
Re[15]: Java to Dart, C# to Dart code converter
От:
Аноним
Дата:
18.12.13 08:15
Оценка:
Здравствуйте, D. Mon, Вы писали:
По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать
1. Полноценный GC
2. Подсчет ссылок и удаление объектов с нулевыми ссылками. (циклические не удаляются до окончания работы)
3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)
Но Го медленнее С++ примерно в 2 раза, даже без учета проблем с GC. Может потом поправят. Правда с параллельностью там супер.
Вообще один из самых быстрых языков программирования это фортран. Сейчас он даже в парсинге рвет С. Но прогеть на нем... сами понимаете как приятно.
Здравствуйте, Аноним, Вы писали:
А>По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать А>1. Полноценный GC А>2. Подсчет ссылок и удаление объектов с нулевыми ссылками. (циклические не удаляются до окончания работы) А>3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)
Хм, а где об этом можно почитать? В документации на golang.org ничего подобного я не увидел.
Последнее, что я видел на эту тему в Go, — там был частично консервативный stop-the-world mark-and-sweep GC.
Re[17]: Java to Dart, C# to Dart code converter
От:
Аноним
Дата:
18.12.13 13:30
Оценка:
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Аноним, Вы писали:
А>>По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать А>>1. Полноценный GC А>>2. Подсчет ссылок и удаление объектов с нулевыми ссылками. (циклические не удаляются до окончания работы) А>>3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)
DM>Хм, а где об этом можно почитать? В документации на golang.org ничего подобного я не увидел. DM>Последнее, что я видел на эту тему в Go, — там был частично консервативный stop-the-world mark-and-sweep GC.
Тоже не нашел сейчас.
Была статья по хайлоад. Там народ запускал горотины и что бы на них не происходило подвисание просто в горотинах выключал гарбажколекшн.
Потом периодически запускал дополнительные горотины, а старые убивал. Именно оттуда и верхний список.
Здравствуйте, Аноним, Вы писали:
А>По мне идеальный вариант сделан с ГО. Когда вызывается ГоРотина создается новый GC причем можно указать как он будет работать
Это неверно. В Go все объекты лежат в общей куче.
А>3. Очищать всю выделенную память только при окончании работы горотины (т.е. во время работы память только выделяется, не нужен даже подсчет ссылок)
Это невозможно, так как горутина может мутировать глобально доступные объекты, добавляя в них ссылки на объекты, созданные в горутине.
Здравствуйте, D. Mon, Вы писали:
DE>>Разве раст менеджед? DM>Не в смысле .Net, но кое-какой GC там имеется.
Он там становится совсем опциональным, хотя на практике ПОЛНОСТЬЮ избежать его использования очень сложно.
Хотя это особо и не надо, так как GC нужен сильно меньше за счёт механизма заимствования указателей и изоляции зелёных потоков.