All streams
Search
Write a publication
Pull to refresh
0
@phponeloveread⁠-⁠only

User

Send message
Безотносительно лженаучности такого деления способностей человека, утверждение, что набор достаточно простых навыков недоступен кому-либо — очень сомнительное.

Дело не в простых навыках. Есть базовый уровень, а есть уровень за его гранью. Навыки это пусть и не прямое следствие способностей, но следствие. Если попроще — любой человек может научиться рисовать, петь, писать. Другое дело, что их навыки и плоды будут различны, даже в идентичных условиях, которые всё равно никогда не будет.

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

В это и проблема, что говорить о битах может кто угодно, особенно те, кто их в глаза не видел. Определяющим является не это.

Это, очевидно, может быть правдой. Только у вас есть ошибка в логике, ведь «технарь» не предполагает умение чего-то с рождения. Все, и технические, либо «технические» навыки не являются недоступными без этого самого «технаря». Как уже говорилось — человеку доступно всё, за одним нюансов — у каждого свой уровень погружения, своя скорость обучения.

И даже если доказать, что разницы в физиологи нет, то это ничего не доказывает. Становление человека обусловлено далеко не физиологией. Если, предположим, мои способности к рисованию равны оным у да Винчи, то из этого мало что следует. Меня это попросту не интересует. Я не понимаю как это делать, зачем это нужно. Со всеми вытекающими — моя продуктивность в этом деле, даже если я буду заставлять себя — будет меньше, чем в том, что мне нравиться.

Точно так же, из факта нахождения в ИТ не следует «технарь», ведь мы не можем сравнивать, даже создателей реакта и его пользователей. Да, формально сборщик мебели, который родил парочку инженерных решений — уже инженер, но только формально.

Поэтому, да, без способностей можно освоить начальные этапы любой деятельности, но только начальные. Да даже средние, но ни о чём выше речи не идёт. Таких людей никто не видел, а даже и видел, то их настолько мало( относительно тех, у кого были явные способности/желания), что ими можно пренебречь.

Можно думать что угодно, считать как угодно, но в реальной жизни это сплошь и рядом. Да, в это не хочется верить, как и в любую объективную оценку.

Во-первых, заявленная вами проблема воровства коинов владельцем — несуществующая проблема. Вот почему. Цель любой экономической системы и криптовалют в том числе — увеличить капитализацию, что, суть, равно увеличению числа пользователей.

Оставленные себе коины никак на капитализацию не влияют, точно так же как и кол-во коинов.

Это просто экономически не выгодно в долгосроке владельцу забирать себе все свои же коины.

А кто говорит про все? Есть замкнутая система, в которой крутиться 100 коинов, у неё есть капитализация. И фишка в том, что когда у владельца есть ещё 100коинов, которые есть, но которые существуют за рамками этой системы. Их можно туда вбросить и результаты очевидны. Реально купленные коины, которые должны продаваться на рынке — заменяются на свои, халявные коины. Все думают, что это те самые, купленные коины, а это не так.

Это то же самое, что фальшивые/эмитированные деньги вброшенные в систему. Результат будет тем же. Вбрасывающий получает ресурсы нахаляву, а все остальные получают инфляцию.

Биткоин — для меня более надежное долговое обязательство, нежели золото, которое не обеспечено ничем (кроме моды на блестящее и немного промышленности).

Нежели биткоин, который не обеспечен ничем (кроме моды на «блокчейн»/крипту и немного промышленности). На сегодняшний день обеспеченность биткоина ЭЭ — это 1/(17-20), что, скорее всего, даже меньше, чем у золота.

Все эти статьи, отзывы и прочее — содержат настолько феерическую подмену понятий, что ты сомневаешься в том — понимают ли люди то, о чём они говорят, либо нет.

Подмена понятий заключается в том, что отзывы о js к js ровным счётом не имеют никакого отношения. Хвалят именно возможность скриптинга в броузере, да и сам скриптинг никому не нужен — нужна возможность исполнять код и писать его на нормальном языке.

Поэтому, имея ввиду js можно говорить только о js, а не о его интеграции в броузер. Интегрировать в броузер можно совершенно любой язык, тот же пхп. И если, всё же, мы попытаемся поставить разницу между js и js browser api, то нужно как минимум доказать то, почему то же самое с другими языками не состоятельно, либо менее состоятельно.

Серьёзно? Давайте сравним.

Что вы хотели своим словоблудием сказать? Что опровергнуть? Что из этого следует?

Причём каждый из них должен знать о всех других GC, которые у вас есть.

Не должен. Это не из чего не следует, как из этого НИЧЕГО не следует.

Причём тут вообще язык? Языков в системе может быть сколько угодно. Вопрос в наличии/отсутствии GC в системе.

Никакого вопроса нет.

То, что у вас система позволяет запускать «произвольный» язык совершенно не обозначает, что вы «поверх этого» сможете реализовать GC.

К чему это и что это должно значить? Попытка слиться на эмуляцию? Нет, не получиться. Никому не интересно то, что «можно» запустить — всем интересно то, как это можно запустить, вернее то — что это даст. И под запустить имеется ввиду именно прямой запуск.

В PNaCl полноценный GC был невозможен, в ASM.js — теоретически возможен, но практически — крайне проблематичен.

