форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
Сообщение от opennews (ok) on 20-Дек-13, 14:21
Разработчики Mozilla сообщили (https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat.../) о реализации в JavaScript-движке SpiderMonkey новой оптимизации операций с плавающей запятой (float32), которая позволила достигнуть нового уровня производительности web-приложений, использующих подмножество Asm.js (http://www.opennet.me/opennews/art.shtml?num=36468). Тестирование производительности показало, что выполняемое в новой сборке Firefox JavaScript-приложение выполняется примерно в 1.5 раза медленнее, чем скомпилированная в машинный код реализация того же алгоритма на языке Си. До внесения оптимизации наблюдалось расхождение производительности в два раза. <center><a href="https://hacks.mozilla.org/wp-content/uploads/2013/12/asm1.5b... src="http://www.opennet.me/opennews/pics_base/0_1387531611.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center> Ускорение наблюдается и при выполнении обычного JavaScript-кода, но наибольший эффект достигается за счёт применения нового типа float32 в Asm.js (http://asmjs.org/), низкоуровневом подмножестве языка JavaScript со строгой типизацией, которое полностью совместимо с обычным JavaScript и может выполняться в любых браузерах. Если браузер не поддерживает Asm.js, то код выполняется как обычный JavaScript, а если поддерживает - включается дополнительный оптимизирующий модуль, учитывающий добавленные в код аннотации. Наличие информации о типах позволяет использовать не только JIT, но и предварительную AOT-компиляцию, выполняемую для всего кода до начала его выполнения и генерирующую более простой и эффективный машинный код. При этом, в отличие от JIT-компиляции, Asm.js обеспечивает предсказуемую производительность и не зависит от сборщика мусора. В настоящее время Asm.js позиционируется в качестве "ассемблера для Web" и используется в web-приложениях, автоматически преобразованных в JavaScript с языков C/C++ при помощи таких инструментов, как Emscripten (http://www.opennet.me/opennews/art.shtml?num=35313) и  Mandreel (http://mandreel.com/). Для более эффективного использования новых  оптимизаций в компилятор Emscripten уже добавлена логика, направленная на более активное использование типа float32 вместо менее эффективного типа float64. При этом оптимизации пока не включены по умолчанию в Emscripten, так как ещё не решены некоторые сопутствующие проблемы, такие как увеличение размера итоговой программы и замедление в некоторых специфичных ситуациях. Примечательно, что по тестам разработчиков JavaScriot-код, непосредственно манипулирующий 32-разрядными вычислениями с плавающей точкой, за счёт предкомпиляции выполняется с использованием движка SpiderMonkey иногда даже быстрее, чем те же вычисления в программе, полученной в результате компиляции в GCC или Clnag. Общий уровень производительности Asm.js приближается к значениям, не сильно расходящимся с показателями на которое разные нативные компиляторы отличаются между собой. URL: https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat.../ Новость: http://www.opennet.me/opennews/art.shtml?num=38700
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

4. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+8 +/–
Сообщение от meequz (ok) on 20-Дек-13, 14:33
Сначала изобрели интерпретируемые языки, потом написали для них компиляторы, круто.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Xasd (ok) on 20-Дек-13, 15:59
	> Сначала изобрели интерпретируемые языки, потом написали для них компиляторы, круто. компиляторы не для интерпретируемых языков же :) ... Emscripten -- это компилятор для компилируемого языка C/C++ в некоторое представление (Asm.Js) которое тоже не является интерпретированным языком.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	70. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 20-Дек-13, 18:30
	>(Asm.Js) которое тоже не является интерпретированным языком. а чем оно является?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	92. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от Аноним (??) on 20-Дек-13, 21:13
	>>(Asm.Js) которое тоже не является интерпретированным языком. > а чем оно является? Метакодом.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	99. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–5 +/–
	Сообщение от Аноним (??) on 20-Дек-13, 21:17
	> Метакодом. В воздухе повеяло метафизикой, торсионщиной и памятью воды...
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	71. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 20-Дек-13, 18:35
	> в некоторое представление (Asm.Js) которое тоже не является интерпретированным языком. Наоборот. Компилятор преобразует компилируемый язык в ту или иную форму объектного кода, который является вполне себе интерпретируемым. Правда, интерпретатор у него, как правило, аппаратный (если не считать эмуляторов).
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	141. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 21-Дек-13, 19:29
	>> в некоторое представление (Asm.Js) которое тоже не является интерпретированным языком. > Наоборот. Компилятор преобразует компилируемый язык в ту или иную форму объектного кода, > который является вполне себе интерпретируемым. Правда, интерпретатор у него, как правило, > аппаратный (если не считать эмуляторов). ну эт да. можно и так выразиться :)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	118. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 12:56
	Ну так сначала создали себе проблемы, потом стали их героически решать. Продолжатели дела Дона Кихота мечтают о славе ничуть не меньше предшественника. P.S. они подозрительно зассали взять за единицу GCC, взяв вместо него за 1 тормозной и недопиленный шланг...
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	148. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 22-Дек-13, 19:59
	Какая разница, как нормировать?
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	150. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Аноним (??) on 23-Дек-13, 11:31
	> Какая разница, как нормировать? Ну как какая? Слабых бить проще. Поэтому с нормальным компилером си они зарубиться зассали, ибо при нормировании относительно GCC результат будет выглядеть довольно хило. А так взяли шланг недопиленый - "во, смотрите, не так уж и сильно отстает". Маркетинговый булшит - он такой.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

5. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+11 +/–
Сообщение от pv47 (ok) on 20-Дек-13, 14:34
Осталось ещё сократить разрыв в потреблении памяти.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	119. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+2 +/–
	Сообщение от Аноним (??) on 21-Дек-13, 12:58
	> Осталось ещё сократить разрыв в потреблении памяти. И перестать мухлевать! А то даже немолодой GCC 4.6 заметно обидел в бенчах шланг принятый за единицу. Кого эти жабаскриптеры ходят надуть?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
Сообщение от FSA (??) on 20-Дек-13, 14:41
> JavaScript-приложение выполняется примерно в 1.5 раза медленнее, чем скомпилированная в машинный код реализация того же алгоритма на языке Си Может всё-таки при написании алгоритма логичнее использовать особенности определённого языка?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	82. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+4 +/–
	Сообщение от Lain_13 (ok) on 20-Дек-13, 20:33
	Тут имеется в виду то, что берут один и тот же сорс, компилируют его в бинарник и в asm.js, а потом сравнивают время работы бинарника и полученного «скрипта».
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–4 +/–
Сообщение от Аноним (??) on 20-Дек-13, 14:45
ассемблер в жабаскрипте ? это революционно
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+6 +/–
	Сообщение от Аноним (??) on 20-Дек-13, 14:54
	нет, это баян.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

18. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
Сообщение от Аноним (??) on 20-Дек-13, 15:24
Это с учётом первого прогона asm.js?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+4 +/–
Сообщение от Xasd (ok) on 20-Дек-13, 15:33
то что AsmJs будут улучшать (в плане производительности) -- этого следовало ожидать. Nacl\PNacl становится всё менее и менее перспективным. гемороя куча при разработке web-программ, а производительность такая же как в AsmJs (кроме времени старта.. Nacl\PNacl быстрее стартует чем AsmJs). к тому же нет обратной совместимости с браузерами которые не умеют Nacl\PNacl. ну или Google может насильно заставить всех сесть за Nacl\PNacl , в случае если ему получится создать 90`процентную монополию с браузером Google Chrome. от этого конечно ни куда не деться :) ..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	57. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+2 +/–
	Сообщение от Аноним (??) on 20-Дек-13, 17:15
	> ну или Google может насильно заставить всех сесть за Nacl\PNacl , в > случае если ему получится создать 90`процентную монополию с браузером Google Chrome. > от этого конечно ни куда не деться :) .. Не сможет. Они удовлетворились 30% долей и начали затягивать гайки. Дальше он пойдёт по пути windows 8 - "мы решили что вам будет удобнее так", соответственно и большей доли ему не видать.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	134. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–2 +/–
	Сообщение от Аноним (??) on 21-Дек-13, 16:38
	> пойдёт по пути windows 8 - "мы решили что вам будет удобнее так", А мозильщики с их австралопитекисом по какому пути пойдут?
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	155. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 24-Дек-13, 19:49
	>А мозильщики с их австралопитекисом по какому пути пойдут? свободы и любви
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	74. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 19:25
	Не знаю, как в NaCl, но с asm.js память вообще никак не освобождается до завершения всего поцесса. Как по мне - для приложений это полная дикость. И я, хоть убей, не могу понять, чему ты радуешься - тому, что успешно сделан безумный костыль?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	78. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 20-Дек-13, 19:59
	> память вообще никак не освобождается до завершения всего поцесса. Как по мне - для приложений это полная дикость. ды во многих (C/C++) программах так сделан прикладной манагер памяти:). ни чего особо плохого. это не утечка памяти, а просто способ избежать насилия над системным манагером памяти. всем нравится, ни кто не жалуется :-).. сделай swap-раздал побольше гибибайт, купи SSD посовременее. ну и конечно ни в коем случае НЕ используй 32-битные операционные системы у себя на компьютере (они неэффективно управляют виртуальной памятью). ну ты понел :-)..
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	80. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Vkni (ok) on 20-Дек-13, 20:27
	> НЕ используй 32-битные операционные системы Операционная система Firefox под гипервизором Windows есть только в 32-х разрядной версии. :-)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	83. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+2 +/–
	Сообщение от Lain_13 (ok) on 20-Дек-13, 20:36
	Тебе же внятно сказали 32-разрядными не пользоваться. Смени гипервизор. -_-
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	84. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 20:36
	Угу, понял. Называется "плевать на эффективность и деньги на ветер". Мне этот подход несколько чужд. А приличный софт на плюсах использует преимущества плюсов - в том числе возможность сочетать разные схемы выделения памяти. Где статика или преаллокация, где пулы разной степени навороченности, где арены... Тем более, что всё это давно написано и отлажено.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	101. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 20-Дек-13, 21:20
	> А приличный софт на плюсах использует преимущества плюсов - в том числе > возможность сочетать разные схемы выделения памяти. Где статика или преаллокация, где > пулы разной степени навороченности, где арены... Тем более, что всё это > давно написано и отлажено. Вне браузера - да. А после запихивания в браузер - еще отлаживать и отлаживать. Особенно в плане безопасности.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	107. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 23:29
	Ну вот в NaCl нет никаких проблем применять всё это отлаженное прямо сейчас.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	113. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 00:10
	> Ну вот в $SOMETHING нет никаких проблем Замечательный аргумент.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	128. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 14:46
	>> Ну вот в $SOMETHING нет никаких проблем > Замечательный аргумент. В Windows нет никаких проблем. В Linux нет никаких проблем. В OSS нет никаких проблем. И т.д. Единственное, что непонятно - почему народ корчится над дальнейшей разработкой всего этого.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	135. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 16:40
	> сделай swap-раздал побольше гибибайт, купи SSD посовременее. ...протри его свапом и замени. Докупи еще памяти. Докупи проц помощнее. И все это чтобы запустить очередную тормозную к@к@шку от скрипткидей, которым приспичило чесать левое ухо правой пяткой.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	120. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 13:00
	> Не знаю, как в NaCl, Там все обычно более-менее обычно. Хотя pnacl смотрится наиболее логично для веба: в вебе же разные девайсы бывают. И x86, и x86-64, и ARM, а потенциально и еще чего-нибудь. Веб не должен зависеть от 1 архитектуры проца, это платформо-нейтральная среда...
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	133. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 16:37
	> Nacl\PNacl становится всё менее и менее перспективным. Я и вижу - знакомые игроделы на него гамезу портанули. А на asm.js они клали с прибором, ибо это уже форменное web'анатство...
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

26. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
Сообщение от Аноним (??) on 20-Дек-13, 15:33
Хм, отличное сравнение clang и gcc.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	59. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 20-Дек-13, 17:18
	Причём старых версий, почему-то. Хотя по моим тестам gcc с новыми версиями почему-то только замедляется.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	72. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Аноним (??) on 20-Дек-13, 18:36
	> Причём старых версий, почему-то. Ну так на фоне более новых компиляторов, сабжевые достижения смотрятся не так внушительно :) > Хотя по моим тестам gcc с новыми версиями почему-то только замедляется. Сам gcc может замедляться хоть на 20%, главное, чтобы собранные им программы быстрее работали.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	121. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-13, 13:01
	> почему-то только замедляется. Расскажи это LTO-оптимизациям, например, которые только в новых компилерах появились.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

49. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
Сообщение от Аноним (??) on 20-Дек-13, 16:39
Теперь на JS можно написать Кризис и Ассасина?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
Сообщение от Аноним (??) on 20-Дек-13, 17:00
Не проще сразу Си компилятор с песочницей в браузеры встроить?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 20-Дек-13, 17:18
	> Не проще сразу Си компилятор с песочницей в браузеры встроить? Нет.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	75. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 19:27
	Проще встроить песочницу (NaCl) - но мозилловцы легкие пути вообще не любят и невесть зачем всё пытаются писать сами - от просмотрщика PDF до этого извращенного костыля asm.js. Что за манера - игнорировать систему, в которой работаешь, и не пытаться с ней интегрироваться как можно теснее - я не понимаю.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	79. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 20-Дек-13, 20:26
	> Что за манера - игнорировать систему, > в которой работаешь, и не пытаться с ней интегрироваться как можно > теснее - я не понимаю. (фраза как я понимаю в сторону PDF.js и Shumway).. всё это началось после того как web-браузером стали пытаться пользоваться по-не-назначению. вот раньше был web , и были web-странички... ...но потом какие-то дураки решили запускать внутри web-браузера -- анимированные ролики через плугины (SWF), и чуть-позже просматривать PDF-файлы. на мой скромный взгляд -- реализация PDF.js\Shumway -- это всего лишь попытка Мозилки вернуть назад всё как было -- к ситуации "используйте web-браузер для web, а не для всего-подрят" :)
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	86. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Lain_13 (ok) on 20-Дек-13, 20:41
	А ещё их достал тот факт, что через эти славные плагины постоянно пролезает всякая дрянь в систему. Вот и решили устроить им экстерминатус. Гугл, кстати, в Хроме тоже свой просмотр PDF сделал. Разве что они таки бинарный сделали, а не на JS, и потому работает он существенно шустрее.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	87. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 20:43
	Насчет того, что браузером надо пользоваться для просмотра веб-страниц (т.е. документов), а не запуска приложений - я двумя руками за. Но вот при чем тут PDF,js и Shumway - не пойму. Наоборот - это одни из самых монструозных "браузерных приложений" получаются. В этом плане идея с плагинами, а лучше - с механизмами вроде XEmbed смотрится куда как логичнее.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	103. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 20-Дек-13, 22:10
	> Наоборот - это одни из самых монструозных "браузерных приложений" получаются. монструозность появляется только в том случае, если ты зашёл на web-сайт, который использует SWF-контент или/и PDF-контент. :) (именно "контент", а не кнопка "скачать этот файл на жёсткий диск"). а в случае если в web-браузере отображаются web-сайты, которые НЕ имеют ни SWF-контента ни PDF-контента -- в этом случае технологии Shumway и PDF.js избавляют web-браузер от монструозности. другими словами: технологии Shumway и PDF.js -- перекладывают всю монструозность и ответственность с плеч web-браузеров на плечи web-мастеров: "web-сайт тормозит? значит пусть web-мастер удалит оттуда PDF\SWF-контент! например заменит этот контент на HTML5-контент, или просто заменит на обычные скачиваемые файлы" (всё просто: если web-мастер создал тормозной web-сайт, значит web-мастер и должен заниматься устранением этих тормозов.. web-браузер должен только показывать контент, а не подвергать пользователя опасностям) ************************************************************ а web-браузер который содержит нативные PDF\SWF-плагины -- монструозен всегда, по умолчанию. даже когда в таком web-браузере просматриваются web-сайты без PDF\SWF-контента. и всегда есть опасность взлома (в худшем случае) или просто краха (в лучшем случае) -- по причине этой монструозности. нативный PDF-Plugin (не важно какой) и нативный Adobe-Flash-Player -- накладывают всю ответственность и монструозность -- на плечи web-браузеров (а не плечи web-мастеров): "web-сайт тормозит? обновите версию плагинов для web-браузера!", "вас взломали?! надо было вовремя обновлять версии плагнов для web-браузера!"
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	109. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 23:39
	К твоему сведению - если на сайте нет соответствующего контента то процесс с плагином даже не загрузится. И, соответственно, никакую тяжеловесность не создаст. Что до разрабочиков браузера и их ответственности - в том-то и дело, что это не их ответственность, а тех, кто поддерживает систему в целом, и надо по максимуму пользоваться сервисами этой системы. Иначе осталось запускать свой гипервизор и полностью всё делать самим, игнорируя то, что предоставлено операционной системой. Дело тут, разумеется, в другом - мозилловцы зачем-то пилят свою систему, и пытаются отдельные компоненты и решения для неё обкатывать на пользователях.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	115. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от angra (ok) on 21-Дек-13, 02:19
	> К твоему сведению - если на сайте нет соответствующего контента то процесс > с плагином даже не загрузится. И, соответственно, никакую тяжеловесность не создаст. А вот если хоть один сайт с таким контентом открыть, а потом закрыть, то процесс с плагином останется висеть.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	127. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 21-Дек-13, 13:28
	Не замечал, обычно процесс убивается в пределах минуты. Но если остаётся - вперёд в багтрекер. Никакой необходимости его держать запущенным нет.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	117. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Bx (ok) on 21-Дек-13, 12:26
	> К твоему сведению - если на сайте нет соответствующего контента то процесс > с плагином даже не загрузится. И, соответственно, никакую тяжеловесность не создаст. Зато js загрузится, если захочет мастер(и позволит клиент, а у него нет выбора). И да, много где перекладывается процесс рассчетов на www-клиент. SWF и др. идут на йух. > Что до разрабочиков браузера и их ответственности - в том-то и > дело, что это не их ответственность, а тех, кто поддерживает систему > в целом, и надо по максимуму пользоваться сервисами этой системы. Иначе > осталось запускать свой гипервизор и полностью всё делать самим, игнорируя то, > что предоставлено операционной системой. Ну, как бы, www-клиент и является "гипервизором" задачи, которую юзер "хочет" исполнять. > Дело тут, разумеется, в другом - мозилловцы зачем-то пилят свою систему, и > пытаются отдельные компоненты и решения для неё обкатывать на пользователях. Ну да и флаг им в руки :) Когда было необходимо исполнение одной КОНКРЕТНОЙ задачи - я за 5 минут накидал форм в QtCreator + напильненгинг на 10-30 минут:) Только никто не хочет пользоваться - всем дай браузер с адресной строкой :)))
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	122. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 13:16
	> (фраза как я понимаю в сторону PDF.js и Shumway).. Как любитель читать даташиты могу сказать что меня совершенно не прет, когда даташит парсится в 5 раз дольше чем качается, разгоняя до предела вентиль на могучем FX-8120 на пару минут. Заметьте, нативная вьюшка открывает этот PDFник мгновенно, я не успеваю увидеть как оно рендерится, проц не клинит в полку на 2 минуты, etc. Поэтому я не понимаю зачем мозильщики встроили кусок столь бесполезного балласта. Shumway - это вообще костыль для костыля. Пусть они еще двигло браузера на JS перепишут, правда тогда они хрому в бенчах сдриснут раз в 10. Зато у хрома станет >50% юзерей. Ибо нефиг страдать ерундой. > Мозилки вернуть назад всё как было -- к ситуации "используйте web-браузер > для web, а не для всего-подрят" :) А на мой взгляд это JS головного мозга и попытка удалить гланды через попу автогеном. Мне это ничего кроме головняка с переназначением вьюшки на нечто более нормальное не дало, например. Пользоваться мозильской вьюшкой невозможно даже при довольно мощном процессоре. Я даже представить себе боюсь сколько будет рендериться большой даташит на нотике, где проц послабее.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	132. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 21-Дек-13, 16:32
	> Заметьте, нативная вьюшка открывает этот PDFник мгновенно, я не успеваю увидеть как оно рендерится заметьте что ActiveX-элементы тоже исполняются мгновенно. и без шума вентилятора, и без парсинга JS. но это не значит что браузер должен полмолчанию исполнять все ActiveX элементы. браузер нужен для просмотра WEB. а не для того чтобы БЕЗ СПРОСА ПОЛЬЗОВАТЕЛЯ (сами по себе) открывались бы нативные программы (например внутри однопиксельного iframe, внутри рекламного банера). "ActiveX" в данном случае это хорошая аналогия для "PDF". (посмотрите на себя со стороны: "как любитель использования множества WEB-Видео-Наблюдений могу сказать что меня совершенно не прет, когда я захожу в очередную WEB-админку для WEB-Видео-Наблюдения, а там ActiveX-элемент не запускается, и Видео-Наблюдение не показывается. я хочу чтобы у всех пользователей всегда запускались бы все ActiveX-элементы, чтобы они в любой момент без гемороя смогли бы использовать WEB-Видео-Наблюдение!", ну бред же!:), вот и вы со своими даташитами -- так же) если вам нравится читать PDF через нативную программу -- то пожалуйста -- читайте PDF через нативную программу. а вот задача Firefox (одна из многих) в частности том, чтобы до тех пор пока у вас НЕ ПОЯВИЛОСЬ БЫ ЖЕЛАНИЯ открывать какие-либо нативные программы -- то нативные программы сами по себе и не открылись бы -- до тех пор пока вы не велели бы ЯВНЫМ ОБРАЗОМ открыть нативную программу, снимая всю ответвтенность с Firefox. ************************************************************ вот если вам нравится читать даташиты, выискивая их через WEB -- то ОЧЕВИДНО что вы (именно вы) ХОТЕЛИ БЫ чтобы Firefox делал бы так: "если открывается PDF-даташит, то Firefox должен открывать его сразу через нативный просмоторщик.. а если открывается PDF-вирусный или какой-то другой PDF-документ, то тогда Firefox должен открывать его через PDF.js, или вообще ни как не открывать" но простите, у Firefox нет искусственного интеллекта, который смог бы автоматически распознать что же это там за PDF-документ: вирусный-PDF, или же даташит, или какой-то другой. (а если и был бы этот искусственный интеллект -- то не уверен что на него можно было бы с полной гарантией положиться. и кстате, сколько бы это жрало процессорной мощности?).
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	136. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от Аноним (??) on 21-Дек-13, 17:20
	> заметьте что ActiveX-элементы тоже исполняются мгновенно. и без шума вентилятора, и без > парсинга JS. Но есть у них и баги. 1) Хромая безопасноть. Это выполняемый код, который вообще никак не ограничен. 2) Для полных лулзов он мог инсталиться автоматически. 3) В ряде случаев даже без проверки подписи, что очень доставляло хаксорам. 4) Оно непортабельное. Т.е. например на ARM оно работать не сможет ну хоть там что, потому что х86 код и только под винду. А вот это FAIL. Веб штука кроссплатформенная. > но это не значит что браузер должен полмолчанию исполнять все ActiveX элементы. А вот тут возможны варианты, спору нет. С другой стороны, я не считаю что хочу увидеть майнер *-коинов на JS вкалывающий у меня по умолчанию, равно как мне не улыбается услышать адский ор в динамики в 3 часа ночи. Поэтому у меня noscrtipt есть и для обычного JS, если уж на то пошло. > браузер нужен для просмотра WEB. а не для того чтобы БЕЗ > СПРОСА ПОЛЬЗОВАТЕЛЯ (сами по себе) открывались бы нативные программы Ну разумеется, запуск нативных программ без спроса и песочницы - это поимение пользователя. С другой стороны PNaCl - не совсем нативная программа. А таки некий промежуточный биткод который потом будет оттранслирован в нативный. Чем использование промежуточного биткода как intermediate representation хуже чем использование JS как IR - мне вообще не очевидно. Вот JS как IR - конкретный изврат,удаление гланд через попу автогеном. А какие именно правила будут применены при трансляции и что там кому будет можно - вообще на совести транслятора и (потом) песочницы. Вон, codepad.org например не очкует произвольные программы на си запускать, прикинь? А покажи его поимение, ради лулзов? :) > "ActiveX" в данном случае это хорошая аналогия для "PDF". Хорошая аналогия - достаточно жирным пдфником можно юзеру на полчаса браузер колом поставить, или out of memory спровоцировать. > очередную админку для WEB-Видео-Наблюдения, а там ActiveX-элемент не отображается, и > Видео-Наблюдение не показывается") А вот тут - нативный кодек должен быть встроен в браузер. И таки да, на сях и оптимизнутом асме. Потому что JS зашьется по производительности и HD явно не потянет, а картинка 128х128 пикселей "зато на JS" - мало кому понравится. А камера должна просто гнать браузеру данные, по какому-нить стандартному протоколу. Это достаточно популярная фича для того чтобы ее сделать core-функциональностью а не какими-то довесками. > если вам нравится читать PDF через нативную программу -- то пожалуйста -- > читайте PDF через нативную программу. Мне не нравится ждать компьютер по 5 минут только для того чтобы в первые же 10 секунд чтения PDFника узнать что мне он вообще нафиг не упал, т.к. у комплектухи которая в нем описана какой-то из ключевых параметров за границами того что мне надо. КПД операции галимый получается. Пример контрпродуктивного подхода, когда страдание фигней ("зато на JS, мимими") получает приоритет над результатом (тормозная непотрeбщина которой пользоваться невозможно). > ОБРАЗОМ открыть нативную программу, снимая всю ответвтенность с Firefox. См. выше. > "если открывается PDF-даташит, то Firefox должен открывать его сразу его через нативный > просмоторщик.. Лис показывает подтверждение на скачку файла. И 1 раз клацнуть оное мне сильно проще и быстрее чем 2 минуты фтыкать на потуги рендеринга при довольно кривом результате, да еще наблюдая как каждая страница прорисовывается по несколько секунд. > а если открывается PDF-вирусный или какой-то другой PDF-документ, PDF формат сам по себе вообще не является исполняемым файлом. И как-то за добрых 20+ лет пользования компьютерами меня ни разу не раздолбали PDFниками, хотя я их много раз открывал. Хотя если использовать акроридер - там конечно, как обычно в продукции адобы, легион дыр при тормозной починке. Если на то пошло, PNG тоже файл данных, давайте и его JSом парсить. Нехай тормозит еще сильнее. И, кстати, в парсинге HTML и JS тоже баги могут быть, это тоже надо на JS переписать. К тому же это сложнее PDF в разы. Правда скорость работы браузера вообще упадет в район плинтуса, "зато никаких нативных программ, яваскриптик, мимими". > то тогда Firefox должен открывать его через PDF.js, или вообще ни как не открывать" Улови мысль, вебанашка: програма прежде всего должна выполнять свои функции и не компостировать пользователю мозг. Все остальное - приоритет номер два. Потому что без выполнения этого условия программа вообще нафиг не уперлась и отправится на свалку. Как бесполезный или даже вредный и назойливый крап. Все остальные свойства программы при таком раскладе вообще не роялят. > но простите, у Firefox нет искусственного интеллекта, который смог бы автоматически > распознать что же это там за PDF-документ: вирусный-PDF, или же даташит, PDF сам по себе - формат данных. Если мозильщики не могут написать парсинг PDF на сях - то я вообще не понимаю как они в ...цать раз более сложный HTML и JS тогда из сей парсят и что там насчет багов. Наверное, ты должен прекратить запускать нативную программу - браузер. Вдруг там попадется вирусный HTML или JS? Или чем парсинг HTML и JS принципиально отличается от парсинга PDF? > или какой-то другой. (а если и был бы этот искусственный интеллект > -- то не уверен что на него можно было бы с > полной гарантией положиться). Короче, отборнейшая бредятина укуренного вебанашки, который уже не знает чем оправдать свои бзики по JS.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	138. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 21-Дек-13, 18:18
	> PDF сам по себе - формат данных. 1. сложный формат. (провоцирует на создание ошибки). 2. не WEB-ориентированный. (т.е. ему не место в WEB.. либо совсем, либо его место должно быть там очень маленькое). PDF предназначен для печати на принтере, в основном. (кстате уже кто-то жаловался что PDF.js печатает PDF-документы очень плохо. в низком разрешении, или ещё какие-то недочёты). > Если мозильщики не могут написать парсинг PDF на сях - то я вообще не понимаю как они в ...цать раз более сложный HTML и JS тогда из сей парсят и что там насчет багов. с чего ты взял что в парсинге HTML и JS  (и воспроизведении) -- не было багов? :-) баги отлавливаются постоянно, затыкаются, затем опять отлавливаются новые.. и это продолжтается уже много лет. в при выходе каждой новой версии Firefox -- оказывается что прошлая версия Firefox содержала баги. в том числе баги, связанные с безопасностью. если к этим багам мы вдруг захотим ещё и прибавить баги от парсинга PDF и баги парсинга SWF -- то не сложная математика (ну или скорее вангология:)) подскажет нам что багов будет просто В НЕСКОЛЬКО РАЗ больше чем сейчас. PSF.js и Shumway позволяют ХОТЯБЫ не умножать уже существующее количество багов. то самое количество которое уже присутствуют в модулях обработки HTML+CSS+JS. а присутствие нативных плагинов (в отличии от PSF.js\Shumway) -- как раз умножают это существующее количество багов. и как показывает практика -- различные виды песочниц спасают от этого не доконца, так как код нативный. как я уже писал выше -- нативный плагин запускатеся не по твоему желанию пользователя, а по желаюнию WEB-страницы (запуск нативного плагина может произойти от однопиксельного элемента внутри рекламного iframe-банера, и это будет явно не datasheet). > я не считаю что хочу увидеть майнер *-коинов на JS вкалывающий у меня по умолчанию биткоины уже на компьютерах майнить не эффективно, даже через нативный код. а тут всё ещё байки про JS-майнеры :-) .. пишешь так будто ты защёл на страницу, и у тебя с пластиковой карточки (из кормана) снялись деньги (через супер-мудрёную технологию Bitcoin!). смешно же, право! :) ну закрой WEB-странцу, ды и всё, делов-то, если тебе на ней что-то не понравилось. > равно как мне не улыбается услышать адский ор в динамики в 3 часа ночи. вот это уже более справедливое замечание. но совет тот же -- ну закрой странцу, ды и всё, делов-то.. :-) хорошо бы конечно, если бы можно было бы в Firefox отключать звук. но это кстате касается не только JS, но и HTML <video>\<audio> тегов. > Поэтому у меня noscrtipt есть и для обычного JS, если уж на то пошло. ха-ха :-) .. позабавил ты меня! безопасный JS ты запретил (потому что вдруг Bitcoin у тебя деньги с карточки сворует!), зато опасные нативные плагины разрешил (пусть опасный контент открывается быстро, главное чтобы Биткоин деньги не воровал бы через JS!).. > Улови мысль, вебанашка: програма прежде всего должна выполнять свои функции и не компостировать пользователю мозг. Все остальное - приоритет номер два. вот именно! WEB-браузер не предназначен для чтения тучи даташитов. а ты пытаешься его так использовать (ды ещё и JS отключил). чтение PDF-даташитов -- это БОНУСНАЯ функция WEB-браузера (а не основная). и именно в бонусном виде PDF.js выполняет это отлично. :) позвони производителю твоих любимых чипов с просьбой чтобы они оформили всю документацию ещё и +в HTML-виде, структурированно, с поиском. > Наверное, ты должен прекратить запускать нативную программу - браузер. ты не уовил самое главное: нативную программу Firefox -- Я ЗАПУСКАЮ САМ (по своему желанию)... а вот любой из нативных плагинов -- мог бы запуститься без моего ведома (см. пример выше про однопиксельный элемент внутри iframe внутри рекламы)
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	142. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 22-Дек-13, 13:56
	> 1. сложный формат. (провоцирует на создание ошибки). HTML и JS намного более сложные и фичастые чем какой-то несчастный PDF, так что если кто не может написать рендерер PDF без ошибок, куда ему в HTML и JS соваться?! При таком раскладе надо заниматься выращиванием рассады. Ну да, если вебпаги будут по 2 минуты рендериться - юзеры мозилу сразу на...й пошлют и ее доля сразу 0% станет. А тут в силу относительной редкости формата - общая непригодность рендерера к использованию не так паливна. И все бы ничего, но этот кусок бесполезного JS-шита только зря утяжеляет и тормозит браузер, при том что свои прямые обязанности выполняет из рук вон плохо. > 2. не WEB-ориентированный. (т.е. ему не место в WEB.. либо совсем, либо > его место должно быть там очень маленькое). Тогда еще менее понятно, какого хрена мозильщиков прорвало пихать этот тормозой глюкодром в браузер. Прости, чувак, эта дрянь тупит по 2 минуты, половину даташитов рендерит некорректно, перерисовка страницы по 5 секунд. Это на мощном проце. А на ноуте например у меня проц в разы слабее. С такими "инновациями" мозилла от славы ТОРМОЗИЛЛЫ не отмоется вообще... > PDF предназначен для печати на принтере, в основном. Слушай, дружок, давай ты мне не будешь говорить что делать с PDF - и я не скажу куда тебе пойти. Я без тебя и вебанашек из мозиллы разберусь что мне делать. А вот если кто вгружает мне в систему тормозной крап да еще имеет наглость ассайнить это как дефолтное действие - я имею основания для недовольства, да. > (кстате уже кто-то жаловался что PDF.js печатает PDF-документы очень плохо. в низком > разрешении, или ещё какие-то недочёты). 1) Кстати, слово "кстати" пишется через "и". Усвойте уже это, дорогие веб-папуасы. 2) Если уж мы о рендеринге, я даже не знаю что PDF.js делает хорошо. Как максимум он ресурсы хорошо жрет. Все остальное он делает плохо. Он не только плохо печатает, он большинство документов рендерит некорректно. Вполне логично что распечатает он это как минимум не лучше. И вообше, знаешь ли, весело, когда на схеме половины линий нет: годный ребус "от мозиллы" вместо даташита образуетя. "Попробуй угадать чего мы здесь забыли нарисовать, дорогой пользователь". > с чего ты взял что в парсинге HTML и JS  (и > воспроизведении) -- не было багов? :-) В парсинге PDF у PDF.js столько багов что я вообще не понимаю как этим можно пользоваться. Половина документов оказывается искорежена напрочь. Ну да, подумаешь, вьюшка половину документов не вьюит. "Зато на JS, мимими". > баги отлавливаются постоянно, затыкаются, затем опять отлавливаются новые.. и это > продолжтается уже много лет. Надо же, какие чудеса. И конечно же JS нас магически избавит от багов. Оно и видно, особенно на примере PDF.js как раз. Которым пользоваться практически невозможно. > в при выходе каждой новой версии Firefox -- оказывается что прошлая версия > Firefox содержала баги. в том числе баги, связанные с безопасностью. PDF.js - вообще один сплошной большой баг. > если к этим багам мы вдруг захотим ещё и прибавить баги от > парсинга PDF и баги парсинга SWF Ну да, а поезда сходят с рельсов, самолеты - падают, автомобили сталкиваются, на улице вас может подстерегать маньяк. Или просто метеоритом может зашибить. Так что давайте жить в подземных бункерах. А на улицу высовывать нос только в бронежилете, с миноискателем, в каске и противогазе, не забыв надеть костюм химзащиты. > PSF.js и Shumway позволяют ХОТЯБЫ не умножать уже существующее количество багов. Не понял, а что, баги в оных уже не считаются? Они свои прямые обязанности толком не выполняют, так что зачем они вообще место на винте занимают и компостируют мозг пользователя своими багами - мне вообще не понятно. ИМХО такой заслуживает только 1 варианта: пристрелить чтоб не мучались и не грели мозги юзерам своими тормозами и глюками. > то самое количество которое уже присутствуют в модулях обработки HTML+CSS+JS. Вот я и говорю - давай их на JS перепишем и посмотрим сколько юзеров у мозиллы после такой диверсии останется. См. выше про противогазы и бункер, в общем. Это примерно как припереться в театр в химзе и каске и получить от ворот поворот от охраны, постремавшейся пускать психа который своей грязной химзой все кресла перепачкает в здание. > а присутствие нативных плагинов (в отличии от PSF.js\Shumway) -- как раз умножают > это существующее количество багов. и как показывает практика -- различные виды > песочниц спасают от этого не доконца, так как код нативный. А упомянутые фиговины - кусок глючного крапа, который не выполняет свои прямые обязанности. По поводу чего это вообще следует снести: браузер облегчится, багов станет на многие сотни меньше. В том числе и багов связанных с безопасностью, если уж на то пошло. Потому что баги безопасности - тоже баги. Обычные в общем то. Например, как-то так по наблюдениям - нынче основная масса взломов серверов идет через вебню. Хоть там и нет никаких переполнений буферов. А взломы - есть. Не поясните - что за фигня, гражданин веб-хомячок? Оказывается дело не в сях а в багах которые сажают програмеры, да? В общем плач папуаса о том что острой бритвой можно порезаться, так что давайте лучше бриться палкой-копалкой - утомили. Ну и что что не бреет? Зато порезаться сложно! > как я уже писал выше -- нативный плагин запускатеся не по твоему > желанию пользователя, а по желаюнию WEB-страницы А мозилла с их click to launch в курсах? Они вроде это и придумали. Благо, интерактивность, даже JSная и прочая - очень даже может быть нежелательной и даже вредной. > от однопиксельного элемента внутри рекламного iframe-банера, и это будет явно не > datasheet). С таким же успехом HTML или JS будет "не совсем веб-страницей". Что ж вы не переписываете браузеровое двигло на JS? Ах, работает плохо? Ну а почему PDF можно хреново и тормозно рендерить? Ах, реже используется? Тогда если ты ходишь менее 10 километров в день - отпили себе ноги, они же редко нужны, без них можно обойтись. А перемещаться кое-как можно и на инвалидном кресле. > биткоины уже на компьютерах майнить не эффективно, даже через нативный код. Ну там есть еще лайткоины, которые нормально вполне. И еще куча всяких криптовалют. > а тут всё ещё байки про JS-майнеры :-) .. Как ты понимаешь, если майнинг за ТВОЙ счет - всем до балды на эффективность. Можешь котлован хоть зубочистками копать, это сугубо твои сложности. А если удастся миллион таких пригнать - даже чего-то выкопают. А то что эффективность лажовая - так не хаксор же электричество оплачивает, какая ему разница? Это же лох получит лишний счет за электричество, а не тот кто майнер ему отгрузил. > пишешь так будто ты защёл на страницу, и у тебя с пластиковой > карточки (из кормана) снялись деньги (через супер-мудрёную технологию Bitcoin!). Ну как бы если врубить майнинг в фоне на несколько потоков (а фоновые воркеры такое уже позволяют) - проц выйдет на свой максимальный TDP, у мощныз процов он достаточно приличный. А можно еще и GPU попробовать озадачить, через шейдеры например. В долговременном плане это вполне может долбануть по кошельку счетом за сожранную электроэнергию. Не то чтобы гигантски много, но быть лохом, оплачивая чужой профит из своего кошелька - маловато удовольствия. > смешно же, право! :) Всего лишь обычные реальности сегодняшнего дня. > ну закрой WEB-странцу, ды и всё, делов-то, Осталось только понять - кто из этих 20 сволочей проц в полку положил. У мозиллы с этим пониманием не богато пока. Мне как, 20 страниц наобум закрывать? Очень удобно и результативно :\. Вот потому NoScript и полезен - с ним большинство несанкционированной активности курит бамбук. > если тебе на ней что-то не понравилось. Есть намного более результативный подход - аппрувать активность через NoScript. > вот это уже более справедливое замечание. но совет тот же -- ну > закрой странцу, ды и всё, делов-то.. :-) Понимаешь ли, на странице может быть что-то нужное мне, поэтому я ее могу оставить на посмотреть как-нибудь потом. А то что кто-то решил там пранк сыграть мне может и не улыбаться. Поэтому предпочитаю NoScript: так можно открывать довольно много страниц без особой нагрузки на проц и сюрпризов, явно разрешая лишь те скрипты которые реально нужны в данный момент времени. А остальное - в пень. > хорошо бы конечно, если бы можно было бы в Firefox отключать звук. > но это кстате касается не только JS, но и HTML <video>\<audio> тегов. NoScript может блокировать любую интерактивность и "неожиданный" (не запрошенный явно самим пользователем) контент. Плагины, скрипты, webgl, редиректы страниц, аудио, видео, (i)frames... кроме того он пытается срубать clickjacking и поползноваения веб-паг сунуться в LANовые адреса (например в надежде поиметь какой-нибудь бажный девайс в LAN etc). Очень полезная штука, при том настраивается что именно давить, для trusted и untrusted. > безопасный JS ты запретил (потому что вдруг Bitcoin у тебя деньги с > карточки сворует!), зато опасные нативные плагины разрешил JS-вебанашки - такие вебанашки. Попробуй найти у меня хоть 1 плагин, для начала. Да, если ты не понял - PDFник открывается evince'ом, но только после подтверждения даунлоада. Эта же участь постигает большинство интерактивности. > (пусть опасный контент открывается > быстро, главное чтобы Биткоин деньги не воровал бы через JS!). Не, не так. Потенциально нежелательные операции разрешаются только там где это реально надо и только тем кому есть некоторое доверие. Остальные курят бамбук. На чем именно они там написаны - второй вопрос. Если уж на то пошло, теоретически, все тюринг-полные ЯП эквивалентны. Практически - могут быть некие отличия, но есть примеры как абузивных действий JS так и относительно безопасного использования голых сей. И да, я не понимаю чем запуск IR кода сгенеренного сями или кем там еще в песочнице принципиально отличается от запуска JS в песочнице. Разница только в носителе. IR код в виде биткода абстрактной VM относительно компактен и прост в трансляции, а JS для этого подходит как топор для сплава по реке. И пользуются им для этого не потому что это хорошо работает, а потому что он - есть. Но в долговременном плане лучше б его заменить на что-то типа PNaCl. Потому что транслировать например си в биткод LLVM а потом его перегонять в JS - редкостное извращение, скажу я вам. Заметь, в результате сишный код таки запускается в JS-овой песочнице и таки не может как-то особо гадить в систему, просто это достигнуто крайне извилистым и похабным маршрутом, пару этапов которого можно откинуть без зазрения совести и станет только лучше, при равном результате :) > вот именно! WEB-браузер не предназначен для чтения тучи даташитов. а ты пытаешься > его так использовать (ды ещё и JS отключил). Ну простите, даташиты выкладывают в веб. Логично что я их открываю оттуда. Впрочем, у меня нет плагинов, ретард. Evince - отдельная программа. И ее запуск таки подтверждается. Просто даже с подтверждением и скачкой файла целиком это как правило намного быстрее чем ждать pdf.js, который не только целиком качает файл но и педалит его потом целиком, если не повезло и шит большой - минутами, на мощном проце, ёлки. > чтение PDF-даташитов -- это БОНУСНАЯ функция WEB-браузера (а не основная). и именно > в бонусном виде PDF.js выполняет это отлично. :) С таким же успехом - пудовая гиря прикованная к твоей ноге тоже сойдет за бонус, имхо. > позвони производителю твоих любимых чипов с просьбой чтобы они оформили всю > документацию ещё и +в HTML-виде, структурированно, с поиском. Поисковики нормально ищут по PDF. И плюс PDF в том что его просто сгрузить целиком и потом читать независимо от интернета. Хоть в самолете, хоть в поезде, etc. >> Наверное, ты должен прекратить запускать нативную программу - браузер. > ты не уовил самое главное: нативную программу Firefox -- Я ЗАПУСКАЮ САМ Когда я клацаю PDFник - меня тоже спрашивают, хочу ли я его скачать или открыть вьюшкой. И я таки выбираю чего делать. Да, я поубивал дефолтное открытие PDF в браузере мозильским недоноском, поскольку оно имеет тенденцию надолго клинить проц, гораздо дольше чем клацнуть диалог скачки файла. Данный факт является особенно позорным для компонента интегрированного в браузер. Когда проще пользоваться внешней программой чем интегрированным в браузер костылем - это FAIL! > (по своему желанию)... а вот любой из нативных плагинов -- мог > бы запуститься без моего ведома (см. пример выше про однопиксельный элемент > внутри iframe внутри рекламы) Булшит, с JSом головного мозга, короче. Веб-хомячье - оно такое. Мозга нет, но мнение имеют. Если ты еще не понял - удачи вгрузить мне без спроса "однопиксельный PDF". Правда, для этого придется надуть диалог скачки файла у лисы каким-то макаром.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	145. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от Xasd (ok) on 22-Дек-13, 15:53
	> удачи вгрузить мне без спроса "однопиксельный PDF" прости, но я не могу сделать это для тебя -- ты же сказал что ты всё поотключал у себя. речь идёт о той ситуации, которую ты предлагаешь, а не о той ситуации, которую ты практикуешь :) .. [из твоего сообщения я так понял что предлагаешь ты одно, а практикуешь другое... возможно типичная ситуация когда человек сам не знает чего хочет (а возможно -- нет)] ************************************************************ а твой NoScript -- ты по сути используешь как словно люди используют Касперский на Винде.. ну допустим распознает NoScript пару типичных ситуаций с Clickjacking.. но наверняка можно найти ситуацию когда NoScript можно обмануть... ...злоумышленники просто не марочатся с NoScript, так как этот NoScript установлен у менее 0.5% пользователей WEB. вот так и выходит что в 90%-случаев NoScript что-то там распознаёт и блокирует. тоже самое как на заборе написать "осторожно злая собака" (и воры не будут входить в дом, опасаясь что возможно вдруг действительно злая собака). воры не будут входить в дом разумеется до той ситуации пока такое на своих заборах ни начнут писать все. техника защиты Trust/Untrust -- выглядет слегка слабова-то, учитывая что могут взломать необновлённую Джумлу на сайте даже которому ты доверяешь.. или учитывая [ОПЯТЬ ЖЕ! см прошлые сообщения] что сайт которому ты доверяешь -- может вставить рекламный банер от сторонней рекламной сети.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	151. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 23-Дек-13, 12:28
	> прости, но я не могу сделать это для тебя -- ты же > сказал что ты всё поотключал у себя. Более того - у меня получилось лучше чем у мозильщиков. В дефолтной конфиге мозилы-тормозилы кто угодно может пдфником заклинить проц на 5 минут и выжрать всю RAM, создав много дискомфорта. Попробуй так у меня похулиганить, удачи. > речь идёт о той ситуации, которую ты предлагаешь, а не о той > ситуации, которую ты практикуешь :) Ситуация простая как топор - качаем даташит и смотрим. Автооткрытие PDF вообще имхо сомнительно. Это может быть удобно иногда, но т.к. PDF в веб сроду никто не пытался *нормально* интегрировать, получилась самодеятельность в режиме "хотели как лучше, а получилось как всегда". Что у адобы, что у мозиллы. > [из твоего сообщения я так понял что предлагаешь ты одно, Я не предлагал открывать пдфники на автомате, в браузере. Это утырки из тормозилы решили что оно надо. При том нормально это сделать они не смогли: то что у них вышло, работает на порядок хуже чем внешняя вьюшка. Что как бы FAIL. > а твой NoScript -- ты по сути используешь как словно люди используют > Касперский на Винде.. Увы, сети - враждебная среда, где миллионы автоматических (и не очень) сущностей ищут для себя выгоду. Как правило в ущерб "вон тем лохам". Приходится учитывать. А эксплойт на сложное как черти-что двигло JS в принципе может и прилететь, даже в линух. Сугубо вопрос лени писателей сплойтов. С NoScript эксплойт на JS двигло имеет все шансы обломаться. Кроме того, аксиома: если есть тюринг-полный ЯП, существуют применения этого ЯП, которые могут владельцу машины не нравиться по тем или иным причинам. Значит, должны быть средства контроля выполнения. Хотя кому-то может и нравится летать на самолете, у которого управление отпало. > ну допустим распознает NoScript пару типичных ситуаций с Clickjacking.. > но наверняка можно найти ситуацию когда NoScript можно обмануть... Спору нет, хорошая ядерная ракета справляется с брезентовой палаткой и паршивеньким бункером примерно одинаково. Это не означает что защищенность палатки и бункера идентична. > NoScript что-то там распознаёт и блокирует. Кроме всего прочего, зарубание JS сильно нагибает возможности по внеплановому жульничеству. > такое на своих заборах ни начнут писать все. NoScript это не только надпись в виде значка, но и дрессированная собака, которая вполне в настроении порвать штаны левым личностям. > техника защиты Trust/Untrust -- выглядет слегка слабова-то, Сделай лучше, чтобы было не менее безопасно и не менее юзабельно. > учитывая что могут взломать необновлённую Джумлу на сайте даже > которому ты доверяешь.. Здесь мы наталкиваемся на магию теории вероятности. Вероятность того что случится все и сразу, в том виде каком оно сработает - ниже, чем в случае когда браузер выполняет все подряд. Грубо говоря, заходя на стройку довольно глупо не одевать каску, потому что "все-равно от метеорита и ядерной ракеты не спасает". > ЖЕ! см прошлые сообщения] что сайт которому ты доверяешь -- может > вставить рекламный банер от сторонней рекламной сети. Может. Только JS он выполнить не сможет. Да и сторонняя сеть скорее всего давно накрыта адблокплюсом...
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	149. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 22-Дек-13, 20:12
	> А вот тут возможны варианты, спору нет. С другой стороны, я не считаю что хочу увидеть майнер *-коинов на JS вкалывающий у меня по умолчанию, равно как мне не улыбается услышать адский ор в динамики в 3 часа ночи. Поэтому у меня noscrtipt есть и для обычного JS, если уж на то пошло. Майнер на JS он не хочет, а майнер на PNaCl это завсегда пожалуйста.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	152. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 23-Дек-13, 12:29
	> Майнер на JS он не хочет, а майнер на PNaCl это завсегда пожалуйста. Ну если его самолично инсталлировать надо - пусть будет, я не против.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

68. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
Сообщение от Vkni (ok) on 20-Дек-13, 18:20
Други, удалось ли кому-нибудь найти опции gcc/clang'а, использовавшиеся при компиляции? А-то ведь банальное -O0 замедляет код раза в пару раз по сравнению с -O2. ;-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

81. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–2 +/–
Сообщение от iZEN (ok) on 20-Дек-13, 20:28
Разверну мысли по поводу уместности Java™ внутри браузера. * идею Java извратили паковкой в JAR Изначальная идея была такова, что Java-апплеты (приложения) загружают свой код не весь целиком, а по мере востребованности байткода. То есть приложение начинает работать ДО того, как загрузился последний в списке .class-файл. Так как не все функции в приложении востребованы пользователем, то незачем грузить неиспользуемые .class-файлы, что и было реализовано в первоначальной модели распространения апплетов. Из-за накладных расходов на открытие HTTP/1.0-соединения на каждый затребованный апплетом .class-файл вынуждены были пойти на паковку ВСЕГО клиенского Web-приложения в один файл — сначала в ZIP, потом в JAR с метаинформацией для запуска. Это убило сразу три возможности: 1) динамическую кодогенерацию верифицированного и проверенного байткода на сервере "по запросу", которая сейчас дана на откуп всяким GWT, которые генерируют медленный интерпретируемый JavaScript; 2) иметь только необходимый байткод на клиенте в кэше браузера, включая части системного кода, а не отдельно установленную JRE с огромным rt.jar; 3) модуляризацию байткода "из коробки" в конце 1990-годов, которую безуспешно пытается сейчас достичь проект Jigsaw. В свете появления Web-сокетов накладные раскоды на подгрузку очередного затребованного .class-файла ничтожны. Необходимость паковки байткода и ресурсов в JAR-файл отпадает. * технология опорочена неэффективной JVM Изначально не было в рекламируемых JVM JIT-технологии трансляции, она была только у Microsoft и позднее появилась в Sun JRE. Из-за этого, а так же из-за долгого старта JVM в качестве плагина к браузеру, пользователи чувствовали тормоза Java-приложений. Они видели замедленную реакцию интерфейса на события мыши и клавиатуры. Отсюда пошла стойкая неприязнь к Java на клиентской стороне. Заранее запущенная JVM в составе браузера может нивелировать впечатления о работе клиентского байткода. Эта аналогия обоснована примером выполнения интерпретируемого динамического JavaScript внутри движка V8. Байткод статически-типизированного языка выполнялся бы гораздо быстрее. * апплеты подложили бомбу замедленного действия под клиентскую Java Апплеты ни дизайном, ни функционалом не вписывались никуда. Они не могли интегрироваться в рабочую среду, так как представляли собой невозможный с эстетической точки зрения концепт приложения "окно-в-окне".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	88. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 20:46
	Вот в таком варианте - угу, смотрится логично. Тем более, что JVM/байткод - не равно Java. Хоть скалу тащи, хоть что. Впрочем, (P)NaCl  с крайне остроумно придуманной гугловцами моделью безопасности мне как-то больше нравится - натив он и есть натив.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	125. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Аноним (??) on 21-Дек-13, 13:20
	> Впрочем, (P)NaCl  с крайне остроумно придуманной гугловцами моделью безопасности мне > как-то больше нравится - натив он и есть натив. Мне тоже - и ограничений на ЯП в принципе нет, в отличие от жабы, и скорость как у нативного кода практически. Зачем надо выбирать как промежуточный рантайм какую-то кривую и ограниченную блeвотину и потом долго бороться с ее свойствами там и тут? Не понимаю. Вот PNaCl смотрится в этом плане очень логичным артефактом.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	104. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 20-Дек-13, 22:25
	> * апплеты подложили бомбу замедленного действия под клиентскую Java > Апплеты ни дизайном, ни функционалом не вписывались никуда. Они не могли интегрироваться в рабочую среду, так как представляли собой невозможный с эстетической точки зрения концепт приложения "окно-в-окне". да, кстате. вот это действительно. не понимаю зачем только теперь уже Google (Chrome) пытается наступать на эти же грабли со своим (P)NaCl.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	110. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 23:47
	Они не встроились, потому что джава-апплеты - это, кроме тормозности, ещё и просто редкостный образец уродства - не только архитектурного, но и визуального, вот и всё. Тогда, когда они кого-то интересовали за пределами корпоратива с приличным интерфейсом в джаве, насколько я помню, вообще был полный швах. А в NaCl совершенно спокойно взлетит какой-нибудь E или Gtk вполне приличного вида - это если вообще этим штукам нужна будет своя отрисовка. Впрочем, я с нетерпением жду, когда в самом HTML5 люди начнут окнтролы на канвасе рисовать за полной непригодностью HTML для приложений.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	116. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 21-Дек-13, 04:12
	да, была какаято новость что мол какието ребята сделали програмный карказ, в котором контролы рисовались через WebGL (Canvas)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	126. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 13:22
	> А в NaCl совершенно спокойно взлетит какой-нибудь E или Gtk вполне приличного вида А еще там взлетит любая SDLная гамеза с весьма приличной скоростью, например. А на asm.js такое делать - это отдельный фееричный костылинг, а то что получится - полный ахтунг. И то что оно "работает и на браузерах без asm.js" - очень хилое утешение. Ибо кому оно надо с получившимися при этом 1.5 FPS'ами? Эстонцам? Это слишком медленно даже для них.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	137. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от Xasd (ok) on 21-Дек-13, 17:49
	> А еще там взлетит любая SDLная гамеза с весьма приличной скоростью, например. вот только кроме игр (технология "окно-в-окне", или "брайзер-в-браузере") -- сделать что-либо полезное врядле удасться с особым комфортом :) > А на asm.js такое делать - это отдельный фееричный костылинг пожалуй это правда. "окно-в-окне"\"браузер-в-браузере" делать через Asm.Js -- сложнее.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	143. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 22-Дек-13, 14:53
	> вот только кроме игр (технология "окно-в-окне", или "брайзер-в-браузере") -- сделать > что-либо полезное врядле удасться с особым комфортом :) На основе такой технологии можно делать в принципе что угодно. Кастомный кодек для видео, обсчет графики в реальном времени, или там чего еще. При том на сях сие делать оптимальнее чем на JS, ибо с статической типизацией и прочая - процу не надо будет прорву вычислений и проверок делать лишний раз. При том дестрой своего собственного адресспейса, простите, всем до лампочки. Покуда программа только свою песочницу загаживает. >> А на asm.js такое делать - это отдельный фееричный костылинг > пожалуй это правда. "окно-в-окне"\"браузер-в-браузере" делать через Asm.Js -- сложнее. Юзеж JS как IR - это феерический пи...ц, граждане. И оно имеет место быть не потому что это хорошо работает, а потому что ничего другого в браузерах не было. Я бы предпочел чтобы как IR распостранился относительно низкоуровневый и быстрый инструментарий типа PNaCl и песочницы под него, вообще не навязывающий ЯП на котором програмить и явно больше подходящий в качестве промежуточного представления нейтральных относительно платформы программ. А JS в таком качестве - как микроскоп в роли кувалды. Т.е. если сильно хочется - можно и им гвоздь вбабахать. Просто мучений намного больше чем могло бы быть с более правильно выбранным инструментом. Даже до гугля доползло что фигачить костыль в шпалу микроскопом - дурная затея, так что они приволокли нормальную кувалду. Мозилла решила что это слишком просто и неспортивно и поэтому пошла по пути увеличения длины тубуса и утяжеления основания чтобы микроскоп до кучи начал походить на сносную кувалду. Правда, кувалда все-равно лучше гвозди забивает, но теперь можно громко вопить на форумах о том что "теперь мы отстаем от кувалды не в 3 раза а только в 2!" и даже показывать чудеса, когда любителям микроскопов даже удается обогнать плохую, неудобную или сломанную кувалду иногда.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	147. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 22-Дек-13, 18:25
	> Кастомный кодек для видео, обсчет графики в реальном времени, или там чего еще. если сделаешь этот PNaCl-кодек -- чтобы он показывал видеоклип прямо внутри компонента <embed /> -- то просто навсего видео у тебя будет тормозить, при большом разрешении. если делать кодек для показа видеоклипа внутри <cancas /> (с применением WebGL) -- то делать на C/C++Emscripten+Asm.Js -- будет менее геморойно чем в PNaCl
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	153. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 23-Дек-13, 12:32
	> если сделаешь этот PNaCl-кодек -- чтобы он показывал видеоклип прямо внутри компонента > <embed /> -- то просто навсего видео у тебя будет тормозить, при большом разрешении. С чего бы? > -- то делать на C/C++Emscripten+Asm.Js -- будет менее геморойно чем в PNaCl Я и заметил - знакомые игроделы в два счета портируют гамезы под хром. А мозилле фига, ибо не собирается никто такими извращениями класса "фантомас в очках на аэроплане" страдать.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	108. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+2 +/–
	Сообщение от Аноним (??) on 20-Дек-13, 23:34
	> Изначальная идея была такова, что Java-апплеты (приложения) загружают свой код не весь целиком, а по мере востребованности байткода. То есть приложение начинает работать ДО того, как загрузился последний в списке .class-файл. Так как не все функции в приложении востребованы пользователем, то незачем грузить неиспользуемые .class-файлы, что и было реализовано в первоначальной модели распространения апплетов. Если class файлы грузить по необходимости, получим целый спектр проблем в дополнение к убогости жавы, включая зависание приложения на время загрузки нужного кода и отсутствие уверенности в том что весь код загружен и можно отключиться от сети. Вы в очередной раз демонстрируете полное непонимание даже платформы которую продвигаете.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	123. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от anonymos on 21-Дек-13, 13:17
	Изя, прекрати путать Java и JavaScript.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

85. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
Сообщение от Аноним (??) on 20-Дек-13, 20:37
_один_ столбик стал чуточку короче, а пафоса-то столько нагнали
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	97. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 20-Дек-13, 21:16
	> _один_ столбик стал чуточку короче, а пафоса-то столько нагнали А ты открой 1024 закладки - и почувствуй, что называется, разницу. :))))))))
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

91. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
Сообщение от Int on 20-Дек-13, 21:03
А отзывчивость интерфейса с прокруткой как тормозила так и тормозит
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

102. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
Сообщение от BrainFucker (ok) on 20-Дек-13, 21:34
Они лучше бы занялись оптимизацией той части, из-за которой браузер тормозит когда скрипты что-то модифицируют на страницах. Сложные математические операции редко где на сайтах выполняются, а свистоперделок полно. http://img22.imageshack.us/img22/6232/6314.png
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	105. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 20-Дек-13, 22:29
	> Они лучше бы занялись оптимизацией той части, из-за которой браузер тормозит когда > скрипты что-то модифицируют на страницах. Сложные математические операции редко где на > сайтах выполняются, а свистоперделок полно. > http://img22.imageshack.us/img22/6232/6314.png у тебя только одно ядро что ли? или это так настроен htop? (не, не.. я знаю что у Firefox нет хорошей многонитевости.. но просто спросил)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	106. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от BrainFucker (ok) on 20-Дек-13, 22:55
	Одно.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	139. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 21-Дек-13, 19:23
	печально :(
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	140. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–1 +/–
	Сообщение от BrainFucker (ok) on 21-Дек-13, 19:29
	> печально :( Нисколько. Особой необходимости нет. Компиляцией заниматься не приходится, видео кодировать тоже. Да и вообще проц редко нагружается на 100%.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	111. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 20-Дек-13, 23:49
	И что самое гадкое - никакого простого способа отследить, какая вкладка чудит, нет. Полцарства за аналог оперовского about:cpu!
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	112. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от BrainFucker (ok) on 20-Дек-13, 23:53
	> И что самое гадкое - никакого простого способа отследить, какая вкладка чудит, нет. Дык, текущая же. Если переключиться на другую, где нет свистоперделок, то грузить перестаёт. Хотя, может и не со всеми скриптами так, не помню.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	114. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Crazy Alex (ok) on 21-Дек-13, 02:01
	Нет, как ни странно, нет. То есть я методом тыка иногда вылавливал проблемные вкладки, но разобраться, чем они отличаются, у меня энтузиазма не хватило. ЖЖ такое творит время от времени, GMail - тоже, хоть и реже, хабр... остальное не помню. Что сволочно - проявляется  непредсказуемо.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

129. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
Сообщение от Аноним (??) on 21-Дек-13, 15:10
>В настоящее время Asm.js позиционируется в качестве "ассемблера для Web" False. Это "an extraordinarily optimizable, low-level subset of JavaScript". То есть, это даже не новый язык, тем более не ассемблер.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	130. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 21-Дек-13, 15:40
	> Это "an extraordinarily optimizable, low-level subset of JavaScript". То есть, это даже не новый язык, тем более не ассемблер. Правильно. Поэтому вот здесь > в качестве "ассемблера для Web" стоят кавычки.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	131. "Новые оптимизации в Firefox сократили разрыв в производитель..."	–3 +/–
	Сообщение от Аноним (??) on 21-Дек-13, 15:58
	И что эти кавычки должны означать? Переносный смысл? В чем он тогда заключается?
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	144. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 22-Дек-13, 14:55
	> И что эти кавычки должны означать? Переносный смысл? В чем он тогда > заключается? В том что гражданин сказал несколько абстрактно. На самом деле он имел даже не только ассемблер, сколько промежуточное представление программы в платформо-нейтральном виде (IR). В любом случае, JS для этого - полный торч!
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	146. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Xasd (ok) on 22-Дек-13, 16:33
	> ...промежуточное представление программы в платформо-нейтральном виде (IR). В любом случае, JS для этого - полный торч! ну ок, Js в качестве IR -- плохо.. а Asm.Js в качестве IR -- тоже плохо? ведь Asm.Js не является Js -- надо помнить об этом (хотя Asm.Js имеет некоторую совместимость с Js, но всё равно Asm.Js не является Js). а то из-за вашей путанницы Js и Asm.Js -- у вас получается как в софизме: [quote] Софист: А что, у тебя есть собака? Крестьянин: Да, есть, сука, и преогромная. Софист: А есть ли у неё щенята? Крестьянин: Да, есть, родила недавно. Софист: То есть получается, что эта собака --- мать? Крестьянин: Да. Софист: И эта собака твоя, не так ли? Крестьянин: Ну да, моя, я же сказал. Софист: Ага, ты сам признал, что твоя мать --- собака. Значит, ты сукин сын! [quote]
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	154. "Новые оптимизации в Firefox сократили разрыв в производитель..."	+/–
	Сообщение от Аноним (??) on 23-Дек-13, 12:35
	> ну ок, Js в качестве IR -- плохо.. Ну вот видишь, ты сам это сказал. > а Asm.Js в качестве IR -- тоже плохо? Да, это - плохо. Потому что вместо того чтобы задизайнить для задачи "вбить гвоздь" нормальный инструмент "кувалда", мозильщики начали заниматься какой-то фигней с попыткой превратить микроскоп в подобие кувалды при помощи твикинга размера тубуса и утяжеления основания.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема