Помеченные указатели (tagged pointers) техника старая как мир. Основывается она на том, большинство распределителей памяти и так выделяют выровненную память и указатели оказываются кратными какой-нибудь степени двойки. Делается это по разным причинам, зависящим от конкретного аллокатора, от фундаментального желания гарантировать правильное выравнивание для данных, которое CPU удовлетворит, до желания уменьшить какие-то внутренние структуры данных. glibc например гарантирует выравнивание на 8 (или даже на 16 на 64-битной системе) для памяти, т.е. младшие 3 бита указателей возвращаемых mallocом всегда 0. (другое дело, что malloc для реализации кучи в VM лучше не использовать, но это другая история). Разумеется это привносит определенную фрагментацию в кучу, но практика показывает, что она не так уж и страшна.
PyPy как-то живет с этим различием. Я не большой специалист по Python, но если нативные расширения и __del__ не использовать, то особо ничего ведь заметно не должно быть.
Он, конечно, не обязательно будет сильно медленнее, но просто будет медленнее. Основное ограничение это, конечно, однопоточность, хорошему GC неплохо бы параллелить все что можно, а еще лучше быть concurrent. Далее если у нас двигающий сборщик мусора, то неплохо бы чтобы копирование (и инициализация памяти) было реализовано наиболее быстрым образом для машины, на которой мы исполняемся (а это значит где-то может даже через xmm регистры надо изголяться память копировать). В asm.js нету паттерна, который бы распознался как «копирование памяти», значит будет циклик. Ну в заключение в сборщиках еще часто есть всякая инфраструктура написанная руками на ассемблере (e.g. write/read barriers), но да это относится к тому же разряду, что и JIT код — просто так на asm.js не переводится.
Самое главное мне просто непонятно, зачем воротить свой собственный GC, когда GC уже есть готовый :)
Ну вшиты не вшиты, но должны ощущаться как граждане первого класса, не должна абстракция протекать… А в JS только копни любую ОО реализацию, сразу прототипы видны.
Я против Дарт как инициативы по замене JS.
А я вам и не предлагаю в своей коробке инструментов заменять JS на Dart. Я все пытаюсь вам объяснить, что Dart — это предложение для тех, кто видит в нем пользу. Но вы мне не верите, я уж не знаю, что мне такое написать, чтобы вы мне поверили, что никто не может прийти и отобрать у вас JS. Это невозможно.
Ну в мире вообще говоря много языков программирования. Если экосистема языка достаточна богата, то задумываться о взаимодействии с другими языками нет необходимости, лишь бы сама эта экосистема была внутри согласованна. В случае когда у нас все программируют ОО в силу своих представлений о красоте согласованность как бы отсутствует.
С другой стороны мне интересно развитие идей Web Component, когда вы можете свое приложение собрать из инкапсулированных кусочков (Custom Elements) и вам нет необходимости задумываться о том, как они реализованы, и на каком языке, потому что они черные ящики. Но даже здесь возникают проблемы, потому что не всегда понятно что означает extend в таком случае, семантика опять оказывается привязана к языку.
Подсчет ссылок это разновидность GC строго говоря. Суть в том, что низлежащая VM обычно уже имеет свой собственный сборщик мусора и достаточно эффективный (потому что он имеет доступ к голому железу и параллелизму), и выстраивая свой собственный GC мы теряем в производительности.
Да я в курсе классов в ES6 и считаю, что очень хорошо, что их ввели, boilerplate у людей из кода станет постепенно исчезать. Проблема в том, что все остальные способы эмуляции классов остались, поэтому я бы ожидал, что особые любители так и продолжат делать свое собственное.
Более того возникает интересная ситуация когда люди могут вроде писать код на JS, потому что class выглядит похоже на то, что они где-то видели, но при этом не понимаю что происходит на самом деле, потому что внутри этот class реализован на основе прототипов. Люди будут себе ноги и руки отстреливать время от времени.
stalkerg скорее всего Lars Bak имеет ввиду, я не настолько известный разработчик V8 ушедший в Dart, чтобы меня цитировать, к тому же я не согласен со словами «нереально», я считаю что в V8 есть много чего, что весьма реально улучшить и что будет улучшено.
Я бы это назвал эмуляцией мультипарадигменности. Разницу с настоящей мультипарадигменностью почувствовать легко: там все парадигмы являются частью языка, а не состоят из спичек и изоленты. Можно допустим себя спросить: «А вот если я хочу ключевое слово super для делегации к методам предка, то через какое место мне нужно этого добиваться?», и все становится ясно.
Осталось показать, что 90% команд фиксируют одну и ту же модель.
Да было бы интересно включить такой вопрос в JavaScript Developers Survey. У меня есть ощущение, что большинство все-таки использует constructor+prototype.
используют совершенно разные подходы.
И вы считаете, что это хорошо? Мне почему-то ситуация, когда у нас есть фреймворки с несовместимыми объектными моделями кажется странной и неудобной, и не привносящей никакой пользы.
Ни одно правило не является догмой, и не надо применять никакие правила бездумно.
Правильно. А теперь у меня вопрос, даже два.
1. Фиксированная ли у вас в комманде объектная модель? Или каждый объекты делает как хочет? Мне почему-то кажется, что она фиксированная, и более того у вас есть библиотечка со всякими утилитными функциями, которая позволяет вам эмулировать выбранную парадигму ОО.
2. Почему вы эту конвенцию не стремитесь применить к JavaScript в целом. Например, кто сказал, что JS должен быть единственным языком, к которому программисты должны иметь доступ?
У меня осталось воспоминание, что в том топике мы с вами ходили по кругу, и мы опять ходим по кругу здесь с одинаковыми аргументами и контраргументами.
Dart в Firefox не работает — это JavaScript работает в FF
Странная логика, JS-то вы не руками написали, он прямым образом получился из Dart программы и выполняет не что-то там случайное, а что в Dart программе было написано… Пользуясь вашей логикой можно ведь сказать, что Dart вообще нигде не работает, потому что CPU его не понимает, и это x86 (ARM, MIPS, etc) assembly, который работает на CPU.
Browser+JS это просто такая платформа, как CLR или там CPU+OS.
Напишите ещё «Amazon EC2 поддерживает Dart», ага.
Хорошо, коробка на официальная Herokuвская, но это не отменяет того факта, что вы можете там хостить свой server-side Dart без какой-либо привязки, которой вы так опасаетесь.
Есть даже стартап, который хочет предложить Dart PaaS: www.dartvoid.com/
Т.е. вы против разнообразия? Оооок.
Я за выразительные возможности и я против зоопарка :-) Опять же нужно понять: чем оно это разнообразие эмуляции ООП так полезно? Где здесь прибыль в виде ускорения разработки? Если 90% команд фиксируют одну и ту же модель эмуляции ООП на уровне конвенций о стиле разработки, то нет никакой пользы от разнообразия, а иногда оно просто вредит переиспользованию стороннего кода, который совсем не обязательно нормально вписывается в конвенции, установленные в вашей команде.
где в текущем треде вы увидели «негатив»
Для меня негатив состоит в том, что вы очевидно видите некий злой умысел за Dart, предполагаете, что кто-то хочет вам Dart «навязывать» и «привязывать». Кто-то хочет взять отключить JavaScript одной темной ночью и т.д. Это явно не нейтральные и точно не позитивные эмоции по отношению к Dart.
Как вы себе представляете реализацию такого плана: сегодня JavaScript работает, а завтра перестал? Мне становится смешно, это же очевидно не работоспособная идея. Такое может случится, только если JavaScript будет использоваться на 0.0000000000000000001% сайтов, а я сомневаюсь что такая ситуация когда либо возникнет. В каком-то смысле web это универсальная демократия.
Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
Вы не могли бы освежить мою память и напомнить, например, предыдущие три раза, когда вы пытались от меня добиться ответа на этот вопрос.
Вы выше ссылку давали на свой топик, в котором вы объясняли почему лично вам Dart не нужен. Мы там с вами дискутировали навязывает ли вам кто-то что-то и привязывает ли вас кто-то к чему-то, но как-то так и не пришли к пониманию.
Оно НЕ работает ни в Firefox, ни на Heroku (только через трансляцию в JS).
Как-то я вас не понимаю, вы в одном предложении одновременно говорите «оно не работает, но оно работает». Трансляция Dart в JS это его встроенная фича, так сказать. Он проектировался, чтобы более менее нормально транслироваться в JS и исполнятся даже в браузерах, которые его нативно не поддерживают.
LL лишнее. Dart VM это Dart Virtual Machine, а LLVM это из другой оперы вообще.
Ок, опциональная статическая типизация — так лучше?
Да.
Прототипное ООП — такое же ООП, как и классовое.
Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия. Кто как хочет, так и рисует свои иерархии. Кто-то на конструкторах+прототипах (что часто называют «прототипным ООП», но что имеет весьма косвенное отношение к настоящему прототипному ООП из, скажем, Self), кто-то Object.create, кто-то клонирует (т.е. все-таки пытается прототипное ООП изобразить) и так далее. Точно такой же зоопарк в реализации делегации и в наследовании и в способах делать mixinы.
Большие команды обычно ставят жестокие рамки на то, как код должен писаться и тем спасаются.
А в Dart спасаться не нужно. Есть одно нормальное ООП и всё :-)
Ну да я вам этот аргумент, уже приводил (см. опять же свой топик), но вы его отметаете и говорите, что преимущества «неназываемы». Ну да и ладно, если вам Dart не нужен, я убеждать вас не буду, для меня главнее, чтобы разработчики, которые видят преимущества Dart для себя, могли его комфортно использовать и чтобы сомневающиеся видели достоинства и недостатки, а не просто негатив от людей, которые видят в языке (по совершенно непонятным мне причинам) какой-то злой умысел, а не желание облегчтить web разработку.
Я от вас много раз пытался добиться, что же такого в Dart привязанного «к гугловой платформе», но так как-то не получается. Если оно работает нормально в Firefox и скажем лежит на Heroku, а стандартизацией языка занимается комитет в ECMA (TC-52), то где здесь привязка к чему либо?
Далее было бы очень прикольно, если бы Mozilla разработала свою собственную Dart VM. Потому что конкуренция порождает прогресс :-)
Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».
Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
«Окружение», а точнее использованные библиотеки, включено в тот самый единственный js файл, который вы получили на выходе из dart2js. Причем dart2js старается выкинуть все, что не используется и оставить только те фрагменты библиотеки, которые реально использовались.
Основной дополнительный размер обычно приходит из dart:html, потому что он уж слишком причесанный по сравнению с нормальным DOM (как пример вместо NodeList везде нормальные коллекции).
Транслятор Python в asm.js сделать проблематично, потому что единственное, что в asm.js удобно компилировать, это низкоуровневые статически типизированные языки типа C/C++. Нету ни поддержки сборки мусора, ни возможности положится на адаптивные оптимизации предоставляемые низлежащей виртуальной машиной. Как следствие языки типа Python или даже Dart никакой пользы от asm.js в той форме, в которой его Mozilla специфицировала сейчас, не получают.
Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину (написанную на языке типа C) компилируют в asm.js, как результат у нас получается GC, реализованный на asm.js, исполняющийся на виртуальной машине, которая имеет свой собственный более эффективный GC. Замечательно. Особые умельцы при этом могут даже реализовать для скомпилированной виртуальной машины JIT-backend, который выдает asm.js вместо машинного кода… Пример pypy.js. Правда ирония заключается в том, что согласно его последним цифрам pypy.js быстрее работает на V8, которая не поддерживает asm.js специальным образом, а не на SpiderMonkey, которая для asm.js имеет AOT-компилятор: twitter.com/rfkelly/status/409787571703529472
В оригинале используется именно такая конструкция «within 2.5X of the Java Virtual Machine», что переводится с сохранением смысла «в пределах 2.5X от JVM».
Как в оригинале, так и в переводе есть неоднозначность: непонятно, что понимается под мерой «performance» («производительность» — это ведь не «скорость») и как эта мера сравнивается «больше = лучше» (скорость) или «меньше = лучше» (время). Я написал Дэвиду DM в Twitter, попросил его уточнить, что понимается под этой фразой и «где бенчмарки». Посмотрим, что он ответит, когда проснётся.
Есть у меня вот такая ссылка www.50ply.com/cljs-bench/, на основе которой я могу сделать предположение, что «performance» — это «время».
мы часто наблюдаем замедление не превышающее 2.5X по сравнению с JVM
Первый абзац переведен неправильно, «this» относится к твиту.
We've known this for some time over here in the ClojureScript corner of the world — all of our collections are immutable and modeled directly on the original Clojure versions written in Java. Modern JavaScript engines have now been tuned to the point that it's no longer uncommon to see collection performance within 2.5X of the Java Virtual Machine.
Нам, в нашем ClojureScript-углу, это [т.е. факт, что производительность JS совсем не плоха] было известно уже давно — все наши структуры данным неизменяемы и основаны на оригинальных коллекциях из Clojure, написанных на Java. Современные JavaScript движки в настоящее время достаточно оптимизированы и мы часто наблюдаем производительность этих коллекций в пределах 2.5X от JVM [здесь, я думаю, 2.5X означает «2.5X медленнее», а не быстрее как вы перевели]
Он, конечно, не обязательно будет сильно медленнее, но просто будет медленнее. Основное ограничение это, конечно, однопоточность, хорошему GC неплохо бы параллелить все что можно, а еще лучше быть concurrent. Далее если у нас двигающий сборщик мусора, то неплохо бы чтобы копирование (и инициализация памяти) было реализовано наиболее быстрым образом для машины, на которой мы исполняемся (а это значит где-то может даже через xmm регистры надо изголяться память копировать). В asm.js нету паттерна, который бы распознался как «копирование памяти», значит будет циклик. Ну в заключение в сборщиках еще часто есть всякая инфраструктура написанная руками на ассемблере (e.g. write/read barriers), но да это относится к тому же разряду, что и JIT код — просто так на asm.js не переводится.
Самое главное мне просто непонятно, зачем воротить свой собственный GC, когда GC уже есть готовый :)
Ну вшиты не вшиты, но должны ощущаться как граждане первого класса, не должна абстракция протекать… А в JS только копни любую ОО реализацию, сразу прототипы видны.
А я вам и не предлагаю в своей коробке инструментов заменять JS на Dart. Я все пытаюсь вам объяснить, что Dart — это предложение для тех, кто видит в нем пользу. Но вы мне не верите, я уж не знаю, что мне такое написать, чтобы вы мне поверили, что никто не может прийти и отобрать у вас JS. Это невозможно.
С другой стороны мне интересно развитие идей Web Component, когда вы можете свое приложение собрать из инкапсулированных кусочков (Custom Elements) и вам нет необходимости задумываться о том, как они реализованы, и на каком языке, потому что они черные ящики. Но даже здесь возникают проблемы, потому что не всегда понятно что означает extend в таком случае, семантика опять оказывается привязана к языку.
Я как бы все еще до этого понял, см. второй абзац «Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину...».
Суть в том, что это не будет транслятор Python в asm.js. Это будет виртуальная машина языка Python транслированная в asm.js со всеми вытекающими.
тьфу, Cython. это не CPython. Прошу прощения. Ну, конечно, если взять статически типизированный язык то все работает.
Более того возникает интересная ситуация когда люди могут вроде писать код на JS, потому что class выглядит похоже на то, что они где-то видели, но при этом не понимаю что происходит на самом деле, потому что внутри этот class реализован на основе прототипов. Люди будут себе ноги и руки отстреливать время от времени.
Я бы это назвал эмуляцией мультипарадигменности. Разницу с настоящей мультипарадигменностью почувствовать легко: там все парадигмы являются частью языка, а не состоят из спичек и изоленты. Можно допустим себя спросить: «А вот если я хочу ключевое слово
superдля делегации к методам предка, то через какое место мне нужно этого добиваться?», и все становится ясно.Да было бы интересно включить такой вопрос в JavaScript Developers Survey. У меня есть ощущение, что большинство все-таки использует constructor+prototype.
И вы считаете, что это хорошо? Мне почему-то ситуация, когда у нас есть фреймворки с несовместимыми объектными моделями кажется странной и неудобной, и не привносящей никакой пользы.
Правильно. А теперь у меня вопрос, даже два.
1. Фиксированная ли у вас в комманде объектная модель? Или каждый объекты делает как хочет? Мне почему-то кажется, что она фиксированная, и более того у вас есть библиотечка со всякими утилитными функциями, которая позволяет вам эмулировать выбранную парадигму ОО.
2. Почему вы эту конвенцию не стремитесь применить к JavaScript в целом. Например, кто сказал, что JS должен быть единственным языком, к которому программисты должны иметь доступ?
У меня осталось воспоминание, что в том топике мы с вами ходили по кругу, и мы опять ходим по кругу здесь с одинаковыми аргументами и контраргументами.
Странная логика, JS-то вы не руками написали, он прямым образом получился из Dart программы и выполняет не что-то там случайное, а что в Dart программе было написано… Пользуясь вашей логикой можно ведь сказать, что Dart вообще нигде не работает, потому что CPU его не понимает, и это x86 (ARM, MIPS, etc) assembly, который работает на CPU.
Browser+JS это просто такая платформа, как CLR или там CPU+OS.
Хорошо, коробка на официальная Herokuвская, но это не отменяет того факта, что вы можете там хостить свой server-side Dart без какой-либо привязки, которой вы так опасаетесь.
Есть даже стартап, который хочет предложить Dart PaaS: www.dartvoid.com/
Я за выразительные возможности и я против зоопарка :-) Опять же нужно понять: чем оно это разнообразие эмуляции ООП так полезно? Где здесь прибыль в виде ускорения разработки? Если 90% команд фиксируют одну и ту же модель эмуляции ООП на уровне конвенций о стиле разработки, то нет никакой пользы от разнообразия, а иногда оно просто вредит переиспользованию стороннего кода, который совсем не обязательно нормально вписывается в конвенции, установленные в вашей команде.
Для меня негатив состоит в том, что вы очевидно видите некий злой умысел за Dart, предполагаете, что кто-то хочет вам Dart «навязывать» и «привязывать». Кто-то хочет взять отключить JavaScript одной темной ночью и т.д. Это явно не нейтральные и точно не позитивные эмоции по отношению к Dart.
Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
Вы выше ссылку давали на свой топик, в котором вы объясняли почему лично вам Dart не нужен. Мы там с вами дискутировали навязывает ли вам кто-то что-то и привязывает ли вас кто-то к чему-то, но как-то так и не пришли к пониманию.
Как-то я вас не понимаю, вы в одном предложении одновременно говорите «оно не работает, но оно работает». Трансляция Dart в JS это его встроенная фича, так сказать. Он проектировался, чтобы более менее нормально транслироваться в JS и исполнятся даже в браузерах, которые его нативно не поддерживают.
А на Heroku Dart кстати из коробки работает blog.sethladd.com/2012/08/running-dart-in-cloud-with-heroku.html
LL лишнее. Dart VM это Dart Virtual Machine, а LLVM это из другой оперы вообще.
Да.
Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия. Кто как хочет, так и рисует свои иерархии. Кто-то на конструкторах+прототипах (что часто называют «прототипным ООП», но что имеет весьма косвенное отношение к настоящему прототипному ООП из, скажем, Self), кто-то Object.create, кто-то клонирует (т.е. все-таки пытается прототипное ООП изобразить) и так далее. Точно такой же зоопарк в реализации делегации и в наследовании и в способах делать mixinы.
Большие команды обычно ставят жестокие рамки на то, как код должен писаться и тем спасаются.
А в Dart спасаться не нужно. Есть одно нормальное ООП и всё :-)
Ну да я вам этот аргумент, уже приводил (см. опять же свой топик), но вы его отметаете и говорите, что преимущества «неназываемы». Ну да и ладно, если вам Dart не нужен, я убеждать вас не буду, для меня главнее, чтобы разработчики, которые видят преимущества Dart для себя, могли его комфортно использовать и чтобы сомневающиеся видели достоинства и недостатки, а не просто негатив от людей, которые видят в языке (по совершенно непонятным мне причинам) какой-то злой умысел, а не желание облегчтить web разработку.
Далее было бы очень прикольно, если бы Mozilla разработала свою собственную Dart VM. Потому что конкуренция порождает прогресс :-)
Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».
Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
Основной дополнительный размер обычно приходит из
dart:html, потому что он уж слишком причесанный по сравнению с нормальным DOM (как пример вместо NodeList везде нормальные коллекции).Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину (написанную на языке типа C) компилируют в asm.js, как результат у нас получается GC, реализованный на asm.js, исполняющийся на виртуальной машине, которая имеет свой собственный более эффективный GC. Замечательно. Особые умельцы при этом могут даже реализовать для скомпилированной виртуальной машины JIT-backend, который выдает asm.js вместо машинного кода… Пример pypy.js. Правда ирония заключается в том, что согласно его последним цифрам pypy.js быстрее работает на V8, которая не поддерживает asm.js специальным образом, а не на SpiderMonkey, которая для asm.js имеет AOT-компилятор: twitter.com/rfkelly/status/409787571703529472
Как в оригинале, так и в переводе есть неоднозначность: непонятно, что понимается под мерой «performance» («производительность» — это ведь не «скорость») и как эта мера сравнивается «больше = лучше» (скорость) или «меньше = лучше» (время). Я написал Дэвиду DM в Twitter, попросил его уточнить, что понимается под этой фразой и «где бенчмарки». Посмотрим, что он ответит, когда проснётся.
Есть у меня вот такая ссылка www.50ply.com/cljs-bench/, на основе которой я могу сделать предположение, что «performance» — это «время».