И? Это проблемы PNaCl, а не ручного управления.

Ну да, конечно, зелен виноград, ой как зелен. Вам не кажется что ситуация, когда сотни тысяч (или даже миллионы?) проектов обходятся без GC плохо совместима с подобными заявляениямии.

Кто это должно знать и что из этого следует? Он им не нужен именно потому, что они без него жили и живут.

Вот на Java — GC почему-то нужен «прям всем».

Мир жава и мир С++ — это разные миры. Я не буду рассказывать об управляемости и производительности, но пойди там ораклу расскажите о том, что хотспот надо переписать на жаву и о том, что им нужен ГЦ.

Во вкрученном «внутрь» внушительной части этих проектов Python'е — GC тоже есть. Да даже в Objective C (который почти C, только «чуть лучше») GC был… раньше. А вот в C++ «это никому не нужно». Не странно ли это?

Нет. Сравнивать скриптуху и пускалки сишного/крестового рантайма с тем, на чём этот рантайм пишется — идиотская затея. Именно от того они и пускалки, что ни в каком ином назначении они не состоятельны.

Вот даже так. А кто тут песни пел про то, что ГЦ является «обычным куском рантайма, таким же как и любой malloc»? Вы уж определитесь, пожалуйста.

Поподробнее, где именно у меня тут противоречие? В чём мне надо определиться? Да, ГЦ обыкновенный кусок рантайма, и? Это как отменяет то, что реализация ГЦ на ГЦ рекурсивно зависит от ГЦ? Нет.

Malloc я могу спокойно писать на языке с malloc'ом, однако.

К чему это? И ГЦ можно писать на языке с ГЦ, и?

Суть в том, что языки( о которых я говорю) с маллоком никак от маллока не зависит, в отличии от языка с ГЦ. Если бы он зависел — была бы такая же рекурсивная зависимость.

Они работают с памятью напрямую и им маллок для этого не нужен. Маллок лишь некая абстракция, которая даёт и забирает куски памяти.

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

К сожалению на этом осмысленная часть рассуждения кончается, так как последующее словоблудие расшифровке не поддаётся, так что я ограничусь, пожалуй, обсуждением GC.

Слив засчитан. Кстати, что именно вы не смогли расшифровать и почему — вы ведь сможете мне показать и рассказать? А то, как я отличу «это словоблудие» от «мне нечего ответить — оправдаюсь тем, что безосновательно назову тезисы/аргументацию оппонента словоблудием»? Я должен вам поверить?

ИМХО если бы Танненбаум не вел себя, как высокомерный м… к, то развитие Линукса от этого бы только выиграло.

Тут проблема не в том, что он высокомерный, не в том, что minix «лучше», а в том, что он попросту не работает и ничего не может, а никому в реальности не рабочее не нужно.

С самим заявлением о том, что «используется minix» то же всё темным-темно. По какой причине был выбран minix? Случайно не из-за того, что она свободна, жива и кодовая база на порядки меньше, чем у linux? Случайно не по тому, что там bsd?

Что осталось от этой minix? Какую часть её интел переписал и сколько дописал. Вопрос так же открытый.

И Энди остался в истории, как твердолобый заносчивый теоретик, который может и знает, как лучше

Очень спорно. Мы знаем, что микроядро лучше, как и Энди знает. Что дальше? Его попросту не существует в природе. Существуют некие макеты, которые могут запускаться, но чем-то рабочим их сложно назвать.

В конечном итоге у нас есть то, что лучше, но реализаций чего в реальном мире не существует, и есть то, что хуже, но что существует. Попросту нельзя сравнит то, что есть и то, чего нет.

А так, все мы знаем, что хороший код лучше плохого, только вопрос не в этом. Вопрос в том, как нам получить этот рабочий код. Не на моделях, а в реальном мире. Это и есть проблема.

А подобное «я бы сделал лучше, но просто студентам нечего было бы делать» — это просто смешно. Это ведь признание того, что оно кривое, а как можно это кривой выдавать за альтернативу? Ведь тут нужно понять, что Энди «на щит» берёт не не микроядро, а именно minix — его реализацию. Это смахивает на манипуляцию.
V8 — это революция.
Если бы. Дело в том, что программирование в системе с ГЦ и без ГЦ — очень сильно разные вещи.

Идентичные.

При этом в системе с ГЦ можно программировать, как в системе без ГЦ — и это часто делается (кладём всё на массивы и «ручками» управляем из содержимым)

Нельзя. Вы просто авойдите вызовы ГЦ и не более того, все эти массивы точно так же пойдут в ГЦ.

ГЦ от управляемого хипа отличается только одним. В управляем есть new и delete, а в ГЦ есть только new. ГЦ — является обычным куском рантайма, таким же как и любой malloc. Поэтому, в языке без ГЦ вы можете заменить malloc на ГЦ и использовать только new, а вот в языке с ГЦ — нет, у вас ниоткуда delete не родиться и ГЦ не вырубится.

Много вы видели систем на C++ с ГЦ? Не на «сбоку прилепленным» C# (Java, Lisp — нужное подчеркнуть), а на С++?

К С++ прикручивается ГЦ за 5минут, только это никому не нужно. И тут говориться не об этом — говориться о рантайме. Любой рантайм с ГЦ зависит от ГЦ, а ГЦ — это такой же рантайм, который так же зависит от ГЦ, а значит он существовать не может. Таким образом ГЦ может существовать только тогда, когда он и связанный с ним рантайм не зависит от ГЦ, а значит его написать на языке с ГЦ НЕВОЗМОЖНО.

Вопрос только в том, что вы понимаете под словом «совершенное». А то пока получается тавтология: если технология А вытесняет технологию Б, то технология А — более совершенна… возможно, но если мы об этом можем узнать только пост-фактум, то что это нам даёт?

Причём тут какие-то технологии? Причём тут какое-то вытеснение? Есть реальность, в рамках которой никакого ГЦ нет, а есть уже обёртка над этой реальность — ГЦ.

Исходная форма — это всегда текст. Ну человеки, потому что, текст пока порождают.

Человеки никого не интересуют. Вы даже не поняли того, что там написано. Исходная форма для asmjs — это не текст, а это было сказано в контексте asmjs.

Если вы о «близкой к CPU» форме — то причём тут webasm?

При том, что никакого текста в природе не существует — существует бинарь и только он, а текст — это уже его представление.

Но текст никому не нужен сам по себе — текст, это представление данных в текстовой форме, что не является нативным для железяки, да и для программирования в целом. В рамках «близкой к CPU» форме числа не представляются как строки.

Для этого машинные коды есть…

Не для этого. Любая программа — это не только код, но и данные, да и сама программа — есть данные. А в рамках этих самих данных — существует некая структура.

Структуру данных «текстом» вообще никак невозможно организовать, поэтому «текстовая структура» выкидывается.

Никакого же текста попросту не существует, но его мы можем представить в бинарном формате. С этим никаких проблем нет.

К тому же, в тексте имеются некоторые интерпретируемые, т.е. текстовое представление неких отдельных объектов — те же числа. И железяка умеет в числа, и если искомое число возможно представить в железяке, то оно требует конвертации, иначе — железяка с ним работать не может. Таким образом — текстовое представление чисел — не нативно.

И такого масса, те же идентификаторы( из них код состоит на 80%+) — они так же могут иметь разное представление. И текстовые они — это так же «не нативно».

Именно поэтому бинарь и является исходной формой, исходной для машины формой. И asm — это лишь рядовой представитель. И исходная она не только для команд, исполняемых cpu, но и для данных. А код является данными.

Текст — это просто бинарный формат, который на самом деле представляет из себя поток байтов/битов. А любой поток, который ограничен форматом — является менее совершенным, нежели неограниченный, который является, по сути, множеством всех возможных форматов.

В этом и смысл совершенности, как полноты. И когда одна полнота полностью включает другую, но является несоизмеримо более полной — смысл существования другой — теряется. Она не нужна.

Именно поэтому ненужны и текстовые форматы, и тут нет места рассуждениям о «а как же читаемость человека» — они попросту несостоятельны. Причины просты:

Данные читает машина, которая не умеет в текст. Поэтому любая обработка текстовых форматов — есть to_binary | process | to_text, что попросту не имеет смысла.

И раз этот самый to_text уже существует, а значит бинарное представление является полным( оно всегда может быть полным), то это to_text можно поставить перед to_text | human_process | to_binary, таким образом — мы обеспечиваем человека текстовым форматом.

Это будет так же прозрачно, как и gzip. Очень смешно читать эти рассказы из комментов о том, «как же мне сложно будет читать tcpdump», только все эти комментаторы не знают, либо не хотят знать о том, что никакой текст по сети не гоняется — гоняется бинарь из-под gzip(подставь нужное).

Именно в этом и смысл webasm. Мы убираем AST | to_text | to_binary | browser_exec. Зачем нам это абсолютно бесполезное to_text | to_binary, к тому же — это не просто текст — это «js».

Причина, собственно, одна: Ларри сильно денег хотел.

Дело не в этом, всё это попросту не может быть альтернативой — ведь по-сути оно не отличается от js. Суть васма именно в том, чтобы не быть привязанным к какой-то платформе, языку — он на том и асм.

В результате «сливок» никому не досталось, и подходы, основанные на JVM (а это не только апплеты — были и другие интересные идеи) и подходы, основанные на CRL (Silverlight и прочее) оказались выкинутыми «на свалку истории», а мы остались с JavaScript'ом и, вот теперь уже, пытаемся переизобрести всё в третий раз…

Неверно, нигде и никак не переизобретаются все эти «идеи» — они умерли потому, что никому не нужны.

Причина проста — снизу должно быть то, что может быть снизу. На лоулевел языке можно реализовать хайлевел, а вот наоборот нет. К языку без ГЦ может прикрутить ГЦ, а вот наоборот нет. Именно в этом проблема — жаваскрипт. Жава ничем не отличается от жаваскрипта в этом плане. И нет смысла менять шило на мыло.

Асмжс и упёрся в проблемы жаваскрипта. Прозрачное взаимодействие с жс, текст, кастыли. Всё это никому не нужно. Зачем кому-то нужно превращать бинарь в текст, типизацию в синтаксические кастыли, если можно проще всё гонять в исходной форме?

И причина, как я уже говорил, не в самой форме, а в том, что это более «совершенная форма». Никому не нужно по сети гонять текст, никому не нужен запрос-ответ, никому всё это не нужно. Вернее нужно тем, кто к этому привык, но это субъективные желания.

Хочешь текст? Пожалуйста — бинарный проток это позволяет, а вот наоборот нет. Хочешь себе запрос-ответ — пожалуйста, всё это реализуется на базе более общего протокола.

Именно в этом суть — более «совершенное» вытесняет менее совершенное и ограниченное, ведь ограничить что-то всегда можно, а вот расширить — нет.
Не всегда — кэш сбрасывается.

И? Уже после выявляются новые обстоятельства? Пусть он хоть 10раз сбрасывается — это ничего не изменит.

В тот то и дело, что наоборот.

Никакого дела нет, есть увиденная где-то статья и ретранслирование из неё, с умным видом, цифр в интернете. При этом не просто ретранслирование, а натягивание совершенно на другие кейсы.

А по поводу матриц, кто-то спастив число из статьи очень сильно себя подставил, ведь он не дочитал до:
Why do the vertical lines stop at 4MB array length?

И вот если бы он дочитал, а потом посчитал, что 512х512 даже из даблов — это в 2раза менее 4мб, то он бы понял, что просто так пастить цифры их статьи глупо — можно попасть в лужу. Он в неё и попал.

Ну ладно, 513 для строк ещё можно объяснить тем, что имелись ввиду квадратные матрицы. Но тут уже подозрительно.

Да и к тому же, есть транспонирование.
1. Можно ли узнать, каким именно образом измерялось время выполнения функций? Какая гранулярность вашего таймера?

Не имеет значения. Даже если разрешение таймера на два порядка больше секундомера — этого достаточно. Хотя такого, естественно, что нету.

Не было ли миграции потока на другое ядро во время выполнения функции, делалось ли thread affinity?

Зачем? Сколько бы там их ни было — это копейки на фоне десятых долей секунды.

Если это tsc, то поддерживает ли проц функции:

Там написано какой проц.

И правильно ли снимались показания счетчика времени (наличие rdtcsp в системе команд еще не означает, что мы этой командой пользуемся. rdtsc выполняется на общем конвеере команд, в то время как rdtcsp обеспечивает hb)?

Абсолютно не имеет значение. Длинна конвейера ну десятки тысяч тактов, а измеряем мы миллиарды тактов.

работа с данными — штука, которая нагружает определенным образом подсистему памяти.

Из этого, ровным счётом, ничего не следует.

Если меряешь время алгоритмов, которые перелопачивают массивы, то нужно мерять разные длины массивов.

Это итак делается.

Потому, что из за эффектов с кэшом, решающую роль могут оказывать совсем не те эффекты, которые были при тестах с другим набором или размером данных.

Какие такие эффекты с кешом? Каким образом увеличение датасета повлияет на кеш? Если у нас есть решение А и решение Б, которое обладают определённым паттерном обращения к памяти, то увеличение датасета паттерн не поменяет. Они могут в разное время, с увеличением датасета, вылезти за какой-то левел кеша/памяти, но из этого ровным счётом ничего не следует — всё это сгладиться.

Сложность так же вызывает то, что эффекты с кэшом сильно зависят от того, как именно в памяти лежат данные.

Абсолютно неважно то, как они там лежат. Важно то, как к ним обращаются, а это уже следствие того, как они лежат. Да и из этого так же ничего не следует — если решение А лежит криво, то на каком угодно датасете оно будет криво.

Так, известно, что перемножение матриц 512х512 работает медленней, чем 513х513.

Какое гениальное открытие, оказывается, что в рамках системы, которая завязана на степени — работать со структура степени двойки проще и быстрее.

Можно так же нарваться на коллизии адресов TLB страниц — и этим просадить производительность.

Показать сможете?

Это все что я насобирал, просто чтобы понимать, что задача не такая простая, как кажется на первый взгляд.

Всё это — никакого отношения к задаче не имеет. Во-первых, кто ставил условие о том, что оно должно быть оптимальней за рамками указанного датасета? Во-вторых, кто и где мерил тут «микро-эффекты»? Третье, всё это можно свести к одно — измеряй на разных датасетах, но это итак сделано и это известная все элементарщина.

Сложность задачи не в том, что-бы измерить, а в том, чтобы понять — что мы намерили. И ни одного слова про это от вас не поступало.

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

Никакие секунды тут не причём. Секунды относятся только к точности измерения и не более, а они будут точными уже на сотых долях секунды — никаких микро-эффекты тут уже ни на что не влияют.

Вы рассуждали о каких-то там кешах, но сейчас показали даже не 5%, а 0. Если у нас датасет один и тот же — абсолютно неважно сколько секунд мы его долбим. Хоть час — это ничего не изменит. Время работы может быть следствием увеличением датасета, но не всегда и тут вам просто повезло.

Но конкретно в нашем случае, скорей всего, если дать больше данных, то основное время выполнения съест подситема подтягивания данных из памяти в кэш. Она не зависит от языка — и времена сравняются.

Никакая подсистема памяти никакое время не ест. Никакие подтягиваний данных в кеш ни на что не влияют — я даже не знают что надо сделать, чтобы это повлияло на измерения ТС — построить цепочку из RA в один байт длинною в l3.

