Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: Почему так мало программ на java?  (Прочитано 2924 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Axa-Ru

  • Гость
Re: Почему так мало программ на java?
« Ответ #30 : 16 Сентября 2011, 14:07:32 »
Уменьшаю количество слов:

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

Оффлайн Gengza

  • Новичок
  • *
  • Сообщений: 9
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #31 : 16 Сентября 2011, 14:39:42 »
Уменьшаю количество слов:

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

1 процесс (1 запущенное приложение) может содержать 1 и более кол-во потоков. поток != процесс. потоки можно паралелить в пределах процессоров. для выполнения одновременно 2х приложений, нужно переключать контексты, что приводит к задержкам.

не нужно путать тёплое с мягким.

Оффлайн Tonal

  • Любитель
  • *
  • Сообщений: 82
  • Карма Кагью
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #32 : 19 Сентября 2011, 10:26:35 »
1 процесс (1 запущенное приложение) может содержать 1 и более кол-во потоков. поток != процесс. потоки можно паралелить в пределах процессоров. для выполнения одновременно 2х приложений, нужно переключать контексты, что приводит к задержкам.

не нужно путать тёплое с мягким.
Точно. :)
Чтобы гарантированно не запутаться, нужно определить термины.

Давай подробно всё распишем:
  • Процесс для ОС - это набор ресурсов, как то память, список привязанных процессоров (как минимум 1), список выполняющихся потоков (как минимум 1), объекты синхронизации, файлы/внешние устройста. Возможны ещё разные ресурсы, типа оконных и ресурсных дескрипторов в винде и других ресурсов разных АПИ.
  • Поток для ОС - это набор комманд процессора + набор регистров + стек + доп.память потока. Так же возможны дополнительные ресурсы ОС и библиотек.
  • Объекты синхронизации - всяческие симофоры, мютексы, условные переменные. Так же часто файлы и устройства могут являтся явными или неявными объектами синхронизации.
  • Диспетчер выполнения (планировщик) - подсистема в ОС, которая распределяет время выполнения потоков на процессорах с учётом объектов синхронизации.
В каждом процессе должен быть хотя бы один поток - главный.
При запуске процесса ОС выделяет нужные процессу и главному потоку ресурсы и запускает на выполнение главный поток.
Главный поток, во время выполнения, явно или не явно, создаёт нужное количество вторичных потоков, которые тоже, в свою очередь, тоже могут создавать потоки.
Потоки, явно или не явно используют объекты синхронизации для синхронизации.
Диспетчер выполнения следит за тем, чтобы всем потокам в системе досталось нужное количество времени.
Как это происходит:
  • При активизации менеджера он проверяет должен ли текущий поток выполнятся дальше.
  • Если нет - поток ставится в ожидание (засыпает), и время процессора отдаётся другим претендентам.
Каким же образом активизируется диспетчер?
Видятся основных 3 варианта:
  • Каждый поток явно отдаёт управление диспетчеру.
  • По таймеру или событию от внешнего устройства прерывается текуший поток и выполнение переключается на поток диспетчера.
  • Поток диспетчера выполняется на отдельном процессоре. Когда он решает, что текущему потоку на другом проце пора отдахнуть - он его останавливает.
Первый вариант называется «кооперативная многозадачность». Она применялась в Win3.x, Nowell Netware, DOS Tsr, и различных Дос расширителях.
Кроме того, при запуске потока posix thread его можно сконфигурировать на похожий такой режим; так же есть Fiber-ы в WinApi. В этих 2х случаях дочерние кооперативные потоки выполняются в рамках запустившего обычного.

Второй вариант интереснее. Что происходит в момент прерывания потока для пункта 2.
Процессор сохраняет все текущие регистры в доп. память текущего потока и переключается на выполнение потока диспетчера, восстанавливая значение регистров из его доп.памяти. Так же тут происходят сбросы кешей - ведь их значения бессмысленны для другого потока.
Вот мы и добрались до того самого «долгого сохранения/восстановления».
В варианте 3 остановка и возобновление потока происходит практически так же.

