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

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

"В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
Сообщение от opennews (??) on 29-Июн-14, 00:35
Доступен первый выпуск проекта Runtime.JS (http://runtimejs.org/), нацеленного на предоставления средств для обособленного выполнения JavaScript-приложений поверх гипервизоров. Runtime.JS представляет собой ядро операционной системы, в которое встроен JavaScript-движок V8. Целью разработки является предоставление операционного окружения для выполнения программ на языке JavaScript без лишних прослоек.  Ориентация только на запуск  JavaScript-кода позволяет пересмотреть архитектуру ядра и предоставить более высокий уровень безопасности, надёжности и производительности. Код Runtime.JS распространяется (https://github.com/runtimejs/runtime) под лицензией Apache 2.0. На языках Си и C++ реализованы только низкоуровневые компоненты для организации загрузки, управления памятью, обработки прерываний, организации ввода/вывода, планирования задач и взаимодействия с движком V8. Всё остальное написано на языке JavaScript, включая драйверы, код управления ресурсами, систему разграничения доступа и средства для управления сеансами. Виртуальная ФС, сетевой стек и подсистемы ввода и вывода оформляются в виде системных сервисов, привязываемых к JavaScript-приложениям, которые выполняются в изолированных друг от друга sandbox-окружениях. <center><a href="http://runtimejs.org/docs/arch.html"><img src="http://www.opennet.me/opennews/pics_base/0_1403984815.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> Система является многозадачной - поверх базового ядра может выполняться несколько изолированных приложений. При этом многозадачность не позволяет использовать традиционные процессы или нити, вместо них обеспечивает запуск JavaScript-окружений, по аналогии с открытием разных вкладок в браузере. Для диспетчеризации задач используется работающий в неблокирующем режиме цикл обработки событий (event loop (http://en.wikipedia.org/wiki/Event_loop)), похожий на применяемый в проекте Node.js. В системе запускается по одному экземпляру виртуальной машины V8 на каждое процессорное ядро. Все компоненты ядра, драйверы и пользовательские приложения выполняются в едином адресном пространстве в режиме ядра (ring 0). Защита и изоляция обеспечивается программно силами движка V8. Поддерживается только архитектура x86_64. Из уже реализованных возможностей отмечается: встроенный движок V8, кооперативная многозадачность, перемещаемые через IPC функций и  ArrayBuffer, поддержка SMP и ACPI, драйверы для PCI, клавиатуры и VGA-адаптера, приложение с консолью (REPL). В планах создание сетевого стека, виртуальной файловой системы и набора драйверов virtio для хранилищ и сетевых адаптеров. <center><a href="http://runtimejs.org/img/runtimejs_2.png"><img src="http://www.opennet.me/opennews/pics_base/0_1403987477.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> URL: http://runtimejs.org/ Новость: http://www.opennet.me/opennews/art.shtml?num=40103
Ответить | Правка | Cообщить модератору

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

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

1. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
Сообщение от Аноним (??) on 29-Июн-14, 00:35
Ждём ось, целиком и полностью написанную на жёванном языке.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	30. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:36
	Да уж, фэйл вышел: > На языках Си и C++ реализованы только низкоуровневые компоненты. Вот такой вот хреновый яваскрипт...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	45. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+17 +/–
	Сообщение от Anonymus on 29-Июн-14, 09:38
	Да уж, надо было начинать с компилятора яваскрипта на яваскрипте. И только потом за ось браться. Столлмана на них нет.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	84. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от qrilka on 29-Июн-14, 19:44
	Их же уже есть, первое из гугла - http://eleks.github.io/js2js/
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	160. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от Xasd (ok) on 30-Июн-14, 12:57
	а они забавные приколисты :-) .. // https://github.com/eleks/js2js/blob/master/src/compiler.js // ... ... // ... ... Js2JsCompiler.prototype.compileCode = function(code) {     return code; // as we need to compile javascript to javascript, we do nothing here :) }; // ... ... // ... ... там кстати есть и функция обратной декомпиляции :-)
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	103. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:52
	> Да уж, надо было начинать с компилятора яваскрипта на яваскрипте. Способность бутстрапнуться - признак серьезного подхода к делу.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	106. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 21:50
	Т.е. компилятор C++(llmv) для C++ вас не смущает?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	131. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:25
	> Т.е. компилятор C++(llmv) Во первых, llvm - это таки либа. Во вторых, она не llmv.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

2. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–25 +/–
Сообщение от Аноним (??) on 29-Июн-14, 00:37
что то я не понял, разрабы как и идиоты из геймдева на онли 64 бита, из за более большой циферки перешли только? ну ладно, у пк игр можно кривые порты оправдывать 64 битностью новых приставок. но не хватало, чтоб браузеры тоже на только 64 бита перешли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от BratSinot (ok) on 29-Июн-14, 00:38
	С такими требованиями к памяти, браузеры в первую очередь перейдут -_-" P.S. Ну, а так-же напоминаю, что прелести amd64 и прелести 64-битной адресации это разные вещи.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	27. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+6 +/–
	Сообщение от Xasd (ok) on 29-Июн-14, 07:36
	> что то я не понял, разрабы как и идиоты из геймдева на онли 64 бита, из за более большой циферки перешли только? ну ладно, у пк игр можно кривые порты оправдывать 64 битностью новых приставок. но не хватало, чтоб браузеры тоже на только 64 бита перешли. а какой есть хоть один смысл поддерживать i586\i686-архутектуру ? и даже если вы [с трудом] и найдёте хоть один такой смысл -- то через год будет найти смысл ещё труднее. разрабы начинают писать софт сегодня -- а выпустят нормальный релиз ещё неизвестно через сколько лет (к тому времени можно ли будет найти [на свалке?] хоть один i586\i686-only процессор?). поэтому было бы совершенно глупо полагаться на сегодняшние устаревщие технологии, которые в будущем станут не просто устаревшими а невероятно_устаревшими, в момент релиза. если имеет место быть некросплатформенное ПО (ассемблерные вставки и подобное трудности) -- то я откровенно уважаю решение не связываться с i586\i686.. это дальновидно.. точнее это даже УЖЕ не дальновидно а стало нормальным (а вот тройку~четвёрку лет назад это было бы дальновидно).
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	32. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+5 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:39
	> что то я не понял, разрабы как и идиоты из геймдева на > онли 64 бита, из за более большой циферки перешли только? А еще - нет ограничений на размер выделяемой памяти. Более нормальный набор регистров, так что программа не состоит на 50% из push+pop. Гарантированный SSE2. Ну и быстрые операции с 64-битными числвами. И да, более мелкие величины прекрасно считаются как частный случай 64-битных. А вот если вам из коротких регистров надо более широкую математику - это уже тормозная этажерка кода получается.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	41. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 29-Июн-14, 08:49
	а также больше размер страницы, больше размер управляющих структур (бедные кэши) и реально выигрыша почти никакого (или никакого вообще). а push/pop в современных процессорах совсем не такой дорогой, как кажется. да и делают его только совсем глупенькие кодогенераторы, остальные вполне умеют регистры распределять получше. как будто при вызове функций регистры не замусориваются, и их не надо сохранять и восстанавливать. никуда любимые перезагрузки не делись, просто register allocators можно писать подубовей, вот и всё. p.s. тьфу. «более оптимально». липнет, зараза…
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	47. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 09:56
	Размер страницы в long mode и 32 bit Protected Mode одинаков - 4kB Большие страницы в long mode 2MB, в 32 2MB (PAE) или 4MB. > а также больше размер страницы, больше размер управляющих структур (бедные кэши) и > реально выигрыша почти никакого (или никакого вообще). а push/pop в современных > процессорах совсем не такой дорогой, как кажется. да и делают его > только совсем глупенькие кодогенераторы, остальные вполне умеют регистры распределять > получше. > как будто при вызове функций регистры не замусориваются, и их не надо > сохранять и восстанавливать. никуда любимые перезагрузки не делись, просто register allocators > можно писать подубовей, вот и всё. > p.s. тьфу. «более оптимально». липнет, зараза…
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	54. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 10:32
	> Размер страницы в long mode и 32 bit Protected Mode одинаков - > 4kB ужас какой. то есть, никакого смысла в 64-х битах нет, если памяти не больше 4 гигов. а если больше… ох, таблички вы мои, таблички, ох, вы кэшики в проце…
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	56. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от BratSinot (ok) on 29-Июн-14, 11:06
	Размер страницы и их количество это разные вещи -_-"
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	75. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 19:03
	> Размер страницы и их количество это разные вещи -_-" действительно. четыре гигабайта поделить на четыре килобайта, и четыре гигабайта поделить на мегабайт… никакой связи между размером страниц и их количеством нет, правда? ну и само собой: для хранения таблиц страниц всегда надо одинаковое количество памяти, вне зависимости от количества страниц, не так ли?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 11:36
	>> Размер страницы в long mode и 32 bit Protected Mode одинаков - >> 4kB > ужас какой. то есть, никакого смысла в 64-х битах нет, если памяти > не больше 4 гигов. а если больше… ох, таблички вы мои, > таблички, ох, вы кэшики в проце… Вывод не верный, скорее, как раз наоборот)) За редким исключением. Пруф - сравните openssl speed в обоих случаях.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	76. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–3 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 19:04
	— слушай, но этот движок же больше бензина жрёт! — ты не прав. смотри, какое у меня седло!
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	121. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 01:45
	> — слушай, но этот движок же больше бензина жрёт! > — ты не прав. смотри, какое у меня седло! Тем не менее, многие функции шифрования и хеширования лучше работают на 64-битных регистрах нежели 32-битных. Да и гарантированный SSE2 там как-то не лишний...
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	124. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–3 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 02:06
	> Тем не менее, многие функции шифрования и хеширования лучше работают на 64-битных > регистрах нежели 32-битных. Да и гарантированный SSE2 там как-то не лишний... а на GPU часто ещё лучше.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	129. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:19
	> а на GPU часто ещё лучше. На проц типа х86-64 1 копия рабочего набора переменных как правило и так уместится по регистрам - сильно лучше не станет. Хотя если ты хотел гонять 100500 потоков впараллель, получится как-то так... -------------------------------------------------------------------------------- OCL 0: 61.0C | 268.0/265.9/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 0:       |  2.19/ 2.18/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 1:       |  2.18/ 2.16/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 2:       |  2.24/ 2.21/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 3:       |  2.18/ 2.18/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 4:       |  2.15/ 2.19/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 5:       |  2.21/ 2.20/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 6:       |  2.20/ 2.21/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none CPU 7:       |  2.25/ 2.24/ 0.00Mh/s | A:0 R:0+0(none) HW:0/none -------------------------------------------------------------------------------- (да, GPU весьма иллюстративно вставляет CPU).
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	137. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 04:44
	> Хотя если ты хотел гонять 100500 потоков впараллель таки да, зачем ещё бедный GPU-то мучать…
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	158. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 12:25
	> таки да, зачем ещё бедный GPU-то мучать… Кажется у тебя вон там баг ^^^^^^ :). Обрати внимание что это  массово параллельный вариант. Для шифрования пары сетевых конекций хватит и проца выше крыши. Хотя если ты вдруг сервер и счет конекций идет на тысячи, тут GPU уже начинает смотреться вполне себе EPIC WINом. Если забыть о том что SSL и TLS в основном являют собой декоративное фуфло для отвода глаз, разумеется.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	143. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Xasd (ok) on 30-Июн-14, 08:51
	> а на GPU часто ещё лучше. а как ты будешь использовать GPU в коде ядра? GPU-то ведь разные бывают (их сотни -- и постоянно изобретаются новые) -- как будешь делать ветвление в зависимости от того какой GPU тебе попался? усложнишь код ядра -- динамически подключаемыми модулями (lib*.so ; *.ko) -- только ради того чтобы заиспользовать криптографию? тыг криптография не плохо работает и на x86_64 -- без необходимости костылей.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	144. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 30-Июн-14, 09:08
	>> а на GPU часто ещё лучше. > а как ты будешь использовать GPU в коде ядра? а зачем?
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	155. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Xasd (ok) on 30-Июн-14, 11:41
	ну вообще может и не понадобится
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	159. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 12:30
	> а как ты будешь использовать GPU в коде ядра? Не очень понятно что ядру в таком количестве считать предлагается. > как будешь делать ветвление в зависимости от того какой GPU тебе > попался? Отдать нужному драйверу, а он пусть разбирается чего там с его железкой делать надо. Как-то так и поступают, правда, через либы в юзермоде это как-то удобнее получается. > ради того чтобы заиспользовать криптографию? Вообще, ядро предоставляет сервисы криптографии. Но мысль впихать в ядро компилятор собирающий для GPU нативный код таки выглядит перебором. > тыг криптография не плохо работает и на x86_64 -- без необходимости костылей. Да, вон там рядом можно посмотреть мою табличку, иллюстрирующую как x86_64 ядра демонстрируют скорость менее 1% от GPU. Открытый графический стек, кстати. Его оптимизить еще не начинали толком, в отличие от gcc и алгоритмов на SSE4-асме, которые на проце работали :)
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	66. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+5 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 15:13
	> а также больше размер страницы, Пардон?! Стандартные 4Кб страницы никуда не делись?! Еще появились huge pages, но это весьма дополнительная опция вообще-то. И как раз снижает оверхед, если надо большой регион памяти. Весь пойнт как раз в том чтобы не работать с большим непрерывным регионом пипетками по 4Кб, вымывая буфера (TLB, etc). > больше размер управляющих структур (бедные кэши) Кэши у х86-64 как правило не слишком мелкие. А еще, в х86-64 появилась относительная адресация (приветы дeбильному x86). Так что совершенно не обязательно передавать 64 бита адреса всегда и везде, можно как относительную дельту vs текущее место выполнения. Еще и релокейшны на старте не придется педалить в диком количестве для трансляции программы в другие адреса (что помогает вещам типа ASLR, делая их куда более "дешевыми" по ресурсам). > и реально выигрыша почти никакого (или никакого вообще). А бенчи обычно иного мнения на этот счет. Конечно EPIC WIN с пятикратным разгоном может настать только в каких-то краевых случаях, когда алгоритм сильно оптимизировали под 64 бита, используя 64-битные величины в каждом закоулке (современные алгоритмы щифрования и хэширования, например). Но поскольку нынче в 32 бита не лезет даже просто смещение в файле - 64 бита в таких реалиях лишними совсем не выглядят. В конце концов, 64-битные регистры при нужде и 32-битные числа неплохо крушат. А вот наоборот - уже болт. > а push/pop в современных процессорах совсем не такой дорогой,как кажется. Ну да, подкостылить пришлось. Какой-то отдельный буфер IIRC даже сделали. Вот это я понимаю - костылестроение для уродца :). > да и делают его только совсем глупенькие кодогенераторы, Щаз. Обычный вызов функции на х86 == push + pop. ABI такое. А у х86-64 функции с небольшим числом параметров (а таких большинство) могут получить параметры и отдать результат через регистры. У х86-64, в отличие от, регистровый файл позволяет такую роскошь. Это ж не х86 с полутора РОНами. > остальные вполне умеют регистры распределять получше. Распределяй, не распределяй, а полутора РОНов не хватит чтобы отдать функции параметры и забрать результат. Еще и считать где-то надо... > как будто при вызове функций регистры не замусориваются, Посмотри на ABI. Там выделены регистры для передачи параметров на вход, на локальный счет и на отдачу результата. PUSH+POP придется только если их не хватило, т.е. какие-то навороченные функции с дофига параметров/результатов или адским счетом под который не хватило "локальных" регистров. > никуда любимые перезагрузки не делись, В половине случаев их может и не быть - за счет упомянутого ABI.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	80. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 19:20
	>> а также больше размер страницы, > Пардон?! Стандартные 4Кб страницы никуда не делись?! ну я же и говорю: или огромные страницы, или огромные таблицы страниц. жутики. > Кэши у х86-64 как правило не слишком мелкие. таблицы страниц тоже. а ещё не вредно вспомнить, что в кэш радостно лезут и прикладные софтины. и всем надо-надо-надо! > А еще, в х86–64 появилась относительная адресация (приветы дeбильному x86). с тем, что там попытались немного починить систему команд (приделали инвалиду деревянную ногу — хотя не было у инвалида руки) я, кажется, не спорил. >> и реально выигрыша почти никакого (или никакого вообще). > А бенчи обычно иного мнения на этот счет. бенчи вообще часто «иного мнения», потому что живут в своём параллельном мире. >> а push/pop в современных процессорах совсем не такой дорогой,как кажется. > Ну да, подкостылить пришлось. Какой-то отдельный буфер IIRC даже сделали. Вот это > я понимаю - костылестроение для уродца :). то ли дело стройный красивый x86_64 — ну совсем ни разу не костыли! >> да и делают его только совсем глупенькие кодогенераторы, > Щаз. Обычный вызов функции на х86 == push + pop. ABI такое. и что? это ABI для библиотек. внутри программы её личные функции компилятор может вызывать так, как хочет. конечно, если программа занимается в основном тем, что вызывает библиотечные функции, которые ничего не делают, то это беда. но нужна ли такая программа? > А у х86-64 функции с небольшим числом параметров (а таких большинство) > могут получить параметры и отдать результат через регистры. эффективно убрав эти регистры из списка свободно используемых. а если вдруг из функции другую (или эту же, хихикс) функцию понадобилось вызвать… ой, что это? push/pop? а-я-яй… да, кстати. куча регистров — это костыль. ты не знал? так знай: куча регистров — это просто такой дополнительный кэш памяти, только ним зачем-то приходится вручную управлять. тьфу, гадость. >> остальные вполне умеют регистры распределять получше. > Распределяй, не распределяй, а полутора РОНов не хватит чтобы отдать функции параметры > и забрать результат. Еще и считать где-то надо... у тебя функции в вакууме живут. если функция impure, то она вызывает другие функции, и всё равно вынуждена эти свои параметры и временные значения сначала совать в память, а потом из памяти доставать. а если pure — то нормальный компилятор её просто заинлайнит и не будет ерундой заниматься. >> как будто при вызове функций регистры не замусориваются, > Посмотри на ABI. а ты посмотри на мой текст выше. >> никуда любимые перезагрузки не делись, > В половине случаев их может и не быть - за счет упомянутого > ABI. магия цифр — страшная вещь. — смотрите, у нас больше регистров, теперь можно вызывать функцию с параметрами в регистрах, а не на стеке! — ура-а-а-а! — извините, а что, если мне несколько функций одну из другой вызвать надо? оно же всё равно где-то в памяти будет вынуждено запоминать значения? и какая разница тогда? — уйди, мальчик, не мешай ликовать! ура-а-а-а!
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	120. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 01:36
	> ну я же и говорю: или огромные страницы, или огромные таблицы страниц. Да вообще!!! А боингу для взлета надо 2 пилота + всяких там стюардесс. Еще толпа техников для обслуживания, несколько спецмашин и здоровенный ангар для хранения. А еще аэродром и персонал на нем. Вот ведь чертов оверхед. То ли дело деревенская телега - стоит в сарае, управляется 1 человеком, лошадь еду под ногами находит. Оверхеда минимум. Правда, почему-то из москвы в владивосток дольше едет, хотя на посадке час вроде сэкономили. О чем это я? О том что если памяти много - ну да, придется потратиться на ее обслуживание. А в среднем по больнице добавление памяти в систему ... только улучшает ее свойства. Например, cache hit вместо обращения к тормозному накопителю - куда как улучшает отзывчивость системы и производительность дисковых операций. Вообще, если задолбали тормоза, можно: - Поставить SSD для системы. - Поставить максимум оперативки на который на жаль денег или который технически возможен. - Выключить на#$% своп и забыть про эмуляцию оперативки диском как страшный сон. И, кстати, например линковка линевого ядра с механического диска может работать с вполне "SSDшной" скоростью. Если оперативы много - RAM-диски они быстрые, заразы. А чем больше кэшей, тем больше оно RAM-диск и меньше - механика. > таблицы страниц тоже. а ещё не вредно вспомнить, что в кэш радостно > лезут и прикладные софтины. и всем надо-надо-надо! Тем не менее, на практике нарваться на сколь-нибудь ощутимые penalty - надо сильно постараться. Наверное есть какие-то краевые случаи где это заметно. Но в большинстве типовых задач добавление в систему кучи оперативки подвержено принципу "кашу маслом не испортишь". А хотя-бы чтобы своп навсегда выключить. Один дерг механического диска по времени займет на несколько порядков больше чем дополнительный лукап в оперативе. Тем более что 1 лукап в добавочной таблице в RAM при результате в 4К-блок в любом случае обеспечит неплохой "КПД". > с тем, что там попытались немного починить систему команд (приделали инвалиду > деревянную ногу — хотя не было у инвалида руки) Ноги у инвалида тоже не было, как видим. Вообще, интел должен помереть жестокой смертью за то что система команд из 70-х годов прошлого века живет до сих пор. На момент разработки этого хлама оно такое было потому что каждый транзюк экономили. Но при миллиарде транзисторов на кристалле это уже просто маразм имени совместимости с древним гуано. > бенчи вообще часто «иного мнения», потому что живут в своём параллельном мире. Как ты понимаешь, я интересуюсь только их вариантами которые имеют какое-то отношение к моим сценариям использования и, соответственно, коррелируют с тем что я увижу. Могу сказать что я точно НЕ увижу: cache miss в TLB я совершенно точно на глаз никогда и нигде не замечу. Поэтому то что их может стать несколько больше - мне до фонаря! Зато cache hit в дисковый буфер сииииииильно улучшает работу системы. В заметном мне виде. Особенно с механическими дисками. И один cache hit в дисковый буфер - переплюнет добрый месяц работы с cache miss в TLB по выигрышу времени. Знаешь песенку про мельника? Который истратил шиллинг, заработал грош? Вот это про TLB vs большая память ;). > то ли дело стройный красивый x86_64 — ну совсем ни разу не костыли! Костыли и полумеры, но - лучше чем то что было до этого. Стало хотя-бы отдаленно смахивать на более-менее приличные процессоры. > тем, что вызывает библиотечные функции, которые ничего не делают, то это > беда. но нужна ли такая программа? В конечном итоге если программа не занимается каким-то хардкорным математическим счетом - она вызывает библиотечные функции. Это так странно? А даже если и занимается - тот же (аудио,видео)плеер, например - делает немало вызовов в библиотеки всех мастей. В том числе и для того чтобы прочесть, декодировать, а потом сбагрить декодированное на экран и/или в звуковуху. Еще бывают программы которые вообще ничего не делают, но sleep(100500) в чрезмерной оптимизации как-то и не нуждается... >> могут получить параметры и отдать результат через регистры. > эффективно убрав эти регистры из списка свободно используемых. Это примерно как рекламировать ампутацию ног, с аргументом "не будут ботинки натирать". А у x86 даже и убрать нельзя - изначально нету. > а если вдруг из функции другую (или эту же, хихикс) функцию понадобилось вызвать… ой, > что это? push/pop? а-я-яй… Так я не говорю что push и pop совсем не будет. Просто их будет меньше. > да, кстати. куча регистров — это костыль. ты не знал? так знай: > куча регистров — это просто такой дополнительный кэш памяти, только ним > зачем-то приходится вручную управлять. тьфу, гадость. Это не просто память, это "умная память" - с ними можно математические операции производить, на то и РОНы. Если уж на то пошло, тогда архитектуры с 1 или несколькими аккумуляторами, типа x86 - вообще гэ неимоверное, еще более костыльное. В идеале, конечно, вся память должна обладать такими свойствами, но память работающая со скоростями проца получается только как SRAM. А это минимум 6 транзисторов на ячейку, даже без всякой математики. А если еще и математику с всеми ячейками захотеть...  А у DRAM - 1 транзистор на ячейку. Ну вот и делают компромиссно. Кстати, видал подобное: у одного из процов с которым я имел дело, регистры мапились в накристальный RAM и даже имели адреса в памяти. Очень кстати удобно: например полностью переключить контекст - 1 регистр-указатель переписать, и вот уже другой адрес = другое содержимое регистров. Можно сделать убер-эффективный аналог полного (или частичного) пуш-попа, щелкая 1 указателем вместо всей кипы регистров. Но, правда, накристальная память очень лимитирована по размеру, а возможность напрямую адресовать регистры проца позволила поиметь ... море лулзов. Прикольно вкатить новое значение регистров через buffer overrun, правда? :). > у тебя функции в вакууме живут. если функция impure, то она вызывает > другие функции, и всё равно вынуждена эти свои параметры и временные > значения сначала совать в память, а потом из памяти доставать. Можно и через регистры обмениваться. И пересылка между регистрами - просто и быстро, обращения в память намного дольше. Ибо, знаешь ли, не хватит на всех ячеек суперскоростной памяти, между которыми еще и математику можно делать. А обычный DRAM и даже кэши - тормознее. И без математики между ячейками. > а если pure — то нормальный компилятор её просто заинлайнит и не > будет ерундой заниматься. Тем не менее, когда есть куча регистров, у компилятора больше возможностей для маневра. Сам по себе push + pop == NOP. Суммарный эффект равен нулю. Чисто технический костыль по поводу "не хватило регистров". Чем больше регистров - тем реже такая ситуация наступает. В предельном случае, если регистров бесконечно много, их хватает всегда :). > а ты посмотри на мой текст выше. Посмотрел. Не отменяет того что чем больше регистров - тем чаще в них влазит без тасования лишний раз. > — уйди, мальчик, не мешай ликовать! ура-а-а-а! Как-то так :)). Хотя-бы по поводу того что мега-у...ще стало просто у...щем. Улучшение, как ни крути :).
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	123. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 02:05
	> Да вообще!!! правда, любители «новых технологий» заводят «боинг» даже если надо в булочную за углом сбегать. > Вообще, если задолбали тормоза нет, задолбало пихание 64-битности во все дыры. и да, x32 придумывали не просто так, например. потому что большинству софта не нужно больше нескольких гигов RAM, а на указатель всё равно будь любезен потратить 64 бита. а чо, не жалко, памяти же много! где-то я такое уже видел… а, вспомнил! «что? наш серер на java тормозит? купите сервер поновей и памяти досыпьте, не жмотьтесь!» > - Выключить на#$% своп и забыть про эмуляцию оперативки диском как страшный > сон. я на своих 4gb так и работаю, кстати. при этом у меня запущена куча софта, собирается немало кода с кучей шаблонов и CTFE… и «в среднем по больнице» где-то гиг памяти свободен. > Тем не менее, на практике нарваться на сколь-нибудь ощутимые penalty - надо > сильно постараться. игроделы дружно разбивают себе лица фэйспалмами. поспрошай на досуге, как они любят тратить 64 бита на указатель, которому достаточно 32, как у них от этого раздуваются структуры данных и сколько новых матюгов они от этого изобрели. да и не только игроделы, в принципе… > Могу сказать что я точно НЕ увижу: cache miss в > TLB я совершенно точно на глаз никогда и нигде не замечу. классно тебе. и раздувания структур данных тоже не заметишь. а вот многие другие — замечают. поэтому, например, попытались придумать x32. > В конечном итоге если программа не занимается каким-то хардкорным математическим счетом > - она вызывает библиотечные функции. (опять имитируя принцессу Альбину) у-ла-ла! а я тебе о чём? соответственно, регистры мусорятся влёт. и их надо или перезагружать, или сначала сохранять, а потом перезагружать. привет, неявный стек! > А у x86 даже и убрать нельзя - изначально нету. есть, есть. хотя их несимметричность раздражает. > Так я не говорю что push и pop совсем не будет. Просто > их будет меньше. ага. умные современные компиляторы тоже не занимаются таким: они просто выделяют стековый фрэйм и запихивают туда данные при помощи mov. реальный выигрыш — это какая-то, например, математика по массивам с кучей измерений. и то во многих случаях компилятор «раскрутит» циклы и будет использовать один-два регистра для адресации. > Это не просто память, это "умная память" - с ними можно математические > операции производить, на то и РОНы. это не отменяет костыльности. > тогда архитектуры с 1 или несколькими аккумуляторами, типа x86 - вообще > гэ неимоверное, еще более костыльное. конечно. эти костыли с древних времён тянутся, когда вообще всё печально было. > Кстати, видал подобное: у одного из процов с которым я имел дело, > регистры мапились в накристальный RAM и даже имели адреса в памяти. нечто похожее в 6502, кстати. не совсем, но адресовать первые 256 байтов там достаточно удобно, их и использовали как «дополнительные регистры». > Можно и через регистры обмениваться. можно. а с рабочими регистрами что делать? функция-то в библиотеке, межпроцедурная оптимизация не того-с. правильно: как я и написал, после вызова смело считать, что в регистрах мусор и весело загружать их заново. чем больше регистров — тем больше и загружать. я ж говорю: выигрыш в основном в том, что для компилятора выражений доступно больше «быстрых хранилищ», поэтому его можно не учить петь «боже, царя храни», стоя на голове и жонглируя стеклянными шариками. но это не настолько критично, в принципе: умный cse всё равно нужен. плюс сброс регистров на узле ветвления. и если посмотреть на большинство выражений в программах — получится, что там регистров-то надо совсем немного. > Как-то так :)). Хотя-бы по поводу того что мега-у...ще стало просто у...щем. > Улучшение, как ни крути :). ну да: прикрыли голову — ноги голые.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	126. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 03:58
	> в булочную за углом сбегать. Ну если тебе только в булочную, типа старта vim и тетриса, а в другой город совсем никак и никогда - ок, тогда да, может тебе 64 бита и излишни. Это однако не отменяет того факта что современные процы напрочь 64-битные и 64 бита становятся дефолтной архитектурой, с выносом 32 битов в легаси. Примерно как сейчас почти никому не приходит в бошку писать 16-битный код под х86. > нет, задолбало пихание 64-битности во все дыры. Сдох ваш бобик. На серверах - давно. А теперь и на десктопах, ибо объем памяти на типовом десктопнике и даже многих ноутах уж давно перевалил за 4Гб. Поэтому 32-битный х86 обречен стать легаси. И становится. Те же криптографы при дизайне новых алгоритмов стали часто ориентироваться на эффективность алгоритмов на 64-битных регистрах. А на 32-битных - по остаточному принципу, т.е. компилер конечно как-то разопрется проделать 64-битные вычисления оптом и на полутора куцых 32-битных регистрах. Но по скорости просядет. В несколько раз. Вот такая нынче правда жизни. > и да, x32 придумывали не просто так, например. Как по мне все это х32 - страдание фигней. Судя по тому как на х32 все дружно положили кроме пары гентушников - не один я так считаю. Вообще, нагревать себя на плюсы 64 битов, коли они уж есть - дурь несусветная. > потому что большинству софта не нужно больше нескольких гигов RAM, Даже если софт не вгружает несколько гигз данных в RAM (хотя я не вижу почему мне например должно быть нельзя вкатить в графический редактор реально большой файл, etc если физически памяти хватает) - есть еще например memory-mapped файлы. И совсем не комильфо их обрубать величиной несколько гигз. > а на указатель всё равно будь любезен потратить 64 бита. За счет относительной адресации - ряд сущностей вполне можно адресовать относительным смещением, скостив число указателей. А когда программа не может адресовать всю доступную память по человечески - это defective by design, извините. Если потребление памяти какой-то программе надо жестко залимитировать, в системах нынче есть более приличные рукоятки. > а чо, не жалко, памяти же много! где-то я такое уже видел… Ну как бы соотношение efforts/results должно быть разумное. Основной объем памяти в системах обычно занят отнюдь не указателями, так что экономия плюс-минус пары метров на всю систему при том что это будет достаточно глобально икаться там и тут, в виде невозможности отпроцессить вон тот большой кус данных вгрузив в память или обкоцывания mmaped файлов - да нафиг надо такие извращения. > памяти досыпьте, не жмотьтесь!» На самом деле, 64-битные программы кушают не сильно больше 32-битных. > я на своих 4gb так и работаю, кстати. при этом у меня > запущена куча софта, собирается немало кода с кучей шаблонов и CTFE… > и «в среднем по больнице» где-то гиг памяти свободен. А я вот тут активно пересобираю линевый кернель и осознал все плюсы хренадцати гигз. Более-менее разлапистый конфиг с дебажной информацией может в сумме генерить сотни мегз записей на диск и читать чуть ли не гигабайтами. И знаешь, хорошо все-таки когда при этом cache hit случается и не вымывается какое-нибудь оглавление разлапистой иерархии. Так даже механический диск может работать с "около-SSDшной" скоростью большую часть времени. > от этого раздуваются структуры данных и сколько новых матюгов они от > этого изобрели. Хз, знаю энное количество игроделов и на моей памяти никто из них не высказывал никаких особых претензий к х86-64. А основной объем у них занимают отнюдь не указатели, а ресурсы, пардон. Вес которых вообще не зависит от битности системы. > да и не только игроделы, в принципе… Да, да, расскажи нам как любители mmaped файлов относятся к идее обрубить виртуальное пространство. Слушаю с нетерпением. > классно тебе. и раздувания структур данных тоже не заметишь. Ну да, как-то так. Просто потому что указатели явно не занимают существенный процент памяти системы. А у какого-нибудь дискового кэша основной статьей расхода будут сами кэшированные данные, etc. > а вот многие другие — замечают. поэтому, например, попытались придумать x32. А mmaped файлы там тоже обрублены до 2^32, да? Ну или как адресовать больше при 32-битных указателях? > мусорятся влёт. и их надо или перезагружать, или сначала сохранять, а > потом перезагружать. привет, неявный стек! Регистры мусорятся, но еще, знаешь ли, старые результаты вычислений иногда перестают быть нужными. И тогда регистры можно реюзать без сохранения и перезагрузки, просто снеся содержимое которое больше нигде использоваться не будет. И чем регистров больше - тем чаще можно будет все обтяпать в этих регистрах, не занимаясь их перегрузкой. Так что я всецело поддерживаю идею донавесить регистров и расширить их битность. Хуже не станет, а вот лучше - запросто. >> А у x86 даже и убрать нельзя - изначально нету. > есть, есть. Меньше чем у x86-64. > хотя их несимметричность раздражает. И битность меньше. В общем нафиг. У...щнее х86 по архитектуре я знаю лишь 1 систему команд - Microchip PIC. Но этот гаденыш маленький, ему еще хоть как-то простительно. Правда я этот тип гаденышей по этой причине программить никогда не буду. > ага. умные современные компиляторы тоже не занимаются таким: они просто выделяют стековый > фрэйм и запихивают туда данные при помощи mov. А это кто как. Лениво лезть в асмовые листинги, но насколько я помню, ABI с передачей в регистрах вполне активно пользуются. > реальный выигрыш — это какая-то, например, математика по массивам с кучей измерений. Или криптография например. Хеширование, шифрование. Обработка мультимедийных данных. А то что ты упоминаешь, нынче модно выгружать на GPU. Там обычно невъ....ное количество регистров, целыми блоками, широких по битности. Ряд команд могут за 1 присест сделать одинаковые трансформации над субкомпонентами регистров, рассмотрев регистр не как 1 широкое число а как пачку более коротких чисел (особо массовый вариант SIMD). И блоков выполнения стоит 100500 штук. Потому оно 3D и долбит с такой скоростью... но если там вдруг не 3D а какие-то иные данные, оно совсем не возражает и их так же раздолбить, ALUшкам не принципиально что там. По поводу чего ускорение на GPU и является модной темой. Многие алгоритмы там вставляют системному процессору в десятки раз. Но ececution flow control там обычно слабый - это не general purpose проц. > и то во многих случаях компилятор «раскрутит» циклы и будет использовать > один-два регистра для адресации. Тем не менее, кашу маслом не испортишь. В смысле, избыток регистров - не недостаток, хуже не станет. Если бюджет по транзисторам позволяет. А нынче он более чем. > это не отменяет костыльности. Мир вообще не идеален. Своп на HDD вон тоже дикий костыль. Но некоторые до сих пор пользуются. > конечно. эти костыли с древних времён тянутся, когда вообще всё печально было. Ну вон у некоторых GPU насколько я понял регистры == локальная память/кэш, измеряется в килобайтах. Правда как ты заметил, компилер справится и без таких наворотов и не так уж и сильно продует. А програмер задолбается трекать тысячи регистров и может проcpaть компилеру в глобальной оптимизации. > нечто похожее в 6502, кстати. Не сильно похожее. Мнемоника команд интелообразная. Называлось сие 80C166 (C167...169 etc). Какая-то вполне самобытная архитектура от инфиньoна/cимeнса (не знаю уж, лицензировали они ее у кого или сами сделали). > не совсем, но адресовать первые 256 байтов там достаточно удобно, > их и использовали как «дополнительные регистры». Я в курсе что есть 6502 и имею отметить что невозможность использовать часть режимов адресации на части памяти - анноит, а "дополнительные регистры" по возможностям не идут ни в какое сравнение с аккумулятором. Если делать 6502 по человечески, на современном уровне - получится ARM. > что в регистрах мусор и весело загружать их заново. чем больше > регистров — тем больше и загружать. Не так уж и много. Локальных регистров под счет все-таки ограниченное количество. > я ж говорю: выигрыш в основном в том, что для компилятора выражений > доступно больше «быстрых хранилищ», Да и при программировании вручную как-то удобнее просто реализовать алгоритм чем мудoxaться с техническими перегрузками по причине "регистров не хватило". И вообще, попробовав использовать какую-нибудь логичную и симметричную систему команд типа ARMовской, да с кучей регистров - от х86 будет тошнить и это не лечится. Уроды типа х86 в основном по душе тем кто слаще морковки ничего не ел. В х86-64 это стало хоть немного походить на нормальные процессоры. > сброс регистров на узле ветвления. и если посмотреть на большинство выражений > в программах — получится, что там регистров-то надо совсем немного. Весьма зависит от программ и чего они хотели. Какой-нибудь алгоритм шифрования или хэширования может запросто интенсивно ворочать пачку 64-битных переменных. При этом x86 разумеется будет в пролете с его полутора куцыми 32-битными регистрами. Это же касается и всяких кодеков и прочих (этим правда больше в кассу SIMD, и тут гарантированный SSE2 оказывается очень кстати). > ну да: прикрыли голову — ноги голые. Ну, блин, приди и покажи этим лохам как надо процы делать. Я теперь на это по крайней мере могу смотреть не сблевывая прямо сразу.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	141. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 05:36
	> Ну если тебе только в булочную, типа старта vim и тетриса, а > в другой город совсем никак и никогда - ок, тогда да а ещё типа всяких компиляторов, например. впрочем, всякие невменяемости типа файрфоксов не собираю, конечно. > Сдох ваш бобик. На серверах - давно. рад за сервера. только меня это не волнует — ну, разве ты мне толстый красивый сервер подаришь. > ибо объем памяти на типовом десктопнике и даже многих ноутах уж > давно перевалил за 4Гб. а на многих — нет. > Те же криптографы дорогой. ты так говоришь, как будто у тебя на x86 криптография 140% CPU сжирает. у меня вон cjd, где сплошное шифрование, даже процента не может. в 32-х битах. > Как по мне все это х32 - страдание фигней. а как по мне, так страдание фигнёй — 64-битные указатели там, где они нафиг не упёрлись (то есть, в подавляющем большинстве «десктопного» софта). > Вообще, нагревать себя на плюсы 64 битов, > коли они уж есть - дурь несусветная. ну да, неиспользованная половина указателя — это плюс. без сомнения. > еще например memory-mapped файлы (напряг память) упс. что-то за последние пять лет не могу вспомнить случая, когда мне надо было замапить десятигиговый файл. >> а на указатель всё равно будь любезен потратить 64 бита. > За счет относительной адресации - ряд сущностей вполне можно адресовать относительным смещением это всё здорово, ты это компилятору расскажи. пусть он «адресует относительно», когда в структурах указатели лежат, угу. я хочу это видеть: как поможет относительная адресация в таком случае? > А когда программа не может адресовать всю доступную > память по человечески - это defective by design, извините. ещё раз: подавляющему большинству «десктопного» софта это нафиг не надо. а оверхэд на размер указателя пихают всем. > Ну как бы соотношение efforts/results должно быть разумное. Основной объем памяти в > системах обычно занят отнюдь не указателями, так что экономия плюс-минус пары > метров на всю систему угу-угу. у тебя там что, одно ядро и init запущены, что ли? > На самом деле, 64-битные программы кушают не сильно больше 32-битных. ровно до тех пор, пока там не появляются разлапистые структуры со сложными связями. > А я вот тут активно пересобираю линевый кернель и осознал все плюсы > хренадцати гигз. а мне и моих хватает. шесть минут — и всё собрано. > Более-менее разлапистый конфиг но зачем? один раз настроил под своё железо — и всё. > Хз, знаю энное количество игроделов и на моей памяти никто из них > не высказывал никаких особых претензий к х86-64. я про игроделов, а не про клепателей говна на юнитях и анрылах. впрочем, таких действительно очень мало осталось. > Да, да, расскажи нам как любители mmaped файлов относятся к идее обрубить > виртуальное пространство. Слушаю с нетерпением. расскажи мне, зачем на «десктопе» ворочать такие файлы? >> классно тебе. и раздувания структур данных тоже не заметишь. > Ну да, как-то так. Просто потому что указатели явно не занимают существенный > процент памяти системы. как вылезешь из контроллеров и попадёшь в мир, где динамические структуры и сборки мусора — твоё мнение может сильно поменяться. > А mmaped файлы там тоже обрублены до 2^32, да? и что? тебе что, видео процессить? так это уже не «десктоп», пардон. > Ну или как адресовать больше при 32-битных указателях? как и раньше — обрабатывая файл чанками. правда, не ясно, зачем. > Регистры мусорятся, но еще, знаешь ли, старые результаты вычислений иногда перестают быть > нужными. И тогда регистры можно реюзать без сохранения и перезагрузки, просто > снеся содержимое которое больше нигде использоваться не будет. таки да. прикинь, для x86 тоже так можно. > И чем регистров > больше - тем чаще можно будет все обтяпать в этих регистрах, > не занимаясь их перегрузкой. интересно было бы посмотреть на статистику: сколько в среднем регистров на выражение идёт в том же gcc и как часто он их сохраняет на x86. эмпирически я подозреваю, что совсем нечасто. но плугин делать лень. алсо, я не против того, чтобы регистров было больше. я против того, чтобы вместе с этим и указатели раздувались, например. да, я активно использую динамические структуры. да, мне лишние байты — это cache misses. >> ага. умные современные компиляторы тоже не занимаются таким: они просто выделяют стековый >> фрэйм и запихивают туда данные при помощи mov. > А это кто как. сказано для си на стеке — значит, на стеке. оптимизировать сие можно только если функции в одном модуле, приватные и межпроцедурная оптимизация включена. иначе обломинго. возможно, ещё LTO может помочь — но опять же: не для библиотек, которые в основном собраны без LTO-секций. да и делать это при сборке, теряя 100500 времени и выигрывая аж десяток миллисекунд на исполнении… > Да и при программировании вручную как-то удобнее просто реализовать алгоритм чем мудoxaться > с техническими перегрузками по причине "регистров не хватило". а ещё лучше пнуть компилятор, пусть он этим занимается. всё равно есть нехилая вероятность, что компилятор лучше код соптимизирует для современных мультикоровых кисков. > кучей регистров - от х86 будет тошнить и это не лечится. да разве ж я говорю, что у x86 хорошая система команд? я ещё лет 15 назад говорил, что x86 надо закопать и охрану поставить, чтобы назад лопатой загонять, если попытается выбраться. > Ну, блин, приди и покажи этим лохам как надо процы делать. армовцы уже, собственно. хотя и они со своими тумбочками в опасном направлении идут.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	148. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Xasd (ok) on 30-Июн-14, 09:36
	> да, я активно использую динамические структуры. да, мне лишние байты — это cache misses. ну используешь -- молодец, используй. тебе 64-бита (размер указателей) ни как не мешает использовать динамические структуры. > алсо, я не против того, чтобы регистров было больше. я против того, чтобы вместе с этим и указатели раздувались, например. длинный указатель -- да -- а тебе что завидно чтоли? завидуешь что указатель длинный, а у тебя достоинство -- короткое? :-) длинный указатель вполне хорошо умещает внутри себя любой адрес. а если ты из тех людей кто экономит на спичках и в результате чего бывает что внутри базы данных нехватает буков чтобы записать редкие имя и фамилию ---- то тебе можно лишь разных мук пожелать. :-) НАГЛЫЙ ТЫ ЭГОИСТ, процессоры (x86_64) предназначены НЕ ТОЛЬКО ДЛЯ ТВОИХ программ, а для универсальных целей! и если лично тебе длинные указатели ни как не помогают (но и не мешают! заметь) то учти что есть и программы не только тобой написанные, а например нормальными программистами.. если лично ты не используешь mmap, то другие его использовать хотят (но им мешает i686, который не умеет делать mmap больших файлов, поэтому приходиться разрабатывать алгоритмы без mmap). терпеть не могу людей который экономят на спичках.. ты своей экономей на спичках выиграешь максимум 7% производительности (если сделаешь указатели более короткие чем 64-бита, как например в x86_x32) но при этом невероятно испортишь жизнь всем остальным программистам, нервы все истрепишь! если например я не ем хлеб, то я НЕ ору "я не ем хлеб! давайте позакрываем все хлебные ларьки, и построим вместо них чего-нибудь нормальное!! давайте БЫСТРЕЕ срочно позакрываем хлебные ларьки! нет необходимости в хлебе, потому что я не ем хлеб! я не ем хлеб уже 5 лет и совсем не жалуюсь.." если нет тебе необходимости в длинным размере 64-битных указателей -- то просто НЕ ИСПОЛЬЗУЙ приемущества длинных указателей. не надо пытаться говорить что они глупые. просто ЛИЧНО ТЕБЕ это не нужно. а некоторым людям даже и компьютер не нужен -- и что?
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	163. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 15:21
	> а ещё типа всяких компиляторов, например. А вот компилятор при работе с механическим диском (протереть дырку в SSD за неделю в мои планы не входит) как-то бурно радуется cache hit на больших иерархиях. Cache hit vs cache miss для диска при -j 8 видно просто на глаз: по нагрузке на проц. Если hit - все 8 ядер прогружаются и вкалывают по максимуму. Если miss - все часто упирается в чтение или запись на диск, проц половину времени курит бамбук. > впрочем, всякие невменяемости типа файрфоксов не собираю, конечно. А линевый кернель как по твоей классификации, например? При сборке в 8 потоков оно запросто упирается в I/O временами. И могучий проц в этом случае курит бамбук. Зато при cache hit процам есть чем заняться и процесс сильно ускоряется (почти по числу ядер). > рад за сервера. только меня это не волнует Ну а у меня и десктоп давно перевалил за 4Гб, т.к. я все-таки могу позволить себе наконец насладиться быстрым компьютером, который я жду а не наоборот только в каких-то особо эксклюзивных случаях, когда работенки реально много. Большой дисковый кэш здорово улучшает поведение системы. При этом можно использовать емкие но тормозные механические диски под данные, не очень страдая от их тормозизма (который после SSD, скажем прямо, выбешивает без такого костыля). > а на многих — нет. А это их проблемы и меня они не интересуют. Так что мы с тобой квиты :). > дорогой. ты так говоришь, как будто у тебя на x86 криптография 140% CPU сжирает. А это сильно зависит от того что и как делать. > у меня вон cjd, где сплошное шифрование, даже процента > не может. в 32-х битах. Это прекрасно, но тут все еще от траффика зависит. Попробуй напрмер гигабит траффа шифровать и хэшировать. Или запись на диск, со скоростью типовой для SSD? Не вижу почему шифрование на скорости I/O надо считать за роскошь. И в этом случае прирост в несколько раз или уменьшение использования проца в несколько раз - вполне себе сойдет за плюс. > а как по мне, так страдание фигнёй — 64-битные указатели там, где > они нафиг не упёрлись (то есть, в подавляющем большинстве «десктопного» софта). Нынче не так уж мало программ использует те же mmaped-файлы, например. > ну да, неиспользованная половина указателя — это плюс. без сомнения. Все должно быть в меру. "If you optimize everything, you will always be unhappy." (ты имхо в курсе кто это сказал). Спору нет, раньше, когда давились за каждый байт, писать дрова на си было пижонством. И писали на асме. Ну как VxD в win3.x/9x и драйвера DOS. Вот только код получался прибит гвоздями к 1 архитектуре да и выглядел жутковато. Но оптимальность была на высоте. Но почему-то никто не хочет сейчас так дрова писать... > когда мне надо было замапить десятигиговый файл. Тебе - возможно. А с чего ты взял что мир заканчивается на тебе и твоих задачах? С более-менее генерализованной програмерской точки зрения, более-менее можно уповать что за 2^64 объем обрабатываемых данных скорее всего не перевалит. А вот насчет 2^32 это нынче уже совсем не факт. А mmaped файлы - достаточно generic сущность и используеся кучей разных программ. > поможет относительная адресация в таком случае? А никак. Почему ты думаешь что все оптимизации должны работать во всех 100% случаев? А можно вообще сказать asm, разбавить сотней-другой NOPов в каждом цикле (а то вдруг случайно получится удачный код?) и жестко заколотить адреса. Тогда этот гадский компилятор уж точно не сможет заоптимизировать. Мало ли зачем ты в адрес 0x100500 напрямую лезешь... > ещё раз: подавляющему большинству «десктопного» софта это нафиг не надо. В моей системе я сам решаю что мне надо. И экономия на указателях чтобы сэкономить пару мегов на всем коде в системе - это, конечно, круто, но проще 1 значок на питоне вышибить и за 1 присест сразу 20М расчистить. Пока там на указателях 20M отыграешь - на горе рак задолбается свистеть. > а оверхэд на размер указателя пихают всем. И фиг с ними: указатели не основная статья расхода памяти в таких системах. > угу-угу. у тебя там что, одно ядро и init запущены, что ли? Нет, но указатели явно не являются основной статьей расхода памяти на системе с 16 гигз. Основная часть памяти как правило дисковый кэш. К которому это бла-бла про указатели не относится чуть менее чем никак. Но при необходимости программы могут и откусить оттуда пяток гигз под какие-то временные нужды, если надо. > ровно до тех пор, пока там не появляются разлапистые структуры со сложными > связями. В большинстве виденных программ на практике разница не превышала 20-30%. И да, знаешь, мне совсем не очевидно почему надо отлупить графический редактор с его запросом в несколько Гб памяти, если они есть а я возжелал открыть странный битмап размером 100500 на 100500. Мне кажется логичным когда возможности программ ограничены только физически доступными ресурсами, а не какой-то побочной муитой. > а мне и моих хватает. шесть минут — и всё собрано. Ну я собираю много и часто. И не такие обрубочные конфигурации как у тебя, видимо (хотя зависит от того для чего это ядро). И с дебагом к тому же. Он жирный, хоть и не тролль. > но зачем? один раз настроил под своё железо — и всё. Во первых, для меня нормальная практика раскидать результат компила на несколко машин - весьма зависит от того что и по какому поводу собиралось. У машин разное железо, прикинь? И это не я 1 такой ленивый - сейчас вон на ARM ресурсы стали позволять - так теперь универсальные ядра способные бутявить разные ARMовые девайсы - во все поля. Потому что задолбало всех по 20 разных ядер собирать. Во вторых меня не прет идея пересобирать все когда я воткнул в usb энный девайс. а для него драйвера не оказалось, etc. Если машина в фоне попашет лишние 5 минут - фиг с ним. А если жареный петух укусит когда надо прицепить "вот этот девайс" и придется 5 минут заниматься тyповэйтингом - это уже булшит. > я про игроделов, а не про клепателей гoвна на юнитях и анрылах. Про юнити и анрылы я ничего не знаю, тебе виднее. > впрочем, таких действительно очень мало осталось. Я и от тех кто самопальные движки делает не слышал особой ругани по этому поводу. А тыкание палочкой обычно показывает что основную массу кушают ресурсы, если их качество не полное г-но. Потому что чтобы не тормозило - стараются буферизовать в RAM по максимуму. Логично же что самый прямой и быстрый способ доступиться - напрямую сунуться и поюзать. > расскажи мне, зачем на «десктопе» ворочать такие файлы? Потому что бла-бла про то что 640Кб (или 4Гб) хватит всем - несколко задолбало. У меня есть файлы сильно поболее 4 гигз. Парочка примеров: есть например нежатое видео на 30Гб для тестов кодеков. Или вон 12Гб данных в плотно скомпрессованом формате OSM - обычные такие планетарные данные. > как вылезешь из контроллеров и попадёшь в мир, где динамические структуры и > сборки мусора — твоё мнение может сильно поменяться. Я в состоянии мониторить расход памяти в моей системе и имею отметить что 20-30% от меньшей части памяти системы - не такая уж и страшная величина. И пристрелить пару значков на питоне или закрыть пару вкладок в браузере куда результативнее на предмет расчистки памяти получается: в 10 раз меньше усилий при в 10 раз более интересном результате. > и что? тебе что, видео процессить? так это уже не «десктоп», пардон. То-есть если я нежатый 30Гб файл отдаю кодеку, чтобы посмотреть как он сожмет, без загаживания результатов предыдущим сжатием и как это соотнесется с другими кодеками - я от этого становлюсь сервером чтоли? Или суперкомпьютером? А если я качнул 12-гиговый планетарный файл OSM, то что? И кстати при выборках/конверсиях из оного опять же cache hit в дисковые буфера все сильно ускорит. > как и раньше — обрабатывая файл чанками. правда, не ясно, зачем. Весь пойнт mmap в том чтобы просто, быстро и логично работать с файлами. А опрационка сможет это на свое управление памятью достаточно эффективно натянуть в лучшем случае. И намного проще, удобнее и быстрее (в плане файловых операций) если желаемое будет делаться влобовую, а не с таким кластерфаком. Извини, Кэп, но я в свое время вволю наелся банков, сегментов и какой там еще костыльной *дряни*. Н-Е-Н-А-В-И-Ж-У. Даешь линейные адресные пространства, где можно просто сделать то что было надо и не трaxaть мозг дурными техническими ограничениями "потому что вон там 200 транзисторов сэкономили (из миллиарда, б@#!!!)". Кстати мне за это из контроллеров нравятся Cortex-M. Как правило там хватает адресов на то чтобы все и вся было одним линейным адресным пространством. Без клевания мозга банками, сегментами и прочими радостями там где этого хотелось бы меньше всего на свете. > таки да. прикинь, для x86 тоже так можно. Только такое счастье наступает редко, в силу куцего регистрового файла. > интересно было бы посмотреть на статистику: сколько в среднем регистров на выражение > идёт в том же gcc и как часто он их сохраняет на x86. эмпирически > я подозреваю, что совсем нечасто. но плугин делать лень. Ну я так, грубо прикинул, на основе смотрения в ассемблерный коды из иды в свое время, х86 программы какие-то наиболее пуш-попистые из того что мне попадалось. Не доставляет. Гомно а не архитектура. И даже без фантика. > алсо, я не против того, чтобы регистров было больше. я против того, > чтобы вместе с этим и указатели раздувались, например. да, я активно > использую динамические структуры. да, мне лишние байты — это cache misses. Ну это какие-то твои специфичные проблемы. Поскольку я не ты и у меня нет твоих программ - меня это не сильно напрягает. > сказано для си на стеке — значит, на стеке. оптимизировать сие можно > только если функции в одном модуле, А как насчет LTO с -fwhole-program? > возможно, ещё LTO может помочь — но опять же: не для библиотек, Ну да, для динамических библиотек не поможет. Там вместо этого менее дурное ABI будет :). > которые в основном собраны без LTO-секций. да и делать это при > сборке, теряя 100500 времени и выигрывая аж десяток миллисекунд на исполнении… Еще LTO может чуть ли не четверть кода в большом проекте у...ть. Так что если кто др... на TLB и прочее - ему должно понравиться :). > а ещё лучше пнуть компилятор, пусть он этим занимается. всё равно есть > нехилая вероятность, что компилятор лучше код соптимизирует для современных > мультикоровых кисков. От кода сильно зависит. Почему-то писаный человеками хардкорный MMXно-SSEшный ASM в всяких там видеокодеках делает по скорости тот шит который генерит компилер буквально в разы. Человек кукует с глобальной оптимизацией, но локально может очень сильно уделать компилер. А так - на вот тебе бонус! Я из интереса померял LZ4, просто потому что "халява попалась". Автор предусмотрел бенчи, да еще 32 и 64 в одном флаконе, как раз то что надо. Я не поленился вкатить пару 32-битных либ - получилось как-то так: http://pastebin.ca/2816804 Внимание, вопрос: почему 64-битная версия LZ4 делает 32-битную в абсолютно всех бенчмарках? Невзирая на 64 бита в указателях (которые там используются более чем активно). Железо и компилер одно и то же, единственное отличие в -m32 для сборки 32-битной версии. > армовцы уже, собственно. хотя и они со своими тумбочками в опасном направлении идут. А чего не так с тумбочками? Если это про thumb. Вроде thumb2 получился очень симпатично - сэкономили прилично битов в потоке команд на условном выполнении, не потеряв его а лишь сделав чуть менее гибким (учитывая что условным выполнением вообще каждой команды мало кто пользовался - никаких особых неудобств это не вызывает, а вот битов в потоке команд экономит прилично).
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	180. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 01-Июл-14, 00:14
	>> а ещё типа всяких компиляторов, например. > А вот компилятор при работе с механическим диском (протереть дырку в SSD > за неделю в мои планы не входит) как-то бурно радуется cache > hit на больших иерархиях. а у меня вот всё вовсе не в диск упирается. disk i/o там какие-то доли процента от общего времени. > А линевый кернель как по твоей классификации, например? а смотря какой. если «универсальный конфиг» — то тоже невменяемый монстр. everything but the kitchen sink, и 90% из этого никогда не понадобится. > Ну а у меня и десктоп давно перевалил за 4Гб, извини, но у тебя не «десктоп». у тебя как минимум «девелоперская станция» — это уже совсем другой класс. и дальше — я поскипаю, потому что ты ведёшь речь про «девелоперскую станцию», но называешь её «десктоп». я понимаю, что чётких определений у этих терминов нет, так что ты в своём праве. но мы таким образом никогда не договоримся, потому что про разные вещи говорим как про одну. > Нынче не так уж мало программ использует те же mmaped-файлы, например. и очень мало — размерами в кучу гигабайт. «десктоп», эй. «фкантактег», «фэйсбук», «ютуб», «твиттер», «джастинбибер», «фонтриергений», «какиесиськи!» >> ну да, неиспользованная половина указателя — это плюс. без сомнения. > Все должно быть в меру. именно. бессмысленное раздувание указателей — не в меру. > Тебе - возможно. А с чего ты взял что мир заканчивается на > тебе и твоих задачах? потому что даже мой нетипичный «десктоп» в этом не нуждается. более типичный «десктоп» — тем более. >> поможет относительная адресация в таком случае? > А никак. Почему ты думаешь что все оптимизации должны работать во всех > 100% случаев? ну, это же ты начал речь про относительную адресацию. вот я и пытаюсь понять, к чему ты это сказал: просто так, или с каким умыслом тайным. >> ровно до тех пор, пока там не появляются разлапистые структуры со сложными >> связями. > В большинстве виденных программ на практике разница не превышала 20-30%. это *много*. очень много. > Ну я собираю много и часто. И не такие обрубочные конфигурации как > у тебя, видимо (хотя зависит от того для чего это ядро). лично у меня — для работы. вот оно, самосборное — прямо сейчас трудится, помогает мне ответ писать. >> но зачем? один раз настроил под своё железо — и всё. > Во первых, для меня нормальная практика раскидать результат компила на несколко машин > - весьма зависит от того что и по какому поводу собиралось. и они все настолько разные, что уменьшить ядро никак. ага. и отчего я не удивлён, что тебе на ресурсы плевать? > Во вторых меня не прет идея пересобирать все когда я воткнул в > usb энный девайс. а для него драйвера не оказалось, etc. Если > машина в фоне попашет лишние 5 минут - фиг с ним. > А если жареный петух укусит когда надо прицепить "вот этот девайс" > и придется 5 минут заниматься тyповэйтингом - это уже булшит. причём ситуация такая наверняка случается от силы раз в месяцев пять-шесть, за которые ты кучу раз ядра пересобираешь. то есть, снова куча бесполезной работы. почему я опять не удивлён? слушай, а ты это… может, ты питонистам просто завидуешь, потому что они ещё круче умеют ресурсы разбазаривать? >> на «десктопе» >нежатое видео на 30Гб для тестов кодеков типично «десктопная» задача, угу. каждый день вижу пользователей, которые это делают. регулярно, утром и вечером. >> интересно было бы посмотреть на статистику: сколько в среднем регистров на выражение >> идёт в том же gcc и как часто он их сохраняет на x86. > Ну я так, грубо прикинул, на основе смотрения в ассемблерный коды из > иды в свое время, х86 программы какие-то наиболее пуш-попистые из того > что мне попадалось. с тех пор оптимизаторы научились разным гитикам. я, кстати, push/pop в коде вижу весьма редко, в основном там, где тупой кодогенератор напрямую преобразовывает стековую VM. так такой на любом процессоре одинаково нагенерит. > Еще LTO может чуть ли не четверть кода в большом проекте у...ть. или линкер, как происходит у меня. надо бы, конечно, как-нибудь разобраться, что там не так собрано, но лень. > Так что если кто др... на TLB и прочее - ему должно понравиться :). указатели из структур оно всё равно не выметет, потому что права не имеет. > От кода сильно зависит. Почему-то писаный человеками хардкорный MMXно-SSEшный ASM в всяких > там видеокодеках делает по скорости тот шит который генерит компилер буквально > в разы. ну да, мы же гордые, мы же компилятору помочь симдовыми интринсиками не хотим, потому что «непортабельно». асм зато офигеть портабельный в итоге получается. > бенчи ну, ты понял, да? > Внимание, вопрос: почему 64-битная версия LZ4 делает 32-битную в абсолютно всех бенчмарках? потому что какой-то дятел запускал её в 64-битном окружении? > единственное отличие в -m32 для сборки 32-битной версии. хоть бы ради приличия на 32-битной системе проверял. ну, и с -march=native, -mtune=native хотя бы. > А чего не так с тумбочками? Если это про thumb. Вроде thumb2 > получился очень симпатично - сэкономили прилично битов в потоке команд на > условном выполнении, не потеряв его а лишь сделав чуть менее гибким проблема в том, что когда люди начинают уродовать систему команд — они обычно уже не могут остановиться. это помимо того, что дополнительный режим усложняет всё остальное. ты сам можешь найти железо и аппараты, где тумбочки или вообще нельзя было использовать из-за багов, или приходилось делать workaround-ы. один такой аппарат у тебя точно есть.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	184. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 01-Июл-14, 03:02
	> а у меня вот всё вовсе не в диск упирается. disk i/o > там какие-то доли процента от общего времени. У тебя или очень крутые диски, или хилый проц. > а смотря какой. если «универсальный конфиг» — то тоже невменяемый монстр. > everything but the kitchen sink, и 90% из этого никогда не понадобится. Как тебе сказать? Ну и пусть себе не надобится. Плюс-минус пара мегабайтов модулей мне на десктопе жить не мешает, они даже не грузятся в RAM если обслуживаемой ими железки нет. А вот самолично тыкать операционки в драйвера я зае... еще в эпоху доса и нт4, поэтому теперь у меня будет plug-n-play. Машине таки виднее что там на шинах прицеплено. > извини, но у тебя не «десктоп». у тебя как минимум «девелоперская станция» Нынче даже нотики с менее чем 4 гигз редко попадаются, RAM дешевый и нагревать себя на скорость работы системы за счет свопления - не оправдано. > — это уже совсем другой класс. и дальше — я поскипаю, Это именно десктоп. Самый обычный. Уже несколько лет как на типовом компе из магазина 4Гб и более. Меньше ставить уже просто неприличным считается. Ну разве что на офисные печатные машинки, где сэкономлено на всем и вся. > договоримся, потому что про разные вещи говорим как про одну. Ты просто не замечаешь что закон Мура никуда не делся и тикает. Поэтому вчера у десктопа нормой было 8Мб. А сегодня - 8Гб. И нет, далеко не каждый компьютер с 8Гб - машина разработчика. Половина - обычные домашние десктопники, у юзверей. Прикинь? Даже тормозной MS нынче 64-битные оси по дефолту впаривает. А 32-битные - по остаточному принципу, на особо бомжовские конфигурации. > «фэйсбук», «ютуб», «твиттер», «джастинбибер», Да, а ты попробуй в хроме каком-нибудь все это открыть. Это добро спокойно сожрет 8 гигз и не подавится, я как-то раз попробовал - офигел от внезапного OOM :). > именно. бессмысленное раздувание указателей — не в меру. Ретроградство/тормозизм - вот это не в меру. Экономить 4 байта, нае... себя на возможность адресации всей памяти в системе - маразм. > более типичный «десктоп» — тем более. А теперь просто разуй глаза и посмотри чего продается в ларьках как десктопы. И операционка там 64-битная. > пытаюсь понять, к чему ты это сказал: просто так, или с > каким умыслом тайным. Просто кивнул на улучшение архитектуры относительно х86, позволяющее местами обставлять оный в некоторых ситуациях. И если честно, архитектура без относительной адресации - это "совсем гoвнo". Хотя в тех случаях которые ты упоминаешь относительно адресоваться не будет. > это *много*. очень много. Ну вот кому это много - тот пусть и др@чится с работой с mmaped файлами кусочками и прочее. > лично у меня — для работы. вот оно, самосборное — прямо сейчас > трудится, помогает мне ответ писать. Ну а вот я могу захотеть поработать с какой-нибудь железкой на USB и подрываться компилить драйверы "на соседний чип usb-uart" - мне как-то не с руки. Пусть лучше заранее лежит и будет вгружен на автомате при втыкании железки в разъем. > и они все настолько разные, что уменьшить ядро никак. ага. и отчего > я не удивлён, что тебе на ресурсы плевать? Да, Кэп, я занимаюсь оптимизациями лишь когда вижу в этом практический смысл. Если это сборка openwrt и надо влезть в 4 мега флеша - ОК, в этом случае будет оставлено по минимуму, то что реально надо. А оптимизация ради оптимизации? Пардон, на компил ядра время тратит машина, а на щелкание галочками - я. Мое время ценится выше машинного. > причём ситуация такая наверняка случается от силы раз в месяцев пять-шесть, Не отменяет того факта что это мне будет неприятно. Поэтому я за плагнплейность - нехай железяка сама разбирается что там на шинах висит. > за которые ты кучу раз ядра пересобираешь. то есть, снова куча бесполезной > работы. почему я опять не удивлён? Если я пересобираю ядра - на это были какие-то валидные причины. И время их компилежки для меня как правило не принципиально. Это не 5 секунд, поэтому оно всяко будет пахать где-то в фоне и я это видеть не буду. Плюс-минус несколько минут ничего фундаментально не меняют. Зато меня не постигнет облом при втыкании энной железки или перетряске оборудования. Мало ли какая железка померла/заменена/заапгрейжена/... - мне чего, ядра пересобирать каждый раз? Я тебе что, гентушник? > слушай, а ты это… может, ты питонистам просто завидуешь, потому что они > ещё круче умеют ресурсы разбазаривать? Не, я просто занимаюсь оптимизацией по ресурсам когда вижу в этом смысл. Экономить мег из 4Мб флехи в роутере - ок. Экономить мег из 80Гб места на SSD - а смысл? Там есть более простые и эффективные методы расчистить мег места, если он нужен. В роутере то эти методы недоступны, сам понимаешь. > типично «десктопная» задача, угу. Видео то компреснуть? :) Да обычная. И даже пожатое видео в HD может спокойно перевалить за 4 гига. > вижу весьма редко, Да ты наверное код в асмовом представлении не сильно часто читаешь. В большинстве случаев и без этого неплохо. Но это не отменяет того что х86 - редкое гуано, х86-64 все-таки несколько поприятнее стал, хотя я бы не сказал что предел мечтаний. > или линкер, как происходит у меня. LTO в фазе линковки и происходит... > указатели из структур оно всё равно не выметет, потому что права не имеет. Логично, но я как-то плохо себе представляю что надо делать на моей системе чтобы это стало основной статьей расхода оперативы и потому первым кандидатом на оптимизацию и обкусывание. > ну да, мы же гордые, мы же компилятору помочь симдовыми интринсиками не > хотим, потому что «непортабельно». асм зато офигеть портабельный в итоге получается. Если уж всяко непортабельно - на асме по крайней мере получается максимально забористый и полностью предсказуемый (покомандно!) результат. Максимально оптимальный и не зависящий от взбрыков кодогенератора конкретного компилера конкретной версии. Асм предмет простой - сказали эти команды, значит эти. > ну, ты понял, да? Да, я понял - я понимаю что и нафига забенчмаркано и делаю выводы насколько и что полезно. > потому что какой-то дятел запускал её в 64-битном окружении? За дятла можно ведь и ответить. Я ведь могу перезагрузиться в 32-битную систему с более-менее теми же версиями софта и пнуть 32-битный бинарь там. Но почему-то мне кажется что результат будет точно такой же. Просто потому что либы и так были 32-битные, а основное время оно проводит не в окружении а в своем коде как раз. > хоть бы ради приличия на 32-битной системе проверял. ну, и с -march=native, > -mtune=native хотя бы. Использовались стандартные флаги от автора либы из его makefile. Дописал. Прикол - скорость ... просела. И в 32 и в 64 битной версии. Вот те и "тюнинг". В 64-битном бинаре проседание сильнее чем в 32-битном, особенно на декомпрессии. Но даже так в половине тестов (все тесты сжатия) 64-битный бинарь 32-битного обставляет. А самый быстрый одинфиг бинарь без arch/tune, с дефолтными параметрами компила и 64-битный. Кэп, а это ведь не удивительно. Судя по всему - у автора система тоже 64-битная и автор видимо не хуже нас знал что делает. Поэтому чем ближе конфиг к авторскому, тем и... :-). > обычно уже не могут остановиться. это помимо того, что дополнительный режим > усложняет всё остальное. В мелких кортексах чаще всего только thumb2 и есть. И идея делать условное выполнение на группу команд смотрится как раз более логично: условное выполнение с гранулярностью по 1 команде редко востребовано, зато битики на это жpeт. Так что они это не сразу сообразили - бывают в жизни огорчения. > тумбочки или вообще нельзя было использовать из-за багов, или приходилось делать > workaround-ы. один такой аппарат у тебя точно есть. Я знаю о чем ты :). Но там есть воркэраунд. И да, errata бывают. У интелья этого добра тоже знаешь ли хоть отбавляй. А если в драйверах линя поискать по словам типа quirk - можно офигеть, там такого счастья всех мастей вагон. Вон ath9k - на 50% состоит из воркэраундов багов чипов, например :).
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	185. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 01-Июл-14, 03:38
	>> а у меня вот всё вовсе не в диск упирается. disk i/o >> там какие-то доли процента от общего времени. > У тебя или очень крутые диски, или хилый проц. старенький, да, корадвадуба на 3 ггц. я очень консервативен, и технику меняю с трудом. плюс — куча кода с шаблонной магией: основное время у компилятора уходит на раскрутку всяких шаблонов. нет, это не цпп. ;-) >> извини, но у тебя не «десктоп». у тебя как минимум «девелоперская станция» > Нынче даже нотики с менее чем 4 гигз редко попадаются, RAM дешевый > и нагревать себя на скорость работы системы за счет свопления - > не оправдано. ты меня не понял. различие между «десктопом» и «девелоперской станцией» не в том, какое там железо, а в том, какие задачи на технике крутит хозяин. >> «фэйсбук», «ютуб», «твиттер», «джастинбибер», > Да, а ты попробуй в хроме каком-нибудь все это открыть. да нормально открывается на четырёх гектарах. хотя, может, в новом хроме это уже починили — у меня весьма древний, я его запускаю только когда надо быстренько сбегать на какой-то вообще невменяемый сервис, где жабоскрип-хипстерам вовремя ломы в анусы не вставляли. > Ретроградство/тормозизм - вот это не в меру. Экономить 4 байта, нае... себя > на возможность адресации всей памяти в системе - маразм. у меня нет софта, которому надо более трёх гигабайт. и я не могу представить, зачем мне такой софт нужен. как и большинству пользователей. кстати, если у разработчиков отобрать «меготехнику с кучей гигов рам», то софт станет сильно лучше. а то я несколько офигеваю, вспоминая, с какой скоростью работал «the bat» на древнем 800-м пне, и как сейчас когтемыл по десять секунд иногда открывает письмо. при том что свободной RAM в системе — почти два гигабайта, так что я не знаю, чем он там занимается. потому что i/o тоже не особо дёргает при этом. >> это *много*. очень много. > Ну вот кому это много - тот пусть и др@чится с работой > с mmaped файлами кусочками и прочее. зачем ты кормишь компилятор портянками на 20 гигабайт? ;-) > Ну а вот я могу захотеть поработать с какой-нибудь железкой на USB > и подрываться компилить драйверы "на соседний чип usb-uart" - мне как-то > не с руки. дел-то… два пинка и две минуты, тьфу. при этом один раз. а собираются бесполезные драйвера каждый. неееет, вас таки надо пересаживать назад на 16 бит. а лучше на 8. > Да, Кэп, я занимаюсь оптимизациями лишь когда вижу в этом практический смысл. то есть, никогда почти. «а чего, пусть лохи технику помощнее покупают». знаю-знаю, жава. понимаешь, привычка класть на оптимизацию проявляется сама по себе. в итоге техника всё мощнее, а софт всё жирней и медленней. при этом никаких мегауберфич, которые бы оправдывали тормоза, он не приобретает. do not want. > Пардон, на компил ядра время тратит машина ну, если у тебя основное занятие — ядра собирать, тогда да. а мне, например, скучно наблюдать за сборкой, я в это время свой код попилить могу. зачем мне собирать уберядро с биотуалетом, если нужные модули я могу дособрать и позже, когда понадобятся? я отчего-то уверен, что ты не тыкаешь каждые пять минут новую железяку, для которой новые драйвера нужны. >> причём ситуация такая наверняка случается от силы раз в месяцев пять-шесть, > Не отменяет того факта что это мне будет неприятно. Поэтому я за > плагнплейность - нехай железяка сама разбирается что там на шинах висит. так ядро пожалуется, что видит грушу, а скушать не может. и какую именно. > Мало ли какая железка померла/заменена/заапгрейжена/... - мне > чего, ядра пересобирать каждый раз? Я тебе что, гентушник? ну да, у тебя же ядро по часу собирается. а у меня — пять минут. с нуля. поэтому ты панически боишься пересобрать ядро, если что-то изменилось, а я — нет. > Не, я просто занимаюсь оптимизацией по ресурсам когда вижу в этом смысл. вот и питонисты то же самое говорят. один-в-один. и чего ты их так не любишь-то? братья же практически. >> вижу весьма редко, > Да ты наверное код в асмовом представлении не сильно часто читаешь. да, не каждый день. тем не менее, читаю. по необходимости, увы. >> или линкер, как происходит у меня. > LTO в фазе линковки и происходит... об том я и говорю — что-то собрал не так. хотя, вроде бы, все опции задавал правильно. впрочем, тут бы найти время (и желание, это важнее ;-), чтобы хоть поддержку динамического рантайма в gdc впилить… учитывая, что в последний раз я в потроха gcc лазил ещё во времена третьей версии, и что там происходит сейчас — представляю только в весьма общих чертах. > Если уж всяко непортабельно - на асме по крайней мере получается максимально > забористый и полностью предсказуемый (покомандно!) результат. а если помочь компилятору интринсиками — то он будет в состоянии сгенерировать асм-код с использованием симда. «непортабельно» это потому, что «gcc-измы», видите ли. > предмет простой - сказали эти команды, значит эти. причём повторять это надо много раз, и радостно отлаживать кучу почти одинакового кода. ну нафиг. > Просто потому что либы и так были 32-битные, а основное время > оно проводит не в окружении а в своем коде как раз. 32-битные программы на 64-битной системе таки работают медленней, чем на чистой 32-битной. не так, чтобы сильно заметно, но. так и различие в бенче не ломающее. > Использовались стандартные флаги от автора либы из его makefile. Дописал. Прикол - > скорость ... просела. И в 32 и в 64 битной версии. что ты сделал со своим компилятором, что он такой сумасшедший-то? O_O ради интереса: а что говорит -Q --help=target в обоих вариантах? нет, сюда не надо, просто сам посмотри. любопытно же. > Кэп, а это ведь не удивительно. Судя по всему - у автора > система тоже 64-битная и автор …нифига не оптимизировал код для 32-х бит на том же уровне, что и для 64-х бит? ;-)
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	188. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 01-Июл-14, 10:20
	> старенький, да, корадвадуба на 3 ггц. я очень консервативен, и технику меняю > с трудом. плюс — куча кода с шаблонной магией: основное время > у компилятора уходит на раскрутку всяких шаблонов. нет, это не цпп. > ;-) D? Зачем этот шаблонный геморрой? > а если помочь компилятору интринсиками — то он будет в состоянии сгенерировать > асм-код с использованием симда. «непортабельно» это потому, что «gcc-измы», > видите ли. Интринсики - это не для белого человека. Только по очень большой нужде их следует вставлять.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	189. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 01-Июл-14, 10:28
	> D? Зачем этот шаблонный геморрой? затем, что это геморрой только для того, кто не умеет применять. а если дать себе труд почитать книгу-другую… > Интринсики - это не для белого человека. Только по очень большой нужде > их следует вставлять. конечно, то ли дело сразу на асме, как настоящий джедай.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	208. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 04-Июл-14, 05:28
	> старенький, да, корадвадуба на 3 ггц. я очень консервативен, Я себе относительно свежее железо все-таки взял. Чтобы не знакомиться с UEFIанскими secure-boot и FAT32 разделами на системных дисках в ближайшие годы. Зато система с IOMMU, современными разновидностями шин и кучей ядер. Еще и оперативка с ECC (у AMD так и на десктопах можно). На ближайшее время хватит. > и технику меняю с трудом. На самом деле железо предыдущего компа никуда не делось - стало "выделенной числокрушилкой". Благо, я никогда не экономил на слотах расширения. > уходит на раскрутку всяких шаблонов. нет, это не цпп. ;-) Ну это как-то далеко от меня и моих задач. > не в том, какое там железо, а в том, какие задачи на технике крутит хозяин. А, ты об этом. Ну да, мои задачи могут отличаться от средне-хомячковых. А железо - обычное, десктопное. Почему оно тогда не должно называться десктопом? > да нормально открывается на четырёх гектарах. хотя, может, в новом хроме это > уже починили — у меня весьма древний, Открывается то нормально, но могут случиться внезапные сюрпризы типа OOM killer-а. Немало удивлялся, попробовав устроить "тестовый забег" в духе моего типичного использования веба на хромиуме и получив OOM на машине с 8 гигз. Это было ВНЕЗАПНО, да. > я его запускаю только > когда надо быстренько сбегать на какой-то вообще невменяемый сервис, Я это вообще не запускаю, как максимум раз в месяц - для валидации бага на кроссбраузерность проявления, etc. > у меня нет софта, которому надо более трёх гигабайт. и я не > могу представить, зачем мне такой софт нужен. как и большинству пользователей. Где-то я похожее уже видел, правда там вроде про 640Кб было. > знаю, чем он там занимается. потому что i/o тоже не особо > дёргает при этом. И правда, странно. Чего почтарю делать 10 секунд с письмом - не понятно. Проц при этом в полку не грузится? (1 ядро) > зачем ты кормишь компилятор портянками на 20 гигабайт? ;-) Не компилятор а скомпиленные программы. Я чертовски уверен что не собираюсь ограничиваться 4Гб при работе с mmaped файлами. > дел-то… два пинка и две минуты, тьфу. при этом один раз. Да знаешь, в DOS тоже за 2 минуты драйвер с дискетки ставился, но как-то противно машину постоянно тыкать носом как слепого котенка. При том что шины - у машины, так что процу виднее что там прицепили. Зачем мне самолично такой информацией свой мозг загаживать? > 16 бит. а лучше на 8. Напугал ежа голым задом. Я до сих пор иногда AVRками пользуюсь. Хотя по возможности как-то предпочитаю 32-битные cortex M3 в подобных применениях. За не в пример более "жирные" MIPSы: 1МГц 8-битника и 32-битника - сильно разные вещи. За нормальное линейное пространство памяти. За могучую периферию. При цене даже дешевле чем большинство атмелок. >> Да, Кэп, я занимаюсь оптимизациями лишь когда вижу в этом практический смысл. > то есть, никогда почти. «а чего, пусть лохи технику помощнее покупают». знаю-знаю, жава. Не настолько редко как тебе кажется. Потому что мелкими железками я все-таки увлекаюсь, по поводу чего твои бухтения мне кажутся в высшей мере забавными. Ты сам то когда в последний раз в 16 кило флеша и 4 кило оперативы укладывался? Там твои навороты типа шаблонов вообще жирование, знаешь ли :) > понимаешь, привычка класть на оптимизацию проявляется сама по себе. У меня нет таких привычек. Есть оценка соотношения затрат усилий к результатам. И понимание того ради чего затевается (или не затевается) некое мероприятие. Я не против что-то оптимизнуть, если это не требует затрат времени и не создает дурных неудобств на ровном месте. Слом плагнплея - это в моем понимании недостаток и неудобство. Я считаю что автоконфигурация оборудования это хорошо. Задолбался я перемычки на платах переставлять и прописывать досу драйвера. Нехай само разбирается что и куда подключили. > в итоге техника всё мощнее, Техника мощнее не из-за этого, а потому что технологии производства чипов тоже улучшаются. Это позволяет делать более сложные чипы при меньшем размере, потреблении и цене кристалла. > а софт всё жирней и медленней. при этом никаких > мегауберфич, которые бы оправдывали тормоза, он не приобретает. do not want. Тебе никто не запрещает использовать древние версии софта, если они по твоему мнению лучше. > мне, например, скучно наблюдать за сборкой, я в это время свой код попилить могу. Ну так я и не наблюдаю. Я запускаю это в фоне и занимаюсь чем-нибудь другим. Пусть себе там компилит. Пять минут, семь или десять - не так уж и принципиально: а зачем мне на этот процесс ффтыкать? Система многозадачная, однако - во время выполнения длительных фоновых задач можно заниматься другими делами. А т.к. за 5 секунд никогда не завершается - "длительная фоновая задача". Время выполнения которой не так уж критично в типовых случаях. > зачем мне собирать уберядро с биотуалетом, если нужные > модули я могу дособрать и позже, когда понадобятся? Затем что мне совершенно не хочется засорять свой мозг составлением подробного списка оборудования которое может мне понадобиться. > я отчего-то уверен, что ты не тыкаешь каждые пять минут новую железяку, > для которой новые драйвера нужны. В USB я могу тыкать много чего и разного и греть свой мозг какие там кому из этого драйвера надо и чего-то дособирать, внезапно обнаружив что нужная железка не работает - нафиг надо. Как по мне - лучше пусть машина больше повкалывает чем я. Я ленивый. > так ядро пожалуется, что видит грушу, а скушать не может. и какую именно. Ну а я вот не хочу фэйсом об тэйбл, я хочу чтобы грушу можно было скушать. И вообще, чтоб ее принесли на тарелочке, с голубой каемочкой. Так приятнее. > ну да, у тебя же ядро по часу собирается. Ты несколко недооцениваешь восьмиядерники :-). Час оно будет собираться только с полным конфигом, всем дебагом и билдовкой deb-пакета. Ядро и модули будут готовы через ~15 минут максимум (наихучший случай - все объектники перестраиваются). Остальное время - создание из этого пакетов. Если оно вообще надо (как ты понимаешь, это имеет смысл далеко не всегда). > а у меня — пять минут. с нуля. поэтому ты панически боишься пересобрать ядро, > если что-то изменилось, а я — нет. Cool story, bro. Правда, действительности не соответствует. И ты не понял. Я не боюсь его пересобирать, я хочу чтобы у меня в системе был нормальный человеческий plug-n-play. Установка дров в виндозно-досявом стиле меня несколько подзае... - пингвин может просто подхватить железку и не канифолить мне мозг. Это в моем понимании вкусная фича и я не собираюсь от нее отказываться, что-то зачем-то оптимизируя на системе где плюс-минус пара метров модулей вообще ничего не решали, так что я ничего не выиграл кроме неудобства и шанса обломаться лишний раз именно тогда когда мне работа некоей железки была нужна больше всего. > вот и питонисты то же самое говорят. один-в-один. и чего ты их > так не любишь-то? братья же практически. Они не понимают что и как работает, поэтому они не могут распереться сделать быстро даже когда это становится надо. Так что не братья они мне. Я их подeлий типа yum наелся, добавки что-то не хочется. К тому же гонка как на пожар при разработке софта обеспечивает гунявое качество. Если уж рапидная разработка - так халтура везде, по всей площади. От архитектуры до багфиксинга. > да, не каждый день. тем не менее, читаю. по необходимости, увы. Ну вот я не испытываю никакого желания читать х86 код. Код х86-64 я со скрипом еще согласен почитать, хоть оно тоже не предел мечтаний. Но не такая лютая дрянь как 16- или 32-битный х86. > бы, все опции задавал правильно. В gcc4.8 для сей и плюсов - работает. > я в потроха gcc лазил ещё во времена третьей версии, и > что там происходит сейчас — представляю только в весьма общих чертах. Gdc - это наверное хорошо, но крутые высокоуровневые навороты для меня как-то просто не востребованы. > а если помочь компилятору интринсиками — то он будет в состоянии сгенерировать > асм-код с использованием симда. «непортабельно» это потому, что «gcc-измы», видите ли. Если уж gcc-измы, пусть тогда сразу asm и лопает. Потому что аккуратно выписанный человеком критичный к скорости блок кода - всяко лучше чем то что компилер генерит. А потом еще в оптимизаторе чего-нибудь поменяют, и оно стухнет по скорости в два раза. Придется лишний раз корпеть в ассемблерных дампах, изучая чего отломали в той или иной версии компилера. А оно кому-то надо - становиться экспертам по закидонам оптимизатора в зависимости от версии компилера? Проще 1 раз написать на асме вставку и более к этому безобразию не возвращаться вообще. А непортабельно еще и потому что simd есть не у любого проца. А даже там где и есть - достаточно разный бывает, да еще нескольких видов. Особенно здорово если код - generic и заранее неизвестно на каком именно проце его запустят и какой вариант там работает и какой работает лучше. По этому поводу особо крутые экспонаты делают рантайм детектирование фич проца и/или бенчмарк разных вариантов критичных кусков кода и выбор наилучшего. > причём повторять это надо много раз, и радостно отлаживать кучу почти одинакового > кода. ну нафиг. Обычно вставки делают 1 раз и после единоразового доведения до ума от них ноль проблем. А если полагаться на кодогенератор компилера - придется узнать много всего нового и невкусного и куковать в асмовых листингах после выхода каждой второй версии компилера, где что-то поменяли в оптимизаторе и все нагнулось в пару раз. Кому надо - пусть тот так и развлекается. > 32-битные программы на 64-битной системе таки работают медленней, чем на чистой 32-битной. За счет чего? И какого порядка отличие? Впрочем, я при случае ребутнусь в 32-битную систему и посмотрю насколько оно быстрее. > не так, чтобы сильно заметно, но. так и различие в бенче не ломающее. Я почему-то так подозреваю что выигрыша явно не хватит чтобы побить тот дефолтный 64-битный бинарник. Есть у меня такое ощущение. > что ты сделал со своим компилятором, что он такой сумасшедший-то? O_O GCC 4.8, -O3 - изначально завинчен автором LZ4, его я не трогал. Я согласен что результат использования tune/arch довольно странный, но выглядит одинаково и в 32- и в 64-битных версиях. На первый взгляд, с тюнингом попросту генерится несколько более пухлый код. Возможно, компилер считал что так обычно быстрее. А в этом конкретном случае оказалось что нифига. Это уже надо рассматривать в виде асмовых портянок что там сгенерилось. > не надо, просто сам посмотри. любопытно же. Да вроде там все логично. Могу предположить что компилер не угадал и в конкретно этом случае от "оптимизированного" кода становится хуже. Подобные вещи бывают, см. например про -Os и файрфокс. > …нифига не оптимизировал код для 32-х бит на том же уровне, что и для 64-х бит? ;-) А это уже не мои проблемы. Не могу же я за всеми авторами либы сжатия, шифрования, кодеки и прочее переписывать? А это как раз то где меня производительность и волнует. А может местами где-то 64 бита оказываются удобнее просто.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	193. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от Аноним (??) on 01-Июл-14, 16:28
	Я что-то смутно припоминаю что в конексте с V8 работа с x64 рождает дополнительную проблемму с эффективностью, которой нет у x86 (вроде как примитивый тип данных становится 64-битным даже когда хранятся int числа - тут я правда не уверен что правильно). При том что допустим получить буфер памяти >2Gb в V8 нельзя без серьезных изменений в самой v8, http://stackoverflow.com/a/8974841/601298, см. комментарий Vyacheslav Egorov, одного из разработчиков V8.
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	145. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Xasd (ok) on 30-Июн-14, 09:11
	> я на своих 4gb так и работа этим всё сказано. все должны подстраиваться под тебя. :-) а вот как только ты купишь себе новый компьютер с 16G (а старый сломается) -- все уже должы будут подстраиваться под "нового" тебя (64-битного). ха! разбежался! есть пословица: "семеро одного тормаза не ждут". ____________________ # P.S.: а в новых ультрабуках -- чип оперативной памяти жёстко припаивают на материнскую плату ультрабука. и оставляют только 1 слот для расширения, вместо двух. так что "лишнюю" память не вынешь оттуда, любитель 4G :-) ..
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	146. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 09:17
	> а вот как только ты купишь себе новый компьютер с 16G (а > старый сломается) -- все уже должы будут подстраиваться под "нового" тебя > (64-битного). раньше у меня было 16. необходимости в 64 битах не ощущал. удивительно, да?
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	149. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от Xasd (ok) on 30-Июн-14, 09:38
	> раньше у меня было 16. необходимости в 64 битах не ощущал. удивительно, > да? нет. не удивительно. раньше это было раньше. а софт улучшается со временем. особенно Desktop-софт -- его развитие слегка отстаёт от серверного софта (относительно тенденции быть оптимизированным под современное железо). современные Desktop-файловые-системы и Desktop-ядро и Desktop-пикладные-программы -- сейчас лучше работают на компьютерах с x86_64 (16G ram, например) чем на ущербных i686 компьютерах. а раньше эти Desktop-файловые-системы и Desktop-ядро и Desktop-пикладные-программы -- были задрочены именно под i686 (4G ram). ------------------------------------------------------------ конечно даже и сегодня, работая на устаревшем i686 (4G ram) компьютере  -- ты если сильно постараешься -- то сможешь найти себе какой-то набор  "особенного" софта, которые не будет у тебя вызывать тормоза на твоём устаревшем компьютере. но если бы ты имел в распряжении современный x86_64 (16G ram) компьютер -- ты мог бы выбирать на выбор любой современный софт. а игроделы -- в особенности сейчас пользуются приемуществами x86_64 -- делая например такие игры как Watchdogs (x86_64 only) и пользуясь на славу большим объёмом оперативной памяти. без длинных указателей игроделы ни как бы не смогли бы оперировать гигобайтами данных в оперативной памяти. так что хватит врать будто что-то там им якобы может не нравиться.. ------------------------------------------------------------ > необходимости в 64 битах не ощущал и ещё раз! разжовываю: вопрос НЕ в том -- "есть ли необходимость в 64-битах?" а современный вопрос звучит так: "есть ли необходимость 32-битном ограничении?" или "есть ли необходимость 32-битном ограничении -- сегодня?" потому что ни кто УЖЕ не пропихивает 64-бита. его уже пропихнули (здравые идеи, здравые люди). и речь может быть только о том нужно ли или не нужно (и если нужно -- то как долго) сегодня думать об устаревших 32-битных компьютерах..
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	187. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 01-Июл-14, 10:15
	> раньше у меня было 16. необходимости в 64 битах не ощущал. удивительно, > да? Раньше у всех было 16 бит, но потом появился DOS4GW.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	190. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 01-Июл-14, 10:30
	> но потом появился DOS4GW. эх, молодёжь… даже Phar Lap не видела.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	194. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 01-Июл-14, 18:51
	[неистово крестится]
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	200. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от arisu (ok) on 01-Июл-14, 21:57
	> [неистово крестится] нечто видел? али просто слова бесовские испугали?
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	209. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 04-Июл-14, 05:38
	>> но потом появился DOS4GW. > эх, молодёжь… даже Phar Lap не видела. Я обоих видел. И как-то рад что их времена закончились. Ибо костылищи адские. Оба.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	186. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 01-Июл-14, 10:14
	> — извините, а что, если мне несколько функций одну из другой вызвать > надо? оно же всё равно где-то в памяти будет вынуждено запоминать > значения? и какая разница тогда? > — уйди, мальчик, не мешай ликовать! ура-а-а-а! В спарке эту проблему пытались решить регистровыми окнами. Типичного кеша ЦП должно очень надолго хватить.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	191. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 01-Июл-14, 10:33
	спарк — это, конечно, хорошо. вот только мы не о нём говорили, увы. и в x86_64 никак это решать даже не собирались, просто докинули регистров, чтобы народ поплясал.
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	195. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 01-Июл-14, 18:53
	> спарк — это, конечно, хорошо. вот только мы не о нём говорили, > увы. и в x86_64 никак это решать даже не собирались, просто > докинули регистров, чтобы народ поплясал. так в спарке тоже это не решает проблем. вообще, несмотря на победные реляции АРМа уже которую пятилетку, процессоры Интеля самые быстрые. и, замечу, с "убогим" набором команд. значит, не столько в этом наборе дело, сколько в чем-то другом.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	201. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от arisu (ok) on 01-Июл-14, 21:58
	> значит, не столько в этом наборе дело, сколько в чем-то другом. конечно, в другом. арм, вообще-то, никогда не ставил целью сделать «самый быстрый процессор». извини, но для продолжения хочу узнать: ты идиотничаешь, или просто совсем не в теме? ощущение, что просто не в теме.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	62. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 13:20
	Пройдите в восьмидесятые.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