Но всё это, конечно же, к теме отношения не имеет. Если у нас одной реализации надо что-то там подтягивать, то и другой так же. Если нам нужны эти данные — мы в любом случае обязаны их подтягивать. И каким образом нам это помешает что-то измерить — неясно.

Утверждения о том, что язык ни на что не влияет — не состоятельны. Язык — это возможности, а так же те, кто на нём пишет. Если в каком-то языке нету возможностей, либо тех, кто сможет их применить — это проблема языка.

Существует множество ручек, которые можно крутить. Начиная от организации структур данных, свободную организацию которых — позволяют единицы языков. Заканчивая всяким nt. И то, это только относительно летенси-цепочек.

Ручек же для трупута ещё больше — там уже есть параллельность. Это не говоря о том, что данные надо не только читать.

Скорей всего, если приложить усилия, более медленный код можно как-то переписать, чтобы он был равен быстрому. Но это нужно «закапываться» в вопрос.

Это ни из чего не следует. Есть ли тот, кто сможет его переписать? А есть ли в языке те возможности, которые необходимы? В этом основная проблема.

Этот комментарий нам никак не поможет

Ну что там далеко ходить — я взял и решил добить huffman_encoding. У меня не особо было время, поэтому я не стал заморачиваться и исправлять всю лапшу — я просто поменял encode() и уже в 5раз быстрее раста, а это оптимизация ещё даже не началась — я просто выпилил ненужную там хешмапу.

Замена подсчёта частоты на нормальный — уже в 10раз быстрее. И оптимизация всё ещё даже не начиналась.

struct string {
  
  string() {}
  
  string(const std::string & str) {
    if(str.length() > data.size()) throw std::runtime_error{"bad length"};
    len = str.length();
    strncpy(std::data(data), std::data(str), str.length());
  }
  
  operator std::string_view() { return {std::data(data), len};}
protected:
  std::array<char, 32 - 1> data;
  uint8_t len = 0;
};

struct encoder {
  encoder(const std::unordered_map<char, std::string> & map) {
    for(size_t i = 0; i < m.size(); ++i) {
      auto it = map.find(i);
      m[i] = (it != std::end(map)) ? it->second : "";
    }
  }
  
  std::string_view encode(char c) {
    return m[uint8_t(c)];
  }
  
  std::string encode(const std::string & str) {
    std::string out;
    out.reserve(str.length() * 32);
    for(auto & x : str) {
      out += encode(x);
    }
    return out;
  }
  
  std::array<string, 256> m;
};


Ничего особо не проверял — если работает, замените им своё.

Слив засчитан, а далее пошла ахинея.

Различий между безопасностью и выразительностью языков нет

Опять же, схема проста — подмени понятия в рамках тезиса, который определён в локальном контексте — на глобальные. И получается так, что я утверждал не то, что ты их не показал, не то, что ты врал и манипулировал, а говорил вообще — нет, я говорил не вообще, а о конкретных примерах.

То же самое и с libc — да, есть код и есть новомодные языки, которые претендуют на замену С/С++, но почему-то ни один из них не является самостоятельным, является нахлабучкой на С/С++ рантайм, на этих «языка» НИЧЕГО серьёзного не написано, кроме их компиляторов, хотя в случае раста и компилятора нет.

И что получается. Ничего нет, но трёп о том, что «выкидывай С++ хоть завтра» — есть. Дак выкинь, продемонстрируй как надо. Нет — никто этого не делает и не сделает.

Каждый год появляется новый убийца, каждый код появляются его адепты. В начале нулевых везде вещали о том, что жава все догнала и С/С++ ненужен. Потом релизнулся v8 и вещали о том, что С/С++ не нужен.

До раста ГЦ был моден и быстр, да и сам раст на нём был. Не фортануло — выкинули, и вот он уже не моден и не быстр и без него быстрого языка не сделаешь. Хотя адепты раста — это хаскелисты/лисписты, которые буквально вчера любили ГЦ.

И так было всегда, и будет всегда. Пока хайп есть — вы посторяете медийные тезисы, как только он сойдёт на нет и появится новое — будет новое. Вы же ничего не предлагаете, ничего не говорите — вы повторяете хрен пойми что и хрен пойми за кем.

Так всегда было есть и будет. Заходишь в тред по С++ и критикуешь кресты — тебя минусуют и «ты ничего не понимаешь». Эта слепая вера в то, что наш объект обожания идеален, что раз везде написано «проблем нет» — значит их действительно нет.

Мне уже давно не интересно этим заниматься — я даже не знаю зачем я снова тут отвечают, ведь отвечаю я в пустоту.
Т.е. о чем я и говорил.

Ни о чём ты не говорил. Ты как всегда сел в лужу, но пытаешься как-то из неё всплыть.

Любая оптимизация, которая затрагивает бинарную совместимость — это проблема. Точно так же, твой раст до это оптимизации и после — не соберётся. Тебе же это никак не помешало. Вот и не помешает сейчас.

Объясни мне, в чем толк этой оптимизации C++, от которой код падает?

Никакой код не падает. Иди передай мне во внешний код, собранный растом до оптимизации.

Зачем ты пишешь эти глупые мазы? Твоему русту это не мешает только потому, что на нём ничего нет и он никому не нужен. Никакая бинарная совместимость ни с чем не нужно — причина проста — ничего нет.

Как ты можешь передать указатель на структуру во внешний C код, если у тебя внутри порядок изменился?

Ну передай мне структуру из раста во внешний код. Переведи из внешнего кода в раст. Переведи между старым растом и новым. Зачем ты придумываешь глупые оправдания?

По поводу твоих супер-раст оптимизаций. Мне лень гуглить, но ir умеет структуры и скорее всего раст их форвардит в ir, а ir — это llvm.org/doxygen/group__LLVMCCoreTypeStruct.html Т.е. судя по всему шланг так же форвардит упаковку на llvm.

И очень высока вероятность того, что великие оптимизаторы раста просто включили флажок в llvm и раструбили это среди адептов как «супер-оптимизацию». Это не ново.

Мне было интересно — побежит ли этот клоун обвинять меня, делая вид, что мы обсуждаем только один тезис.

И заметьте, я вам показал, кто есть реальный тролль, и чьё призвание мыть полы. Ведь я не стал использовать её обсёр с T && как основание для игнорирование и закидывания дерьмом.

А вы не отвлекайтесь, минусуйте/плюсуйте — ведь вам же не интересно то, кто говорит что-то сознанное, а кто просто трепится и пытается свой слив замаскировать под «ты тролль, я с тобою не играю».
Ты бы и рад соврать, да никак не получается, да? Обидно, небось)))

Обрадовался и решил всё остальное проигнорировать, впрочем, как и всегда.

godbolt.org/g/GxbPZa

Давай я чутка тебя расстрою. Ну ты это, давай, побольше скобочек.
Вы опять мимо.

Опять ответов нет, а трёп есть.

Quantum Render — это не про поддержку каких-то свойств в CSS.

Никто не говорил про поддержку, о поддержке говорилось в контексте демки и servo. Враньё номер раз.

Вам стоило бы немного немного разобраться в тех вещах, о которых вы пытаетесь говорить. На этом я завершаю разговор с вами, ибо уже очевидно, что продолжать его нет смысла.

И на основании вранья делаются какие-то выводы, а вернее делается слив.

Артефакты — это свойство именно композитора. Это первое. Второе — нерабочий ксс не обязательно, а вернее совсем не обязательно следует из нерабочего уровня растеризатора. Поэтому мы видим артефакты композитора, видим другие артфекты и мы как минимум не знаем — на каком уровне они взялись.

Что мы имеем в конечном итоге? Рассуждения о движках, которых нет. Спустя десять лет впилили ксс-парсер на расте. Никаких бенчмарков нет, никаких объективных данных нет. Ничего нет, а трёп о том, что «супер-быстрый» есть.

Далее мы пытаемся впиливать ещё один хелворд, который как-бы супер-быстр и работает, а самом деле он сливает хрому и не работает. Никаких объективных свидетельств за работает — нет, а за не работает — есть.

Ну и самое главное — произошел слив с основной темы, а именно интеграции какого-то раста в люсу и влияние его на её производительность. Никакой интеграции нет, кроме ксс-парсера. ксс-парсер — это капля в море. это 2% от браузера.

Никаких объектых свидетельств за то, что он быстрее старого( хотя из этого ничего не следует, ведь нет смысла сравнивать с аутсайдерами, когда надо сравнивать с хромом). Ничего нет.

В конечном итоге, мы облегчили интерфейс, впилили по треду на вкладку, добавили хелворд на расте и трубим везде о том, что «быстрее» он стал из-за раста. Хотя никто никакой связи не показал и не доказал.

Ну и как всегда, мы сравниваем раст и кресты, но при этом сравниваем ни хром и firefox, а firefox с firefox — т.е. калеку с новыми изваяниями. Почему-то хрому для того, чтобы уделывать firefox никакого раста не нужно. Почему мы сравниваем ни с хромом? А причина проста — вранья, манипуляции и маркетинг. Что он делает на техническом ресурсе? Непонятно.

Я отвечу на эти вопросы не тебе, но будущим читателям, потому что ты поленился пройти по ссылке и ознакомиться с предметом. Садись, два, плохой тролль, плохой!

Я не буду это комментировать — нужны публике клоуны — пусть будут клоуны.

Оптимизировали представление структур в памяти. Изначально в Rust, как и в C++ был прямой порядок полей, что значит, что каждое поле находилось в памяти в том порядке, в котором было объявлено.

Я могу уже сейчас тебя назвать клоуном, и в очередной раз показать публике то, какого уровня у раста адепты. Правда публике это не интересно.
Эту оптимизацию и встроили в коробку, т.е. в компилятор Rust. Он это делает за тебя. C++ так не может и не сможет, потому что считается, что каждая структура в C++ обязана маппиться на C. Это древнее наследие, которое никак не сломать.

godbolt.org/g/4cC91L

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

Он пишет какие-то тезисы о том, что «должны ммапиться на си», при этом что из этого следует и как из этого следует невозможность подобной потимизации — эксперт никогда не скажет.

Данная оптимизиция затронула структуры в каждой библиотеке, каждом крейте, каждой утилите. Это не капля в море, это океан оптимизаций!

Опять же, что мы тут видим? Наивную ретрансляцию того, что человек где-то прочитал, человек ещё не дошел до того, что такое выравнивание, почему упаковка структур, по большей части протухшая и не особо актуальная оптимизация, которую имеет смысл применять только в достаточно редких юзкейсах.