А теперь, сможешь описать где именно получает выигрыш виртуальная машина Java (JVM) при многозадачности?
В каком месте она оптимизирует работу по сохранению/восстановлению регистров и сбросу кешей?

Ну, или можешь описать самостоятельно всю механику указав где ошибочно моё описание. :)

П. С. Я не расписывал управление приоритетами и работу с объектами синхронизации - это влияет на стратегию выбора диспетчером какие процессы должны заснуть/проснутся, но не на сам механизм засыпания/просыпания.

Оффлайн Gengza

  • Новичок
  • *
  • Сообщений: 9
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #33 : 19 Сентября 2011, 10:58:43 »
Цитировать
Вообще-то для обуздания неуправляемого кода существует аппаратная архитектура, основанная на изоляции адресных пространств памяти каждого процесса, кольцах безопасности и продуманном механизме переключении задач. Но прямое её использование существенно снижает производительность системы, в которой трудится множество программ (аппаратное переключение контекста процесса требует сотни циклов работы процессора). Кроме того, все преимущества аппаратной поддержки защиты памяти сводятся на нет лояльностью к вопросам работы с разделяемыми объектами и данными - основой коммуникаций процессов в нынешних системах.

собственно выполнение управляемого кода в среде виртуальной машины, решает эту проблему.

Оффлайн Tonal

  • Любитель
  • *
  • Сообщений: 82
  • Карма Кагью
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #34 : 19 Сентября 2011, 12:15:21 »
Ещё раз спрашиваю: каким образом «выполнение управляемого кода в среде виртуальной машины» решает проблему долгого переключения контекстов?

Я вижу 3 возможности:
 1. Нативный. Использовать многозадачность ОС дополняя своими обёртками - тут выигрыша совсем нет. :)

 2. Внутренний. ВМ сама управляет многозадачностью, т. е. берёт на себя работу планировщика и объектов синхронизации. При этом прерываться текущий поток выполнения может явным вызовом функции планировщика (sleep/yeld...), или после определённого количества инструкций ВМ. Соответственно сохранятся/восстанавливаться будут не регистры процессора а текущее состояние виртуальных регистров. Сколько это «циклов работы процессора» зависит от устройства ВМ и её «процессов». Не факт что этих циклов окажется больше. :)
Ну и использовать несколько процессоров/ядер при этом не получится - распределением по процам управляет планировщик ОС, а для него вся ВМ - один нативный поток.
Так же, при самостоятельной реализации планировщика ВМ практически лишается средств многозадачности ОС, которые могут быть гораздо сильнее проработаны под определённую специфику (например реалтайм).
Кроме того, для такой виртуальной многозадачности есть некоторые атомарные операции, выполнение которых невозможно прервать другим псевлопотоком ВМ. Это может быть, например, копирование объектов, операции менеджера памяти, вызовы нативных функций с непредусмотренной поддержкой планировщика этой ВМ.
(В Erlange долго была проблема в том, что сопоставление с образцом было атомарным. при этом для больших данных сопостовление могло блокировать всю ВМ).

 3. Гибрид. Использовать нативные потоки ОС. На каждом пускать несколько ВМ-потоков.
Проходит в том случае, если переключение ВМ-потоков существенно быстрее нативных. При грамотной диспетчеризации можно избежать блокировок на атомарных операциях. Но код внутреннего планировщика изрядно усложняется и должен быть подогнан под специфику планировщика ОС. Так же сильно возрастает сложность менеджера памяти (сборщика мусора).

Насколько я в курсе ВМ Erlang-а использует именно 3-ю возможность. ВМ Python-а - 1
Насчёт JVM не очень в курсях - нужно исследовать вопрос (быстрый поиск показал что начали с 2 и 3, перешли к 1). :)
Можешь сам погуглить и выложить наиболее вменяемые ссылки по теме. :)

Про разделяемые объекты - с ними нет проблем при работе внутри одного процесса - память то общая. :)

Axa-Ru

  • Гость
Re: Почему так мало программ на java?
« Ответ #35 : 19 Сентября 2011, 12:25:44 »
Можно я за него отвечу...
Нужно написать программу на С++.

Оффлайн Gengza

  • Новичок
  • *
  • Сообщений: 9
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #36 : 19 Сентября 2011, 12:28:42 »
Где-то там, чуть выше, я уже писал каким образом.

Проще говоря, для процессора работает всегда один процесс. Остальные запущенные приложения работают внутри виртуальной машины. Да, она является менеджером процессов. Да она сама переключает между ними контекст внутри себя. По этому не тратится процессорное время на эти задачи. И да, тесты Singularity показали что этот подход является эффективным. Более того, еще и безопасным. Но само собой с ограничением - выполнять можно только управляемый код.

Оффлайн Tonal

  • Любитель
  • *
  • Сообщений: 82
  • Карма Кагью
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #37 : 19 Сентября 2011, 17:44:16 »
Проще говоря, для процессора работает всегда один процесс. Остальные запущенные приложения работают внутри виртуальной машины.
Опять у тебя каша в терминах.
Общепринятую терминологию я привёл:
На процессоре выполняется поток инструкций.
Процесс - всего лишь контейнер содержащий 1 или больше потоков, общую память и некоторые другие системные ресурсы.
Т. е. выполняются только потоки.
Что означает термин приложение в этом контексте - непонятно. :)

Да, она является менеджером процессов. Да она сама переключает между ними контекст внутри себя. По этому не тратится процессорное время на эти задачи.
Т. е. кооперативеая или гибридная модель.
И я правильно понял по выделенному, что на логику планировщика и переключение потоков процессорное время не тратится? А как жеж и кем эта логика исполняется ежли не процом?
Вмемориз однозначно! :2funny:

И да, тесты Singularity показали что этот подход является эффективным. Более того, еще и безопасным. Но само собой с ограничением - выполнять можно только управляемый код.
Ежели ты пишешь для Singularity - вполне возможно. Даже если пишешь на Erlang-е или Haskell-е под *никс, мак или офтопик - тоже возможно.
Но для более обычных сочетаний ОС - язык пока грамотная нативная реализация многопоточности таки быстрее управляемой. :)

Оффлайн ArhimondR

  • Новичок
  • *
  • Сообщений: 21
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #38 : 21 Сентября 2011, 00:27:32 »
Очередной холи вар=)))
раз пошел разговор о быдло кодерах.....хм....

чтобы стать быдло кодером, в:

с++ - надо знать че такое cout

php - надо знать че такое echo

у явы в этом плане получаются самые НЕ говнокодеры, ибо в яве надо знать многабукаф аля System.out.atatat

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

с++ - в основном вещи работающее на "полу-системном" уровне(доступ к системным рессурсам на прямую)
плюс этого языка - доступ ко всему что угодно, высокое быстродействие(ПРИ ПРАВИЛЬНОМ НАПИСАНИИ КОДА)
минусы - очень длительная компиляция(реально большие проэкты по слухам могу и целую ночь компилится), зависимость от платформы, зависимость от версий библиотек, почти что нету универсальных фреймворков которые облегчают жизнь при решении повседревных задач

java - в основном вещи которые не требуют прямого доступа к системным ресурсам(хотя с использованием JNI можно делать все что угодно)
Плюсы - низкое время компиляции, куча полезных фреймворков, технологий(EJB, SPRING, HIBERNATE) которые облегчают жизнь для рядового  разработчика решений для бизнеса и предприятий, особенно когда говорят "Надо сделать до вечера". Тем более что производительность Java почти на одном уровне даже при правильном написании кода на с++(это еще конечно зависит от компилятора и JVM.....но....).

Если в случаях "Надо сделать до вечера" юзать с++ с его компиляцией в ночь.....