Сообщение от vitalif (ok) on 29-Июн-14, 00:37
Прально, фигли c#, java... даёшь настоящий хардкор!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от rob pike on 29-Июн-14, 03:21
	Настоящий хардкор - это на Haskell http://www.reddit.com/r/haskell/comments/1y9el0/rewrite_netb.../
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	33. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:40
	> Настоящий хардкор - это на Haskell А я думал - на брейнфаке...
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	64. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от scor (ok) on 29-Июн-14, 13:32
	Спасибо! Не знал про Ajhc. Интересный проект.:)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

5. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+5 +/–
Сообщение от kai3341 (ok) on 29-Июн-14, 00:39
Объясните мне дураку: ЗАЧЕМ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+12 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 01:04
	http://i.imgur.com/oQL4t.jpg
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 01:07
	И правда дурак. Потому что just for fun. Если в совершенстве знаешь какой-либо язык, всегда интересно поэкспериментировать с ним областях, где его применение стандартным не назовешь. Конечно, людям, которые умеют писать код только за деньги, тягу к экспериментаторству не понять.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	42. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+3 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:50
	> И правда дурак. Потому что just for fun. Один дарвинист тоже как-то заявил "во как я могу!" и ... отхватил себе бензопилой голову. Так что само по себе "во как я могу!" еще не гарант полезности и интересности начинаний.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	44. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+3 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 08:53
	особенно умно писать ОС на языке, где нет статической проверки типов. видимо, им ошибок не хватает.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	68. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 15:18
	> особенно умно писать ОС на языке, где нет статической проверки типов. видимо, > им ошибок не хватает. А об этом мы подумаем через годик, когда размер кода перевалит пару мегабайт и недельная сессия отладки закончится безрезультатно.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	69. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 15:57
	шо, через неделю все так отупеют?
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	70. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 16:25
	Пардон, через годик, да.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	71. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 17:14
	> Пардон, через годик, да. Сразу видно яваскриптера :). Только не спрашивайте как я догадался.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	117. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 23:11
	окай, тока я ниразу не яваскриптер :)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	130. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:24
	> окай, тока я ниразу не яваскриптер :) Ну может питонист. Или PHPшник. Или жабист. Не больно какая разница.
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	58. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 11:15
	> Так что само по себе "во как я могу!" еще не гарант полезности Никто не говорит о полезности. Но исключать, что кому-то пригодится, нельзя. > и интересности начинаний. О интересности автору - человеку, который уделил разработке своё время, может сказать только сам автор. То, что сабж не интересен тебе, говорит только о том, что ты считаешь себя пупом земли и удивляешься, зачем в мире столько людей делают то, что тебе не нужно.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	83. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 19:27
	> То, что сабж не интересен тебе, говорит только > о том, что ты считаешь себя пупом земли и удивляешься, зачем > в мире столько людей делают то, что тебе не нужно. странно. я, например, не использовал и не собираюсь использовать leechcraft. и c++ на дух не переношу. однако не говорю, что личкрафт не нужен. с другой стороны, я не использовал и не собираюсь использовать ReactOS. однако реактор — не нужен. это так, информация для размышления.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	165. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 16:40
	fix> это так, никого не интересующее мнение трепла-лузера
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	169. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 18:28
	> fix> это так, никого не интересующее мнение трепла-лузера Ну у тебя и самокритика, тезка.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	205. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от Аноним (??) on 02-Июл-14, 13:40
	не тёзка ты мне, гнiда арисуj0пая
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	10. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Psykukumber (ok) on 29-Июн-14, 01:07
	Потому что могут.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	22. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 04:30
	У них на сайте написано зачем.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	72. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от anonymous from da LOR on 29-Июн-14, 17:39
	Во славу Сатаны, конечно!
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+36 +/–
Сообщение от Аноним (??) on 29-Июн-14, 01:03
26 лет назад у меня была проблема - текстовый процессинг немного тормозил. Казалось, добавить немножко мегагерц, несколько сотен килобайт памяти, и станет хорошо, и наконец-то можно будет нормально работать. Но нет, текстовые редакторы стали графическими, мегагерцы не помогли. Чёртова скрепка смотрела на меня в ворде и тормозила. Всё жрало память. Казалось бы, добавить немножко гигагерц и мегабайт памяти, и станет хорошо, и наконец-то можно будет нормально работать. Но нет, теперь документооборот только в сети. Открывай в браузере google.docs, фигач там. Всё написано на JS, всё в браузере, и поэтому тормозит. Но это потому, что вкладка делит ядро с другими задачами (и памяти маловато). Казалось бы, надо добавить немножко 3-гигагерцевых ядер, ещё несколько гигов памяти, и станет хорошо, и наконец-то можно будет нормально работать. Но нет, теперь ОС будут писать на яваскрипте тоже. И драйвера. Присвятой Торвальдс, они пишут драйвера на JS, этот мир сошел с ума. Хотя понятно - через 20 лет Интелу надо будет как-то продавать новые процессоры на 1024 ядра (ведь на 512 ядрах текст будет нормально не поредактировать - они придумают что-нибудь и для этого), надо начинать решать проблему заранее. А мне надо было ещё на первом шаге (26 лет назад) освоить vim и послать всех к чёрту.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+7 +/–
	Сообщение от anonymous (??) on 29-Июн-14, 01:46
	> А мне надо было ещё на первом шаге (26 лет назад) освоить > vim и послать всех к чёрту. vi. vim-у только 22 года. Ну или Emacs.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	24. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 06:50
	Лучше vim
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	67. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+4 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 15:14
	Какой типаж! Кто вы? Я не узнаю вас в гриме!
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	74. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 19:02
	за кадром осталась нераскрытая тема - зачем было гнаться за модой и переходить на графические редакторы. Автор сам сделал неправильный выбор и проиграл  :)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	156. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
	Сообщение от kravich (ok) on 30-Июн-14, 11:46
	Документооборот он такой - общий для всех
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	113. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 22:50
	вы раскрыли суть капитализма: сами создают проблему и сами же предлагают решение, пусть руки делающие это и разные
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	167. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+2 +/–
	Сообщение от Moomintroll (ok) on 30-Июн-14, 17:28
	> вы раскрыли суть капитализма: > сами создают проблему и сами же предлагают решение, пусть руки делающие это и разные Вы неправы, здесь несколько иное: «Компьютеры позволяют с успехом решать задачи,… которые не возникали до их появления» ©
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	170. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 18:29
	> «Компьютеры позволяют с успехом решать задачи,… которые не возникали до их появления» © А до появления железных дорог не требовались локомотивные депо и обходчики путей. Правда, радости с этого почему-то было мало...
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	183. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 01-Июл-14, 00:31
	> «Компьютеры позволяют с успехом решать задачи,… которые не возникали до их появления» > © конечно: до появления автоматизированной обработки информации за некоторые задачи не было смысла браться. это было настолько очевидно, что никто и не брался, и от того казалось, что таких задач нет. точнее, или результаты было невозможно применить, потому что для применения требовались ещё большие ресурсы, или результаты вообще были бесполезны. а когда появилась возможность решать «неподъёмные» задачи — стали развиваться области, где результаты решения этих задач применимы, и задачи вдруг волшебно возникли. когда появится нуль-Т, тоже будут говорить, что до нуль-Т не было задачи рассчитывать расположение небесных тел с такой точностью. и будут правы: действительно, такой задачи как бы и не было, и никому это было не надо: считать долго, а результат на практике не применим. и конечно, в возникновении таких задач будет виновата именно нуль-Т, а никак не нуль-Т разовьётся потому, что появились мощности, позволяющие решать такие задачи.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

11. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
Сообщение от asavah (ok) on 29-Июн-14, 01:14
дожили, млин
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
Сообщение от MPEG LA (ok) on 29-Июн-14, 01:16
>кооперативная многозадачность успех, чо
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:42
	> успех, чо Почти догнали Win 3.11! :)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
Сообщение от arisu (ok) on 29-Июн-14, 01:30
когда эти идиоты наиграются уже?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от anonymous (??) on 29-Июн-14, 01:47
	> когда эти идиоты наиграются уже? Пусть играются, главное, чтоб не вздумали это на фронтир "инноваций" кидануть. Что-то у меня хреновое предчувствие, однако.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

Часть нити удалена модератором

	40. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:48
	> Покажи-ка свой гитхаб, "эксперт" Меряться всяким спамом на гитхабе - это так по кидисовски. Главное туда какой-нибудь жабаскриптятины или питонятины по бырому навалить и сделать пару тыщ коммитов. Все будут думать что ты мегапрограмер, ололо.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	43. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 08:51
	характерно уже то, что они кроме «гитхаба» больше ничего не знают.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	51. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 10:08
	> характерно уже то, что они кроме «гитхаба» больше ничего не знают. Покажи хоть что-нибудь
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	133. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:29
	> Покажи хоть что-нибудь Он уже показал: способность к мыслительному процессу. Это в 10 раз лучше очередного мегаблокнота на JS (или бидоне) на гитхабе.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	166. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 16:43
	>> Покажи хоть что-нибудь > Он уже показал: способность к мыслительному процессу. Это в 10 раз лучше > очередного мегаблокнота на JS (или бидоне) на гитхабе. арису, залогинься, ты показал свою некомпетентность во всех темах, которые ты берешься комментировать
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	171. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 18:44
	> арису, залогинься, Проблема в том то я ни разу не арису и этот персонаж забыл сообщить мне данные своей учетки. Я, конечно, понимаю что у некоторых граждан от нестыковки ЧСВ с тем как их окружающие воспринимают начинается шиза, но все-таки советую подумать: вы не центр вселенной и на этой планете обитает более 1 человека. Если вам интересно, в данный момент вы подкармливаете персонажа известного как "294-й". И хотя моя точка зрения не так уж редко совпадает с точкой зрения Кэпа, вы доставляете мне море лулзов. Если посмотреть как я спорю с arisu насчет 64 битов, например, в соседних постах. > ты показал свою некомпетентность во всех темах, которые ты берешься > комментировать А я иного мнения на этот счет. Кэп конено временами затупляет, как и любые другие двуногие, но в целом он по крайней мере снабжен головным мозгом и умеет им пользоваться. Это намного более интересное достижение чем 20 нотпадов на js/бидоне на гитхабе. Потому что временами от такого человека можно узнать что-то новое или научиться чему-то полезному. А кусок примитивного гомнокода никаких новых знаний и умений сам по себе не несет...
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	179. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 23:19
	более того: код обычно и не нужен, если можно немного пообщаться — дурость и умность без кода видно. но пусть дети думают, что они круто меня уделали, мне не жалко.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	206. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от Аноним (??) on 02-Июл-14, 13:47
	> Если вам интересно, в > данный момент вы подкармливаете персонажа известного как "294-й" nuff said. арису - твой идеальный приемник эстафеты некомпетентности
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	50. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 10:07
	>> Покажи-ка свой гитхаб, "эксперт" > Меряться всяким спамом на гитхабе - это так по кидисовски. Главное туда > какой-нибудь жабаскриптятины или питонятины по бырому навалить и сделать пару тыщ > коммитов. Все будут думать что ты мегапрограмер, ололо. По крайней мере, будет повод для дальнейшего диалога. arisu генерирует массу мусорных комментариев почти под каждым постом, их смысловая нагрузкая стремится к нулю, в неоднократных попытках перейти в область обоснованного диалога, этот субъект демонстрировал некомпетентность, переход на личности, выдвигал эмоцианальные необоснованные суждения, суть которых сводится к примитивным провокациям (туп0й троллинг), потому попытка проверить хотя бы авторитет этого "эксперта" справедлива.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	88. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:26
	> комментариев почти под каждым постом, их смысловая нагрузкая стремится к нулю, Да, неглупый человек и так знает все что наш форумный Капитан Очевидность имеет сообщить. Но, к большому сожалению, 95% населения - ..., поэтому они из постов arisu узнают для себя много нового. В понятной им форме.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	114. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 22:53
	> Да, неглупый человек и так знает все что наш форумный Капитан Очевидность > имеет сообщить. Но, к большому сожалению, 95% населения - ..., поэтому > они из постов arisu узнают для себя много нового. В понятной > им форме. а вот и почитатели и читатели этого бреда
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	127. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:08
	> а вот и почитатели и читатели этого бреда Кэпа читать интереснее чем всяких cpaных яваскриптеров, которые знают только "яваскрипт рулит!!!111 (потому что ничего другого я не знаю и вообще, программирование слишком сложная штука, а в JS кой-как разобрался даже я)".
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	161. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 15:00
	> Да, неглупый человек арису, залогинься > Но, к большому сожалению, 95% населения арису, ты и есть идеальная репрезентация как входящих в эти 95%, так и использующих "95%"-аргумент для сведения отсутствия обоснований к переходу на личность > поэтому они из постов arisu узнают для себя много нового. В понятной им форме. настолько толстое "сам себя не похвалишь", что даже толсто
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	172. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 19:08
	> арису, залогинься Не могу: Кэп не дал мне свою учетку. А было бы смешно, да. > арису, ты и есть идеальная репрезентация как входящих в эти 95%, Я не арису, я 294-й. Но кормите вы меня хорошо. Напыщенный такой представитель 95% попался. > так и использующих "95%"-аргумент для сведения отсутствия > обоснований к переходу на личность Не очень понимаю какие нужны обоснования, если личность демонстрирует шизу и непонимание что на планете есть чуть более чем 1 человек, так что может получиться что мнение арису по какому-то вопросу ВНЕЗАПНО совпадает с чьим-то еще мнением. Прикиньте, какая неожиданность?! > настолько толстое "сам себя не похвалишь", что даже толсто А по-моему вполне так ничего вышло! Ведь вы 294-му готовы с пеной у рта доказывать что он - арису :).
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	198. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 01-Июл-14, 19:43
	> Я не арису, я 294-й. Это я 294-й, а ты - арису!
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	207. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 02-Июл-14, 13:47
	>> Я не арису, я 294-й. > Это я 294-й, а ты - арису! желаю вам обоим скорейшего попадания в биоректор
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	115. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 23:03
	>> Покажи-ка свой гитхаб, "эксперт" > Меряться всяким спамом на гитхабе - это так по кидисовски. Главное туда > какой-нибудь жабаскриптятины или питонятины по бырому навалить и сделать пару тыщ > коммитов. Все будут думать что ты мегапрограмер, ололо. Ещё круче - наделать форков крупных проектов, типа, я во всём этом разбираюсь и вообще мегаспец по всему на свете. Главное, pull делать регулярно.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	162. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 15:02
	>>> Покажи-ка свой гитхаб, "эксперт" >> Меряться всяким спамом на гитхабе - это так по кидисовски. Главное туда >> какой-нибудь жабаскриптятины или питонятины по бырому навалить и сделать пару тыщ >> коммитов. Все будут думать что ты мегапрограмер, ололо. > Ещё круче - наделать форков крупных проектов, типа, я во всём этом > разбираюсь и вообще мегаспец по всему на свете. Главное, pull делать > регулярно. главное, что всё местоо трепло типа arisu неспособно даже не это
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	173. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 19:10
	> главное, что всё местоо трепло типа arisu неспособно даже не это Батхерт засчитан. Но ты продолжай, мегапрограммист.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	85. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Серж (??) on 29-Июн-14, 19:51
	Гитхаб не модно, Аноним! Сделай в железе и покажи железку, а не гитхаб!
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	35. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+3 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:43
	> когда эти идиоты наиграются уже? Лучше пусть "ОС" на JS пишут, чем по лестницам валяются бухими и обдолбаными. Хотя, операционку на JS будучи трезвым тоже врядли полезешь писать.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	37. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+2 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 08:45
	>> когда эти идиоты наиграются уже? > Лучше пусть "ОС" на JS пишут, чем по лестницам валяются бухими и > обдолбаными. одно другому совершенно не мешает.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	89. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:28
	> одно другому совершенно не мешает. Ну почему же? Неудобно наверное валяясь на лестнице код писать. Я, правда, не проверял, но подозреваю.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	90. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 29-Июн-14, 20:38
	>> одно другому совершенно не мешает. > Ну почему же? Неудобно наверное валяясь на лестнице код писать. Я, правда, > не проверял, но подозреваю. можно чередовать.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	128. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:09
	> можно чередовать. Тогда в моменты написания кода тушка негодяя не будет занимать местность -> PROFIT :).
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	136. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от arisu (ok) on 30-Июн-14, 04:42
	сам ты негодяй! я всего лишь молодой был!
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	147. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 09:22
	Негодяй, негодяй! Занимал место и не давал другим достойным людям место поваляться там!
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

14. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–2 +/–
Сообщение от Аноним (??) on 29-Июн-14, 01:35
Классно сделали с научной точки зрения, в качестве примера возможностей языка. Думаю что и в других отраслях найдется применение
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+3 +/–
	Сообщение от MPEG LA (ok) on 29-Июн-14, 01:39
	ну брали бы уже тогда Dart или TypeScript...  их хоть оптимизировать можно толково (статика какая-никакая)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	77. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 19:05
	> ну брали бы уже тогда Dart или TypeScript...  их хоть оптимизировать > можно толково (статика какая-никакая) есть мнение (не мое, но поддерживаю), когда начинают что-то оптимизировать, это перестает нормально работать :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	82. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+3 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 19:23
	> есть мнение (не мое, но поддерживаю) о, да: говнокодеров в мире навалом. чумы на них нет.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	36. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+6 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:44
	> Классно сделали с научной точки зрения, в качестве примера возможностей языка. С научной точки зрения, теоретически все ЯП эквивалентны. А практически - "есть некоторые нюансы". Поэтому "во как я могу!" применительно к колошматингу гвоздей микроскопами совершенно не обязано выглядеть убедительно и симпатично.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	63. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Baz on 29-Июн-14, 13:22
	найдётся применение? ещё одна мобильная ось чтоль? ))))
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	112. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 22:39
	> найдётся применение? ещё одна мобильная ось чтоль? )))) Нет, все в тех же учебных целях, просто подходы к преподаванию у всех разные. Поэтому думаю что найдется тот кто будет доволен этим проектом. Я вообще считаю что подобные проекты надо воспринимать как есть, а именно автор или авторы совершенствуют свои знания. Так что от слов нафиг это поделье нужно, им ни холодно ни жарко. Но зато у этих людей есть талант и знания.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	168. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Moomintroll (ok) on 30-Июн-14, 17:31
	> Но зато у этих людей есть талант и знания. … и КУЧА свободного времени
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

20. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
Сообщение от kravich (ok) on 29-Июн-14, 03:24
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
Сообщение от бедный буратино (ok) on 29-Июн-14, 06:49
в netbsd это можно прям в браузере запускать. а тут ещё и qemu
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+3 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 08:46
	> в netbsd это можно прям в браузере запускать. а тут ещё и qemu Фабрис сто лет назад уже линь на своем JS-эмуляторе x86 запускал. Ну как бы забавно, но практической пользы - ноль целых, хрен десятых. Единственное реальное достижение - за счет крЮтого профессионализма Фабриса оно тормозит все-таки несколько меньше чем ожидаешь.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	52. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–2 +/–
	Сообщение от бедный буратино (ok) on 29-Июн-14, 10:09
	во-первых, не сто лет назад. а во-вторых, с очень большими ограничениями. netbsd-шное ядро - реально работает :) правда, как и у большинства проектов netbsd, хоть потенциал и огромный, но сами они так и не поняли, зачем это сделали... сделали и сделали, само сделалось, а что дальше - неясно.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	57. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от rob pike on 29-Июн-14, 11:10
	Вы зря так плохо думаете о людях. NetBSD часто используется для экспериментов в области ОС-строения, но не стоит считать что их целью являются те артефакты, которые от этих экспериментов остаются в NetBSD. Это не более чем побочные эффекты. Просто то "что дальше" происходит уже не в NetBSD и этого кода открывать никому интереса нет.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	91. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:39
	> во-первых, не сто лет назад. Про понятие "образное выражение" наш железный дровосек видимо не слышал. > а во-вторых, с очень большими ограничениями. Обычное ядро, обычного линя. Ну разве что лишшнее отключили для уменьшения размера и ускорения загрузки. Не, конечно можно собрать ему 500 модулей USB/PCI/... устройств, только где их JS и браузер возьмут? А так - программы запускает, даже свою можно написать и скомпилить фабрисовским же tiny c. Единственный реальный лимит - ну, ок, сети нет. Но это скорее ограничение браузера. Не дает он JS лупить произвольными пакетами в сеть. Что к лучшему. Иначе каждая вебпага pwn'ила бы весь интранет первым делом. Странички и так это уже умеют. Усугублять не надо. > netbsd-шное ядро - реально работает :) А тот линь в эмуле  - НеРеально работает, чтоли? > netbsd, хоть потенциал и огромный, но сами они так и не > поняли, зачем это сделали... сделали и сделали, само сделалось, а что > дальше - неясно. Ну так как обычно. "Во как я могу! -> хрясь бошку бензопилой". Чуть более продвинутая форма самовыражения.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	116. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 23:05
	>[оверквотинг удален] > Про понятие "образное выражение" наш железный дровосек видимо не слышал. >> а во-вторых, с очень большими ограничениями. > Обычное ядро, обычного линя. Ну разве что лишшнее отключили для уменьшения размера > и ускорения загрузки. Не, конечно можно собрать ему 500 модулей USB/PCI/... > устройств, только где их JS и браузер возьмут? А так - > программы запускает, даже свою можно написать и скомпилить фабрисовским же tiny > c. Единственный реальный лимит - ну, ок, сети нет. Но это > скорее ограничение браузера. Не дает он JS лупить произвольными пакетами в > сеть. Что к лучшему. Иначе каждая вебпага pwn'ила бы весь интранет > первым делом. Странички и так это уже умеют. Усугублять не надо. Хоть не позорились бы; не знаете, о чём говорите - лучше промолчите.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	134. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:35
	> Хоть не позорились бы; не знаете, о чём говорите - лучше промолчите. Ты о чем, чудило? Если про pwnage - вполне обычная практика делать запрос из "дружественной" вебстранички на какого-нибудь "почти-локалхоста" вида 192.168.1.1, где обычно у хоячков живет нечто типа домашнего роутера. И зачастую обычного get-запроса, который может скроить даже браузер - более чем достаточно для поимения. Благодаря дырам или бэкдорам. Так что браузер кроме всего прочего может "случайно" поиметь сетевую железку в интранете, если она бажная или просто с дефолтным паролем. Особо продвинутые вещицы типа NoScript в firefox срубают подобные инициативы, как раз именно вот поэтому, но как ты понимаешь, далеко не каждый первый хомяк догадывается о такой подставе.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

25. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
Сообщение от pavlinux (ok) on 29-Июн-14, 06:51
Даёшь ОСь на XML!!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от rob pike on 29-Июн-14, 10:47
	На XSLT, вы хотели сказать? Придётся много extension-ов изолентой привязывать. На SQL тоже хорошо получится, IIRC он же Тьюринг-полон с CTE.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	73. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от pavlinux (ok) on 29-Июн-14, 18:13
	> На XSLT, вы хотели сказать? Тогда линух написан на GCC
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	92. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:40
	> Тогда линух написан на GCC Не настолько уж и неправда - а ты попробуй его чем-нибудь другим собрать :).
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	95. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 29-Июн-14, 20:43
	>> Тогда линух написан на GCC > Не настолько уж и неправда - а ты попробуй его чем-нибудь другим > собрать :). смотря какой версии. до определённых пор — вполне собирался при помощи tcc.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	102. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:51
	> смотря какой версии. до определённых пор — вполне собирался при помощи tcc. Современной. Там пытаются прикрутить сбор шлангом, но пока воз и ныне там, так что....
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	125. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от pavlinux (ok) on 30-Июн-14, 02:10
	>> смотря какой версии. до определённых пор — вполне собирался при помощи tcc. > Современной. Intel C, AMD Open64, clang под ARM полностью рабочий. В общем тема не о том, а от том, что XSLT - это препроцессор перед "XML-движком".
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	135. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 04:37
	> В общем тема не о том, а от том, что XSLT - > это препроцессор перед "XML-движком". Тем не менее, насколько я помню, он тюринг-полный, так что теоретически он может все. Практически это будет круче чем "а теперь коронный номер - фантомас в очках на аэроплане".
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	140. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от pavlinux (ok) on 30-Июн-14, 05:12
	> Тем не менее, насколько я помню, он тюринг-полный,... При условии, что разработка OS XML будет конечна :)
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	174. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 19:26
	> При условии, что разработка OS XML будет конечна :) Где-то здесь мы и начинаем догадываться чем теория отличается от практики....
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

48. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
Сообщение от Baz on 29-Июн-14, 09:58
давайте пообсуждаем эмблему этой ОС, видимо там что-то вроде "0" будет, только кривоватое...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	79. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 19:09
	> давайте пообсуждаем эмблему этой ОС, видимо там что-то вроде "0" будет, только > кривоватое... вполне возможно, хотя я бы предпочел что-то такое монументальное. Типа "Х", только гротескный...
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

61. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
Сообщение от Нанобот (ok) on 29-Июн-14, 12:01
JavaScript поверх гипервизоров - как-то слабенько. Даёшь Javascript на реальном железе! Чтобы поддержка Javascript была прямо в процессоре!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	65. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+3 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 14:00
	поддержка С++ уже есть в твоем процессоре?
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	78. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–2 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 19:07
	> поддержка С++ уже есть в твоем процессоре? js в железо перенести вполне реально, а С++ - фиг :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	94. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:42
	> js в железо перенести вполне реально, а С++ - фиг :) Оно и видно - C++ную программу можно целиком перегнать в нативный код заранее, а в JS этот номер весьма проблематичен.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	96. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–1 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 20:44
	>> js в железо перенести вполне реально, а С++ - фиг :) > Оно и видно - C++ную программу можно целиком перегнать в нативный код > заранее, а в JS этот номер весьма проблематичен. нет никаких проблем в этом. большого смысла, правда, тоже.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	99. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:46
	> нет никаких проблем в этом. большого смысла, правда, тоже. Динамические свойства усложняют это начинание. Абсолютно невозможным, конечно, не становится, но все-таки.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	100. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	–2 +/–
	Сообщение от arisu (ok) on 29-Июн-14, 20:47
	>> нет никаких проблем в этом. большого смысла, правда, тоже. > Динамические свойства усложняют это начинание. нет.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	154. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 11:31
	>> js в железо перенести вполне реально, а С++ - фиг :) > Оно и видно - C++ную программу можно целиком перегнать в нативный код > заранее, а в JS этот номер весьма проблематичен. а теперь попробуйте немного напрячь головную мышцу и подумать об интерпретаторе.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	178. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 20:24
	> а теперь попробуйте немного напрячь головную мышцу и подумать об интерпретаторе. Исторически как-то так вышло что кампиляторы с ahead of time перегонкой в нативный код совершенно безнадежно зарулили интерпретаторы. В плане скорости и всего такого. Вообще, чистый интерпретатор обречен быть тормозиловом, потому что сильно разбавляет поток команд с логикой программы своим потоком команд "потому что интерпрератор работает". Это неизбежно обеспечивает поганую производительность vs компилятор или JIT, где по возможности в проц отправляется только поток команд с реализацией желаемой логики и ничего лишнего в комплекте.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	181. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 01-Июл-14, 00:23
	AOT-ы атомно отсасывают у JIT-ов в языках с динамической типизацией. по очевидным причинам. чисто теоретически на долгих задачах хороший JIT может нагнауть AOT и для языка со статической типизацией — за счёт задрачивания хотспотов под поведение программы.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	197. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Vkni (ok) on 01-Июл-14, 19:41
	> чисто теоретически на долгих задачах хороший JIT может нагнауть AOT и для > языка со статической типизацией — за счёт задрачивания хотспотов под поведение > программы. Никто не мешает делать гибрид - вхерачивать в скомпилированный код высокоуровневого языка (не С/С++) кеширование, аля JIT.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	202. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 01-Июл-14, 22:00
	> Никто не мешает делать гибрид - вхерачивать в скомпилированный код высокоуровневого языка > (не С/С++) кеширование, аля JIT. никто, только это всё равно будет разновидность JIT. да и особого смысла нет, потому что класс задач, где овчинка будет стоить (для статических языков) — исчезающе мал. а компилятор за счёт этого сильно усложняется.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	97. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:44
	> js в железо перенести вполне реально, а С++ - фиг :) FYI, поинтересуйтесь как делают аппаратные декодеры видео. Сильно офигеете, узнав что это далается ... трансляцией кода на C или урезанном C++ в железо.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	153. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 11:30
	Ну вот откуда вы такие выбежали, говороны очевидного?  При чем тут трансляция? Речь об интерпретаторе. И тут js код можно стравливать по инструкции, а вот сишный код - фиг.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	175. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 20:17
	> js код можно стравливать по инструкции, Можно все. Только выглядеть будет как http://s00.yaplakal.com/pics/pics_original/2/8/1/2577182.jpg :-) > а вот сишный код - фиг. Если вы вдруг не знали, в железе гораздо проще и быстрее парсить бинарные опкоды. И дряни по шинам в этом процессе меньше передается. Вот и не занимается никто онaнизмом в предложенном вами стиле.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	87. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от A.Stahl (ok) on 29-Июн-14, 20:22
	Может я что-то путаю, но вроде бы SUN выпускали (проектировали?) процы, жрущие Java-байткод.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	111. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 22:35
	Более того, в некоторых стареньких Nokia было такое: ARM9 с технологией Jazelle, которая и есть исполнение Java-байткода. Но не JavaScript.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	176. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+1 +/–
	Сообщение от Аноним (??) on 30-Июн-14, 20:19
	> которая и есть исполнение Java-байткода. Только если почитать внимательно, окажется что выполняется в железе там далеко не все и единственное ощутимое достоинство - выделенный железный state tracker для JVM. В любом случае, как видим, использование этой хрени сошло на нет.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	93. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:42
	> поддержка С++ уже есть в твоем процессоре? Он заранее транслируется в нативный код, поддержка которого у процессора, определенно, есть :). И если посмотреть внимательно, некоторые машинные команды сделаны именно такими чтобы сям было удобно делать типовые операции.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	98. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 29-Июн-14, 20:45
	> И если посмотреть внимательно, некоторые машинные команды сделаны именно > такими чтобы сям было удобно делать типовые операции. а я вот читал, что два вида инкрементов/декрементов в си появились как раз потому, что у процессора соответствующие команды были…
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	101. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 29-Июн-14, 20:48
	> а я вот читал, что два вида инкрементов/декрементов в си появились как > раз потому, что у процессора соответствующие команды были… А я вот читал что, например, система команд AtMega была спроектирована именно такой для того чтобы сишные компилеры удобно было делать. ЧСХ, один из немногих восьмибитников, под которые есть нормальные сишные и даже слегка плюсатые компилеры.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	104. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 29-Июн-14, 20:59
	ну да: сначала си подгоняли в угоду PDP, а теперь железо подгоняют под PDP. гыг.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	177. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Аноним (??) on 30-Июн-14, 20:21
	> ну да: сначала си подгоняли в угоду PDP, а теперь железо подгоняют под PDP. гыг. Да все правильно на самом деле - до появления компилера, дизайны компилеров были ориентированы на железо. А после появления таковых - железо тоже стали подгонять под компилеры. А почему этот процесс должен быть 1-сторонним, если в дружбе заинтересованы и те и другие? Микропроцессор без софта - кусок кремния. Поэтому чипмейкер заинтересован чтобы с его чипами софт работал хорошо.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	196. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от Vkni (ok) on 01-Июл-14, 19:39
	> до появления компилера Оптимизирующих компилеров. Только этот презерватив на глобус уже не натягивается - GPU не влез, интринсики всякие набежали.
	Ответить | Правка | ^ к родителю #177 | Наверх | Cообщить модератору

	203. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+/–
	Сообщение от arisu (ok) on 01-Июл-14, 22:02
	на самом деле супероптимизатор (для наблюдателей: это термин, если что, а не эпитет) вполне в состоянии сгенерировать идеальный код для чего угодно. другое дело, что ему для этого нужны идеальные машины с неограниченым быстродействием. а тогда необходимость в супероптимизации отпадает.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	108. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
	Сообщение от burjui (ok) on 29-Июн-14, 22:10
	Ждём интерпретатор JavaScript в FPGA. Но лучше на микросхемах логики, а то слишком легко. Или на транзисторах. Или уж сразу придумать QuantScript, чтобы два раза работу не делать, а то скоро производительности обычных компьютером для браузеров не будет хватать.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

118. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
Сообщение от Аноним (??) on 30-Июн-14, 00:11
для онлайн-сервисов(не только социальных сетей и иже)нужная штука, бо там до половины кода в жабОскрипте, порой, бегает. опять-же Ынтерпрайз разный бывает. даже препроцессоры к HPC-вещам, порой - на нем, родимом, увы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

182. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
Сообщение от Наноним on 01-Июл-14, 00:25
Вы все не верно размышляете!!! Для JS надо писать двигло написанное на JS чтобы исполнять JS скрипты. А для этого нужен компилятор на JS. А чтобы написать компилятор на JS надо по любому использовать один из низкоуровневых компиляторов.  Можно использовать для этой цели любой низкоуровневый компилятор и линковщик, но лучше всего тот, который не связан цепями патентов, чтобы потом к вам никто не приставал по финансовым вопросам.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

192. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
Сообщение от Аноним (??) on 01-Июл-14, 16:12
Это видимо какбе такой серверный WebOs с Node.js
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

199. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	–1 +/–
Сообщение от Аноним (??) on 01-Июл-14, 20:09
Проектом занимается походу только один человек. Я на гитхабе подглядел. А вообще я помню, еще когда на всех компах всего мира стоял 98 виндовс, помню нашел в сети эмулятор линукса на JS. У меня гдето в архивах валяется на старом винте.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	204. "В рамках проекта Runtime.JS развивается ядро ОС на базе..."	+1 +/–
	Сообщение от arisu (ok) on 01-Июл-14, 22:03
	> когда на всех компах всего мира стоял 98 виндовс > эмулятор линукса на JS ты лжёшь. то, что ты нашёл — это был достаточно ограниченый недоэмулятор shell и нескольких posix-утилит. разницу нагуглишь.
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

210. "В рамках проекта Runtime.JS развивается ядро ОС на базе Java..."	+/–
Сообщение от piteri (ok) on 07-Июл-14, 10:57
Аааа, горшочек, не вари!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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