Звучит неубедительно, предоставь пруфы.

Иммутабельности по умолчанию уже достаточно, ну и основа хайпа mt-safety, а он базируется на иммутабельности.

Ты думаешь, что внутри unsafe происходит что-то ну совсем страшное. На самом деле, там пишут то, что пишут в обычном С++.

Никакого «обычного С++» не существует. Это не имеет смысла. В unsafe используются небезопасные конструкции, которые являются такими же небезопасными и в С++.

Весь код вокруг unsafe проверяет компилятор

Никакой компилятор ничего не проверяет — компилятор просто не даёт использовать то, что можно использовать в unsafe.

Тебя предупреждали. Программисты C++ любят повторять: «Писать безопасный код на С++ можно, для этого надо придерживаться определенных правил», ну так вот, этих правил и стоит придерживаться внутри unsafe. И всего лишь. Для желающих узнать больше.

Опять какой-то бред.

Никакого «безопасного» кода в С++ не существует. В С++ так же существуют безопасные и небезопасные конструкции и эти правила относятся к небезопасным.

Написание безопасного кода в С++ — это не правила написания unsafe кода — это правила написания safe кода, который ничем не отличается от раста.

Единственная разница между С++ и растом — это в том, что для написания указателя — в С++ тебе не нужно писать unsafe, а в расте нужно. Но из этого ровным счётом ничего не следует.

Единственный аргумент, который мне смогли предоставить — это «unsafe проще найти грепом», но никто в здравом уме код не грепает. Для этого существуют статические анилизаторы, для которых ты пишешь за пол часа правило и он тебе находит все использования указателей в коде.

Прости, был не прав.

Для меня это не новость.

C++ предпочитает мутабельное инстанцирование иммутабельному.

То, что «ты» написал — это не «мутабельное инстанцирование » — ты сам придумал эту ахинею. Оно УНИВЕРСАЛЬНОЕ. Читай по слогам до просветления.

Зачем ты в «иммутабельномое инстанцирование» передаёшь не иммутабельный объект? В этом твои проблема, что делаешь непонятно что и непонятно зачем. Если ты передашь иммутельный, то у тебя будет первая перегрузка.

Да, конечно.

Это не constexpr, а хрен пойми что. Никакого описания того, что оно может и зачем существует — нет.

Моё утверждение, что Rust может существовать без C или C++ непоколебимо.

Нет, то, что не соответствует реальности — является бредом.

А того, что у тебя, в мире хелвордов, может существовать какой-то раст без С/С++ — из этого ровным счётом ничего не следует, ведь это не общий случай.

В мире существуют, на самом деле их почти нет, «реальные» проекты на расте и ни один из них без С/С++ не существует. Начиная от компилятора раста, заканчивая его stdlib, сервой и прочим.

Но ты можешь им помочь и спасти их от С/С++, а то видишь как — они не могут, а ты можешь. Нужно срочно пойти и их научить.

В коде за авторством себя и прочих обычных программистов я лажу находил сильно чаще, чем в stdlib. В рамках данной дискуссии проблемами stdlib можно пренебречь и взять её корректность за аксиому.

Слив засчитан. stdlib — это не единственный пример — таких примеров тысячи. Начиная от серво и всех его зависимостей — кончая от биндингов к libc — без которой раст существовать не может, как и остальному сишному рантайму.

Большинство unsafe скрыто именно в сишном рантайме, который не переписан и никогда не будет переписан на раст. И даже не смотря на то, что основная часть айсберга невидна — наверх торчат тысячи и тысячи unsafe.

Ну и самое главное — что там вы находили — никого не интересует, ведь из этого ничего не следует. Это просто пустой трёп.

Потому что если вы прогрепали и не нашли unsafe, то он безопасный.

Каждый раз, когда мне кто-то говорит, что он не адепт — он адепт.

Вам действительно так сложно в логику, что вы неспособны понять того, чем отличается «раст по умолчанию безопасный» и «раст безопасный после того, как мы его погрепаем и не найдёт unsafe», хотя их мы найдём.

С вами дискутировать не имеет смысла, вы за 10строк 10 раз родите взаимоисключающие параграфы. Вы сами же опровергли свой тезис о том, что «раст по умолчанию безопасный», но продолжаете делать вид, что это не так.

Любой код с * и &? Прям все ссылки и указатели запретить? Успех!

Опять же, либо полная неспособность понять то, что вам пишут, либо неадекват. В расте нет указателей и это никого не заботит, а тут вдруг уже подавай указатели. & — это не ссылка, есличто.

Ну и самое главное, я ведь не зря сказал про clang-tidy, но что-то вы это проигнорировали? Почему?

new? Ну буду писать вместо этого std::make_unique().release(). Такой код от некоторых карго-культуристов я видел в проде.
Для справки — результатом release() будет указатель, от которых мы выше отказались. Вы действительно не понимаете всей бессмысленности того, что пишите?

Не валялись по каким критериям?

По производительности и возможностей к написанию лоулевел кода.

Возьму Idris/Coq/ATS и докажу как теорему.