Оффлайн Упс

  • Старожил
  • *
  • Сообщений: 3231
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #39 : 21 Сентября 2011, 02:32:09 »
Цитировать
с++ - в основном вещи работающее на "полу-системном" ................ почти что нету универсальных фреймворков которые облегчают жизнь при решении повседревных задач
Qt не подойдёт?
Хотя если "Надо сделать до вечера" то "Не себе и так сойдёт". :)
« Последнее редактирование: 21 Сентября 2011, 02:38:11 от Упс »
xUbuntu 12.04

Axa-Ru

  • Гость
Re: Почему так мало программ на java?
« Ответ #40 : 21 Сентября 2011, 08:49:48 »
ArhimondR, вы извините меня пожалуйста, но почти все, что вы написали никакой связи с реальным миром не имеет.
Проект с Qt Sigil собирается минут за 5. Ядро линукс имеет 10 миллионов строк кода. На моем ноуте компилится около 40 минут. Про какие ночи вы говорите?

Что за полусистемный уровень?

Чем писать пустые фантазии и вводить в заблуждение неокрепшие умы лучше бы дали ссылки на фактический материал:
В Google провели сравнение производительности C++, Java, Go и Scala
Заодно и сами бы почитали  >:(
« Последнее редактирование: 21 Сентября 2011, 08:53:21 от Axa-Ru »

Оффлайн ArhimondR

  • Новичок
  • *
  • Сообщений: 21
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #41 : 21 Сентября 2011, 11:43:00 »
Что за полусистемный уровень? - Это было написано в кавычках, это значит что программе может потребоватся прямой доступ к памяти, и прочему железу. Хотя как я потом сказал, с помощью  JavaNativeApi можно писать на с++ и подключать к ява-машине библиотеки. (Был один случай когда к Swing апликашке надо было подключить сканер=))))

Статью с гугла читал.

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

Qt - это десктоп фреймворк=) А у нас в основном вэб-интерфейсы.

Оффлайн RazrFalcon

  • Автор темы
  • O_o
  • Старожил
  • *
  • Сообщений: 3129
  • Zombie Mod
    • Просмотр профиля
    • Я на GitHub
Re: Почему так мало программ на java?
« Ответ #42 : 21 Сентября 2011, 12:05:29 »
Qt - это десктоп фреймворк=) А у нас в основном вэб-интерфейсы.
У "вас" - это у кого? Инопланетян?
Тема изначально про десктопы была. А точнее про десктопный линукс.
Все что вы написали делает кьют, без проблем. Если нужен полусистемный уровень - "Си" ваш друг. Ну или на крайняк С++ STD.

И да, 10к строк на с++ - это реально небольшая прога.
Gentoo + KDE, Official Windows Hater
Хотите помочь нашей вики: https://help.ubuntu.ru/wiki/fixme

Оффлайн ArhimondR

  • Новичок
  • *
  • Сообщений: 21
    • Просмотр профиля
Re: Почему так мало программ на java?
« Ответ #43 : 21 Сентября 2011, 12:40:07 »
"А зачем джава, если все на С/С++ написать можно?"
"Бедные быдлокодеры........."

каждому языку - свое приминение. Для десктопа да, java мб и не что надо. Но зато ява рулит в других областях, в которых юзать С++ и QT действительно будет быдло-кодерством=)))
« Последнее редактирование: 21 Сентября 2011, 12:48:02 от ArhimondR »

Оффлайн RazrFalcon

  • Автор темы
  • O_o
  • Старожил
  • *
  • Сообщений: 3129
  • Zombie Mod
    • Просмотр профиля
    • Я на GitHub
Re: Почему так мало программ на java?
« Ответ #44 : 21 Сентября 2011, 12:53:14 »
QT != Qt

мы про десктопы, изначально, говорили...
Gentoo + KDE, Official Windows Hater
Хотите помочь нашей вики: https://help.ubuntu.ru/wiki/fixme

 

Страница сгенерирована за 0.052 секунд. Запросов: 25.