Нет. Я уже вам тысячи раз говорил о том, что недостаточно написать рандомную фразу и выдать её за аргумент, либо тезис. Возьми и напиши. Пока этого никто ещё не сделал, но я знаю — ты сможешь. Удачи. Не забудь потом законтрибутить в раст, а то бедный раст так и не осилил родить свой аллокатор — приходиться использовать подлый, небезопасный аллокатор на крестах.

Кресты без ссылок и указателей

Никто вам о ссылка не говорил. & — это не ссылка, а взятие адреса, а * — это разименование и тип переменной. Я не запрещал умножение и and.

это немножко разные вещи

Это одно и то же.

по выразительности и интероперабельности

Это вы только что придумали и это ни из чего не следует.

с внешними библиотеками.

Любая программа на расте, кроме хелвордов,, да и сам раст — это биндинги к С/С++. Что-то они пишут биндинги — напишите и вы. Никаких проблем нет.

А захотите написать что-то новое — напишите без указателей, ведь на расте же пишут.

В любом случае, все эти разговоры не имеют смыслы, ведь вы уже слились. Вы либо этого не замечаете, либо делаете это намеренно.

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

И почему-то вы не задаётесь вопросом — какой смысл существования раста? Если нужно было бы добавить греп в С++ — можно было бы за месяц написать идеальный clang-tidy плагин, который бы находил всё это влёт.

И так со всем, куда бы вы не пошли, если вы начнёте анализировать то, что вы говорите, то, что вам предлагают — вы поймёте, что все тезисы, которые вы повторяете — ничего не стоят. За ними ничего нет. Всё это трёп.

И тут основной вопрос заключается в том — чего вы хотите. Понять, либо убедить себя в том, что всё так, как вам рассказали. Объективная реальность — это сложно. Все уверены, что они не повторяют пустые тезисы, но именно это они и делают.

Похоже, что вы всё же не читали что там написано. А там чётко сказано:

Нет, нет. Это так не работает. Недостаточно что-то кинуть и сказать, что «я прав» — надо вывести это «прав» из ссылки. Вы утверждали то, что там что-то есть, кидая ссылки. В которых ничего про «есть» не сказано, а то, что описывается — никакого отношения к firefox не имеет.

Это я ещё вас пожалел и уж не стал играть ту карту, что вы слились на то, что есть только Quantum CSS, хотя вы пастили Quantum Render. Из этого уже следует то, что вы пастите всё подряд.

Более того, в описании новшеств Firefox 57 также чётко упоминается, что Quantum CSS уже в Firefox:

Из этого булшита равным счётом ничего не следует — это рекламная агитка, такая же, как и эта hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank, перевод который я уже смешивал с дерьмом тут. Как оказалось — эта агитка состоит из вранья, манипуляций, ахинеи невероятных масштабов и просто не работает.

По второй ссылке, где описывается следующий компонент, почти готовый к внедрению (Quantum Render), чётко сказано, что оно ещё не в релизе, но войдёт в него в скором времени:

Зачем вы несёте эту ахинею? Никакого Quantum Render в природе не существует, существует нерабочая поделка, которая умеет рендерить 2-3 ксс свойства.

Quantum CSS — это парсер примитивного ксс, объективных свидетельств за то, что он где-то там быстрее — в природе не существует. Всё. Таких «Quantum CSS», разной степени паршивости, написано десятки, если не сотни.

Не вижу причин не верить Mozilla и здесь.

В этом основная проблема. Ничего нет, рекламная агитка есть, и никаких причине «не верить» ей нет. Подход не тянет на уникальность.

Как же он тогда работает? Quantum CSS не занимается рендерингом вообще.

Естественно, и я об этом вам уже сообщил. Только вот вы пастили не только Quantum CSS, а и рендер, но почему-то слились на парсер.

Он занимается разбором CSS и быстрыми ответами на вопрос какие из правил применимы к каждому из тысяч элементов на каждой странице.

Зачем вы как попугай повторяете то, что увидели в агитке? Я это могу прочитать из без вас. Никаких критериев «быстро» не определено, объективной информации нет — это всё пустой трёп.

Отдавать computed style может любой хелворд, хотя это и есть хелворд.

Если демка Servo (которая действительно очень сыра) не может отрендерить какое-то правило правильно — это не вина этого компонента.

Опять какое-то враньё. Это не демка servo — это Quantum Render, который «уже готов к внедрению».

И опять же, враньё. Вы всё перепутали — демка не не может отрендерить какую-то часть правил — она не может отрендерить НИЧЕГО. А даже те пару правил, которые работают, которые и показали в демки — на самом деле не работают, они рисуются с артефактами и дерьмо анлиалиасингом. А видео, на котором запечатлена работа демки — каким-то странным образом дерьмово пожато, что никаких артефактов и качество отрисовки — на нём не видно. Вот ведь какое совпадение, да?

Ну и да, она побеждает хром только во влажных мечтах. В конечном итоге — что мы имеем? Враньё про то, что побеждает хром. Враньё про то, что она что-то там умеет. Враньё про то, что она где-то там быстрее. Враньё про то, что она где-то там( в параллельной вселенной, наверное) готова ко внедрению.

Но вы продолжайте, нет причин не верить мозилле. Блаженны верующие — верьте дальше, ведь объективная реальность — это не для вас.

Information

Rating
Does not participate
Registered
Activity