LINUX.ORG.RU
Ответ на: комментарий от anonymous

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

4.2

и только жабу с горем пополам удалось распалаллелить, и то в этом результате можно усомниться

невероятный бред

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

В жабе версии 1.3 еще не было никаких параллельных сборщиков мусора: http://www.reins.altervista.org/java/gc1.3.1.html
В 1.4 появился https://en.wikipedia.org/wiki/Concurrent_mark_sweep_collector
С самого начала были synchronized и volatile, но до версии 1.5, она же 5.0, volatile работало неправильно:
https://www.ibm.com/developerworks/library/j-jtp02244/ - Fixing the Java Memory Model, Part 1
Ну и java.util.concurrent.locks появилось только в 1.5.

Таким образом, можно говорить о том, что до 1.4, вышедшей в 2002 году, многопоточность в жабе была курам на смех, примерно как многопоток в питоне сейчас. Начиная с 1.5, то есть, с 2004 года, можно говорить о серьезной поддержке многопотока - восемь лет с момент релиза 1.0.

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

это как?

Здесь я действительно ошибся - я думал, что когда-то существовала истинно однопоточная жаба. А такой не было, по крайней мере на публике.
Дело в том, что многопоточный доступ к объектам, пусть и якобы несинхронизированный для стороннего наблюдателя, на самом деле подразумевает большое число блокировок самых разных внутренних структур. При чем, в случае жабы это именно многочисленные мелкие блокировки, а не какая-то одна большая - так потоки меньше друг другу мешают, но так же происходит общее снижение производительности.
Serial GC до сих пор является самым быстрым сборщиком - это просто еще раз подтверждает, что многочисленные мелкие блокировки обходятся дороже, чем простая общая блокировка: https://blog.gceasy.io/2016/08/15/questioning-status-quo-serial-gc-not-for-se...

byko3y ★★★★
()
Ответ на: комментарий от byko3y

примерно как многопоток в питоне сейчас.

Стоп, с java 1.2 полноценные потоки, никакого GIL и зеленых, какой питон?

Я не понял что в Lock такого особенного? Просто помогает избегать вложенных блоков синхронизации.

volatile работало неправильно:
https://www.ibm.com/developerworks/library/j-jtp02244/ - Fixing the Java Memory Model, Part 1

Я не увидел ошибки, там говорится что volatile раньше нельзя было использовать как флаг готовности объекта, потому как состояниях других полей, не помеченные как volatile, могли отличаться от потока к потоку, т.к. изменения non-volatile могут быть не видны всем потокам сразу. А теперь в JMM добавили контракт, что если поток1 пишет в volatile поле, а поток2 читает значение этого поля, то изменениях оставшихся non-voatile полей становятся видимыми для читающего потока. А если поток3 не проверит volatile то у него могут быть не видны последние изменения в non-volatile полях.

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

P.S. По поводу контракта с volatile я не знал, я кажется прокачал скил для ответа по поводу volatile на интеврью, теперь еще буду про JMM добавлять. Чтож спасибо :)

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

Первый вопрос. Ты можешь пояснить о чем ты говоришь в приведенной цитате? Вот есть у нас T1 аксессает поле P1 на объекте O1 желая его прочитать. T2 у нас отсутствует (однопоточная программа). Что за блокировки у нас тут будут конкретно и сколько мы по твоей оценке теряем в сравнении, например, с аналогичным С кодом?

Второй вопрос. Ты утверждал, что Java в свое время проектировалась якобы как «изначально спроектированы под одно ядро» (что бы это ни значило) и потому якобы «не способны показать роста производительности на нескольких ядрах». Далее ты говоришь о многопоточности в увязке с GC. У меня есть программа program1, она использует 4 ядра и дает результат за 1 секунду. Каким образом и сколько моя программа теряет от того, что Java «изначально спроектированы под одно ядро» и как это связано с GC?

mxrd2
()
Ответ на: комментарий от Aber

Стоп, с java 1.2 полноценные потоки, никакого GIL и зеленых, какой питон?

В питоне тоже есть различной хреновости варианты выполнения нескольких потоков - об этом я и писал. Кстати да, спасибо за инфу - действительно, в жабе до 1.2 были зеленые потоки.

Я не понял что в Lock такого особенного? Просто помогает избегать вложенных блоков синхронизации.

А что в нем особенного? Или ты про мое упоминание java.util.concurrent.locks? До этой штуки ты мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Я не увидел ошибки, там говорится что volatile раньше нельзя было использовать как флаг готовности объекта, потому как состояниях других полей, не помеченные как volatile, могли отличаться от потока к потоку, т.к. изменения non-volatile могут быть не видны всем потокам сразу

Эта особенность модификатора volatile, скопированная из C, делала его потрясающе бесполезным.

В сях таких контрактов нету, там все зависит от железа

В Си ты можешь добавить

asm volatile ("" : : : "memory");"
и проблема будет решена на уровне скомпилированного кода - хоть это и убого. В жаве до 1.5 эта проблема простого решения не имела. Атомарные операции (load/store, lock cmpxchg) содержат в себе барьеры и решают проблему порядка операций, но являются достаточно тяжелыми, чтобы в Си нужно было целенаправленно руками их вызывать.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

в жабе до 1.2 были зеленые потоки.

Там с 1.1 реальные треды. Это 1997 год.

mxrd2
()
Ответ на: комментарий от byko3y

java.util.concurrent.locks? До этой штуки ты мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Что ты хотел сказать тут? Как-то непонятно ты выразился.

mxrd2
()
Ответ на: комментарий от byko3y

до 1.4, вышедшей в 2002 году, многопоточность в жабе была курам на смех, примерно как многопоток в питоне сейчас

synchronized wait/notify были первой версии 1996

В 1.1 1997 уже были реальные треды (возможно только под солярис на сановских серверах, потому как на PC это куда менее актуально было в те годы)

до 1.4, вышедшей в 2002 году, многопоточность в жабе была курам на смех, примерно как многопоток в питоне сейчас

Он уже в 1997 был нормальным. О чем ты говоришь? В питоне в 2019 нет того, что в джаве в 1997. Я не топлю за джаву. Но как это сравнимо? Где тут «курам на смех»?

mxrd2
()
Ответ на: комментарий от mxrd2

В питоне в 2019 нет того, что в джаве в 1997

В корабле 2019 года нет того, что было в самолете 1997 года.

Еще раз. Вы тут что самые умные?

dem ★★
()
Ответ на: комментарий от mxrd2

Вот есть у нас T1 аксессает поле P1 на объекте O1 желая его прочитать. T2 у нас отсутствует (однопоточная программа). Что за блокировки у нас тут будут конкретно и сколько мы по твоей оценке теряем в сравнении, например, с аналогичным С кодом?

Если бы у тебя был такой код на Си, то никаких блокировок бы не было. Однако же, JVM - это сильно больше, чем «выполнить разыменование указателей». Грепни сорцы хотспота по MutexLocker: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/archive/tip.tar.bz2
Конечно, добрая половина из блокировок будут в сборщиках мусора.
Оценить, сколько теряется, я не могу, а тесты ты и без меня можешь нагуглить.

https://www.javacodegeeks.com/2015/09/testing-concurrent-applications.html#te... - вот хорошие графики
https://stackoverflow.com/questions/19901915/why-single-thread-is-faster-than...
https://stackoverflow.com/questions/3820647/multithreading-not-faster-than-si...
https://pdfs.semanticscholar.org/dd54/a215131c5eacd997708c5c4612345fe989c7.pdf - Интересное сравнение многопотока с многопроцессом, которые идут почти ноздря в ноздрю.

Ты утверждал, что Java в свое время проектировалась якобы как «изначально спроектированы под одно ядро» (что бы это ни значило) и потому якобы «не способны показать роста производительности на нескольких ядрах»

У жабы есть фундаментальная проблема, которая упомянута в pdf выше, и которая не даст жабе расти вверх с увеличением числа потоков - это наличие единой кучи объектов, обслуживание которой становится дороже с каждым потоком. Этой проблемы не стояло в 90-х годах, но она встает сейчас. Я уже упоминал некоторое время назад работы по этой проблеме, и с тех пор ничего не поменялось:
https://www.cs.kent.ac.uk/pubs/2005/2228/content.pdf - A fast analysis for thread-local garbage collection with dynamic class loading (2005)
https://kar.kent.ac.uk/57582/ - A study of thread-local garbage collection for multi-core systems (2016)

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

java.util.concurrent.locks? До этой штуки ты мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Что ты хотел сказать тут? Как-то непонятно ты выразился.

Ты хочешь защищить доступ к полю объекта. А можешь защитить только весь объект - да, это мельче, чем GIL, но все же, довольно крупный уровень.

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

В 1.1 1997 уже были реальные треды (возможно только под солярис на сановских серверах, потому как на PC это куда менее актуально было в те годы)

Да, ты прав, на солярке уже в 1.1 были родные потоки: https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/

В питоне в 2019 нет того, что в джаве в 1997.

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ты хочешь защищить доступ к полю объекта. А можешь защитить только весь объект

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

Object field = new Object();
Object lock = new Object();

public void test() {
    synchronized (lock) {
        field.foobar = foobarbaz;
    }
}

Ты кукаретик похоже просто.

mxrd2
()
Ответ на: комментарий от mxrd2

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

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

Когда ты пишешь код с блокировками, то для исключения дэдлоков нужно выполнять простое правило - в один момент времени должна быть взята только одна группа блокировок, и эта же группа будет всем скопом отпускаться. То есть, должно быть что-то вроде synchronized (lock1, lock2) - но и такая конструкция создает неудобство в достаточно сложной программе. Зато tryLock и прочие позволяют реализовать безопасные блокировки, да еще и с кооперацией для исключения голодания - потому я и пишу, что только с 1.5 в жаве появились серьезные инструменты многопоточности.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ты не прав.

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

В реальности же 1996 год (релиза первой версии Java) совпадает с Sun Ultra Enterprise 6000 is a cabinet-housed data center server with up to 30 processors и Sun Workstation Ultra 4000 (Up to 14 UltraSPARC СPUs).

Ты утверждал, что в джаве многопоточность

курам насмех
изначально спроектированы под одно ядро
примерно как многопоток в питоне сейчас
[джаву] c горем пополам удалось распалаллелить, и то в этом результате можно усомниться

В реальности же ее изначально проектировали как многопоточную. О чем свидетельствует synchronized как часть синтаксиса с 1996 версии 1. Кроме того, там нативные треды с 1997 года.

мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Выяснилось, что ты не понимаешь семантики ключевого слова (или конструкции) synchronized.

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

Выяснилось, что ты ошибся

Ты не прав. Санки действительно продавали многоПРОЦЕССОРНЫЕ системы, но многопоточная производительность у них была ужасная

У меня вопрос. Если ты говоришь что «плохая» у сановских машин, ты должен как-то обосновать это. Если 4 или 30-процессорная машина сана была плохая (для пускания на ней жавы). То какая была хорошая? Мне вот самому любопытно, тот же x86 что мог предложить в плане многопроцессорности тогда джаве? PC на с ранней версией NT были бы лучше по-твоему под джаву, как оцениваешь?

--

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

mxrd2
()
Ответ на: комментарий от mxrd2

Ты зачесывал что-то про процессоры того времени, про «соответствуют развитию железа». Что мол якобы тогда и джаву делали однопоточную из-за этого.
В реальности же 1996 год (релиза первой версии Java) совпадает с Sun Ultra Enterprise 6000 is a cabinet-housed data center server with up to 30 processors и Sun Workstation Ultra 4000 (Up to 14 UltraSPARC СPUs).

И в каком месте тут противоречие? Да, Сан делал одноядерные процессоры, и до 2005 года развивал именно одноядерные процессоры.

Выяснилось, что ты не понимаешь семантики ключевого слова (или конструкции) synchronized

Я не скрываю, что я не пишу на жаве. Многие сидящие здесь в курсе - просто не рискуют возразить.

Выяснилось, что ты ошибся

И я это подтвердил - однопоточной жабы никогда не существовало.

Если ты говоришь что «плохая» у сановских машин, ты должен как-то обосновать это. Если 4 или 30-процессорная машина сана была плохая (для пускания на ней жавы). То какая была хорошая? Мне вот самому любопытно, тот же x86 что мог предложить в плане многопроцессорности тогда джаве? PC на с ранней версией NT были бы лучше по-твоему под джаву, как оцениваешь?

Презенташка 1995 года в духе «потоки - зло, не пишите многопоточных приложений»: https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
Кто автор презентации? John Ousterhout из САН МАЙКРОСИСТЕМ. Человек из Сан пишет, цитирую: «avoid threads wherever possible» - что прямо противоречит бредятине, которую ты мне втираешь про «Сан продвигал многопоточные технологии».
В 90-х многопоточные технологии никто не развивал, под них не делали ни языков, ни железа, и жава была сделана в то время. Потоки в жаве сделаны скорее как маркетинговый ход, вроде «конечно же, вы не будете использовать потоки, но если вдруг у вас возникнет острая необходимость все-таки потоки сделать - у нас есть некоторые базовые примитивы для поддержки онной». Это примерно как продавать вазелин и наушники в супермаркете - человек пойдет в этот супермаркет, потому что там «всё есть», и неважно что выбор мал, что качество низкое.
Менеджер-заказчик в этом плане мало чем отличается от домохозяйки, потому что приходит на рынок, где является не специалистом, а просто мимопотребителем, которому нужно впарить надежные и стабильные технологии, высокую производительность, чуткую поддержку, перспективность, проверенные решения, признанные лидерами бизнеса - и не важно, что за этим кроется vendor-lock, который высосет из тебя последние соки, а если у тебя получится каким-то образом выжить - будет пить кровь еще многие годы.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Забыл упомянуть доки к первым JDK:
https://www.cs.princeton.edu/courses/archive/fall97/cs461/jdkdocs/
https://www.cs.upc.edu/lclsi/Manuales/java1.2/index.html
Здесь видно, что про существование потоков в жаве предпочитают не говорить.

К слову об UltraSPARC - начало разработки многоядерных версий подозрительно совпадает с разработкаой версии жавы 1.5.

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

поле в тэг-памяти вполне защищаемо - однако тэг-память не то что может взлететь при современном прогрессе - ака не ясности сколько же битиков хватит для всей номенклатуры продукции всего народного хозяйства

anonymous
()
Ответ на: комментарий от byko3y

Ну вот они выпустят в в след году и всё станет хорошо.

В 90-х многопоточные технологии никто не развивал, под них не делали ни языков, ни железа

ни железа

Я тебе показал вроде бы уже.

Все 90е это как раз бум разработки и продажи многопроцессорного железа. Все этим занимались.

Я тебе показали их серверы с десятками процессоров.

У них в 1992 году 4 процессора в десктопе было.

Ты отрицаешь что все это существовало? Ты совсем дурачок что ли?

mxrd2
()
Ответ на: комментарий от byko3y

https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf

Аахах. Да ты же вообще дно оказывается! Ты пытаешься закидать ссылками, но сам не понимаешь что там написано. Там всё это по сути «Why Threads Are Hard».

Кроме того саму презентацию мы не видели. Мы видим только слайды. В духе «не надо X пихать там, где он не нужен только потому что теперь так можно, круто и модно». Контекст может быть совершенно другой в духе: во времена многопроцессорного железа и повсеместного внедрения многопоточности, давайте поговорим о трудностях с которыми мы сталкиваемся .

Threads not well supported: Hard to port threaded code (PCs? Macs?).
Standard libraries not thread-safe.
1995

Это очевидно не про Java.

Too hard for most programmers to use.
Even for experts, development is painful.
Must coordinate access to shared data with locks.
Forget a lock? Corrupted data
Circular dependencies among locks.

Это о трудностях программирования же. Больше ни о чем. Такого полно. Как это относится к теме, и к тому что ты обосрался? Т.е. что и как это подтверждает?

Fine-grain locking increases complexity, reduces performance in normal case.

И, что? Это неизбежно, волшебства не бывает. Именно над этим их железячники и работают, а сан зарабатывает деньги. Ты пытаешься так себя спасти? Ты совсем клоун? Как это иллюстрирует твои доводы и опровергает реальность?

Should You Abandon Threads?
No: important for high-end servers (e.g. databases).

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

-

Многопоточность в Java уже была, а Sun - это вендор много-много-много-процессорного железа. Это невозможно отрицать же. Всё это делалось совместно, чтобы помогать продаже сановского железа, синергия так сказать.

mxrd2
()
Ответ на: комментарий от byko3y

однопоточная жаба работает значительно быстрее.
изначально спроектированы под одно ядро
Ты не прав. ... продавали многоПРОЦЕССОРНЫЕ системы, но многопоточная производительность у них была ужасная
К слову об UltraSPARC - начало разработки многоядерных версий подозрительно совпадает с разработкаой версии жавы 1.5.
И в каком месте тут противоречие? Да, Сан делал одноядерные процессоры, и до 2005 года развивал именно одноядерные процессоры.

Ты оказывается совсем идиот.

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

Жаль времени на тебя потраченного.

mxrd2
()
Ответ на: комментарий от byko3y

Я не скрываю, что я не пишу на жаве. Многие сидящие здесь в курсе - просто не рискуют возразить.

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

Я же вообще себя крутым экспертом не считаю. У меня на джаве суммарный опыт программирования месяца 3 наверное.

То есть ты идиот не из-за того, что у тебя опыта программирования Java нет.

mxrd2
()
Ответ на: комментарий от mxrd2

Жаль времени на тебя потраченного.

Мил человек, 99% времени на лоре является потраченным впустую. Тебя удивляет, что вы со своим коллегой не попали в 1%?

anonymous
()
Ответ на: комментарий от Aber

P.S. По поводу контракта с volatile я не знал, я кажется прокачал скил для ответа по поводу volatile на интеврью, теперь еще буду про JMM добавлять. Чтож спасибо :)

Это всё описано в обычной документации по Java.

mxrd2
()
Ответ на: комментарий от mxrd2

Он мне не коллега. Почитай что он пишет, и что я пишу.

Коллега по форуму, как минимум. 🤡

anonymous
()
Ответ на: комментарий от byko3y

https://www.cs.upc.edu/lclsi/Manuales/java1.2/index.html
Здесь видно, что про существование потоков в жаве предпочитают не говорить.

Это _ перечень _ документации. Ты читать не умеешь что ли? Или не понимаешь что за ссылку даешь?

Здесь видно, что про существование потоков в жаве предпочитают не говорить.

http://web.mit.edu/java_v1.0.2/www/tutorial/java/threads/TOC.html

Здесь видно, что про существование потоков в жаве предпочитают не говорить.

http://web.mit.edu/java_v1.0.2/www/apibook/javab1.htm

Ты извиняться-то будешь?

Здесь видно, что про существование потоков в жаве предпочитают не говорить.

Concurrent Programming in Java: Design Principles and Patterns
Doug Lea.
Addison-Wesley 1996 ISBN:0201695812
https://dl.acm.org/citation.cfm?id=548105

mxrd2
()
Ответ на: комментарий от mxrd2

Ну вот они выпустят в в след году и всё станет хорошо.

Публичная альфа жабы была в 1995 году, в этом же году появилась, например, очевидно проплаченная статья «Ten Best Products of 1995» в Таймз с упоминанием жабы как одного из прорывов года.

Все 90е это как раз бум разработки и продажи многопроцессорного железа.

Мне кажется, что ты до сих пор не понял проблемы многопроцессорного железа, хоть я тебе ее уже и описал - процессоры замедляются при обращении к памяти, используемой другим процессором. Это и значит ориентированность на многопроцессовость, а не многопоточность. По поводу же многопоточности Сан придерживался позиции «вы ее не хотели, она вам не нужна».

У них в 1992 году 4 процессора в десктопе было.

SPARCstation 10? Это была не ПК, это был workstation, что упомянуто в самом названии - те самые workstation, на которые нынче ставят зеоны и тредриперы.

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

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

Ты пытаешься хвататься за последнюю соломинку. Можно предположить, что презентация отличалась от слайдов, может на презентации ни слова не было сказано из слайдов, но это бредовое предположение. Вывод был вполне конкретный - «avoid threads wherever possible».

Threads not well supported: Hard to port threaded code (PCs? Macs?).
Standard libraries not thread-safe.
1995

Это очевидно не про Java.

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

Это о трудностях программирования же. Больше ни о чем. Такого полно. Как это относится к теме, и к тому что ты обосрался? Т.е. что и как это подтверждает?

Это относится к теме о том, что ты сам обосрался.
Презентация описывает трудности, более специфичные для C++, и объясняется, почему эта модель плохо подходит для многопоточного программирования, и лучше подходит для событийной модели. Модель классов взята за фундамент жавы, что автоматически делало жаву плохо подходящей для многопоточного программирования, о чем прекрасно знали в Сане. Но фундаментальная задача состояла в том, чтобы впарить свои решения, а не продвигать какой-то абстрактный прогресс технологий.

Should You Abandon Threads?
No: important for high-end servers (e.g. databases).

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

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

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

В питоне в 2019 нет того, что в джаве в 1997. Я не топлю за джаву

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

kawaii_neko ★★★★
()
Ответ на: комментарий от anonymous

Тебе объяснить разницу между workstation и personal computer в контексте 90-х годов? Workstation подразумевает инженерную или научную деятельность, в частности, 3D визуализацию, в то время как PC предназначен для пользования рядовым дауном, часто даже без сетевого подключения.

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

У меня на джаве суммарный опыт программирования месяца 3 наверное.

У меня и того меньше. Ты пытаешься аппелировать к моей неточности в мелочах реализации, чтобы скрыть тот факт, что ты обосрался в глобальной картине.

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

Здесь видно, что про существование потоков в жаве предпочитают не говорить.

http://web.mit.edu/java_v1.0.2/www/tutorial/java/threads/TOC.html

Здесь видно, что про существование потоков в жаве предпочитают не говорить.

http://web.mit.edu/java_v1.0.2/www/apibook/javab1.htm
Ты извиняться-то будешь?

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

Concurrent Programming in Java: Design Principles and Patterns

Если бы книга называлась «Concurrent Programming in Brainfuck» - что бы это значило? Что бреинфак - хороший инструмент для написания многопотока? Что разработчики бреинфака планируют создание железа для многопоточных серверных приложений? Дуглас Ли - это левый чел, который всю жизнь был повернут на параллелизации, и не преминул возможностью написать книгу на хайповую тему - а жава была люто хайповой в 96-ом году. Реальная многопоточность в жаве была внедрена при помощи JSR-166, к разработке которого пригласили того самого Дугласа Ли, и под которым выпустили жаву 1.5 с настоящей многопоточностью под готовые двухядерные процессоры UltraSPARC IV, а в следующем году и четырехядерные UltraSPARC T1.

byko3y ★★★★
()
Ответ на: комментарий от mxrd2

Это всё описано в обычной документации по Java.

Ответ просто супер, жаль что таких умников при поиске сотрудников не найти.

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

Aber ★★★★★
()
Ответ на: комментарий от byko3y

очевидно проплаченная статья «Ten Best Products of 1995» в Таймз с упоминанием жабы как одного из прорывов года

но ведь, она и правда оказалась прорывом года?

next_time ★★★★★
()
Ответ на: комментарий от next_time

но ведь, она и правда оказалась прорывом года?

боюсь вмешаться в спор java-апологетов про Go, но прорывом тогда (1995) была jvm как технология а не java как язык.

помню те годы и jvm была чем-то новым, шустрая вирт.машина. А java тех лет - просто язык.

ps/ да и положа руку на сердце, яву вытащила исключительно java-server-page, иначе при всех феньках она бы сдохла.

MKuznetsov ★★★★★
()
Ответ на: комментарий от next_time

очевидно проплаченная статья «Ten Best Products of 1995» в Таймз с упоминанием жабы как одного из прорывов года

но ведь, она и правда оказалась прорывом года?

Нужно понимать причину и следствие - они идут рядом, потому что одно вызвало другое, но второго без первого бы не было. Mesa/Cedar уже были, как и кучу других язычков с разной степенью платформозависимости. Qt в мае 1995 года была первый раз релизнута. Основным конкурентом жавы я бы назвал кобол, который тоже был кросс-платформенным, но разработан на 35 лет раньше.
Напомню, что в жаве изначально не было хотспота, то есть, это было довольно медленно двигающееся поделие на виртуальной машине, исполняющей байткод, в отличие от Cedar, который компилировался в нативный код для SPARC.

Теперь, на фоне всего этого, скажи мне: что прорывного было в жаве? Кроссплатформа? Нет. Безопасное выполнение? Нет. ООП? Опять нет. Сан позаимствовал все коммерчески успешные (по их мнению) фичи других языков, чтобы сделать всепоглощающую технологию, которая должна была бы захватить мир. Особенно хайповым было ООП, на который мастурбировали все институтские профессора того времени.
Сан планировал, что все браузеры должны были работать на жаве, сервера на жаве, десктопные поделия на жаве - а Сан будет держать всех за яйца проприетарными технологиями и лицензиями. Ну примерно как MPEG Audio Layer III, который, вполне возможно, до сих пор побирает разрабов лицензионными сборами.
Чтобы провернуть этот коварный план, Сан должен был убедить всех, что жава - это решение всех проблем, которые вы до жавы решали другими инструментами и не жаловались. У жавы не было никаких прорывных технологий - их выдумали, высосали из пальца. Дальше работает элементарный маркетинг: крик из каждого утюга про «открытие века», рассказы про «лидеры рынка уже с восьмедисятых перешли на жаву, и с тех пор их бизнес пошел вгору» - короче говоря, типовой бесплатный для обывателя концерт, проводимый за счет рекламодателя.

Итого, как бы это странно не было, самым привлекательным свойством жавы было кол-во денег, вброшенных в ее раскрутку. Конечно, технология должна быть не совсем уж полным говном - остальное уже не важно. Типовой заказчик, как я уже писал, не разбирается в IT, а просто хочет быстро, дешево, и надежно. Он открывает Times - а там рассказ о том, что найдено решение всех проблем быстро, дешево и надежно - вот, как раз то, что нужно нашей фирме. Когда же заказчики привыкли к жаве, когда разрабы научились в жаву, тогда имидж технологии начинает работать вместо каких бы то ни было преимуществ этой технологии.

Также замечу, что если бы не возник C#/.NET, то жава продожала бы свое медленное развитие с минимальными дополнениями для поддержки новых технологий. Но возник проклятый C#, который задавал планку качества, в котором новшества вводились раньше и были реализованы лучше, чем в жаве. Если бы разрабы не подсуетились, то C# проник бы на другие платформы и уверенно соревновался бы с жавой в тех же нишах.

byko3y ★★★★
()
Ответ на: комментарий от MKuznetsov

боюсь вмешаться в спор java-апологетов про Go, но прорывом тогда (1995) была jvm как технология а не java как язык.

https://en.wikipedia.org/wiki/BCPL - 1967, o-code VM
https://en.wikipedia.org/wiki/Pascal_(programming_language)#Pascal-P - 1973, p-code VM.
https://en.wikipedia.org/wiki/Pascal_(programming_language)#Pascal-S - 1975, p-code VM.
https://en.wikipedia.org/wiki/UCSD_Pascal - 1978, p-code VM.
https://en.wikipedia.org/wiki/Z-machine - 1979
https://dl.acm.org/citation.cfm?id=800542 - 1984, Smalltalk-80 с JIT, который, предположительно, был создан по мотивам разработанного еще в 1969 году JIT компилятора для экспериментального языка LC ( http://eecs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/JustInTimeCom... )
https://en.wikipedia.org/wiki/Self_(programming_language) - 1987, развитие смолтолка.

Как вы видите, JVM была не прорывом, а засохшим говном мамонта.

да и положа руку на сердце, яву вытащила исключительно java-server-page, иначе при всех феньках она бы сдохла.

Еще жаву опенсорснули, когда запахло жареным - иначе она бы тоже сдохла.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

кобол, который тоже был кросс-платформенным

Кросс-платформенным в том же смысле и виде что и Java? Разве?

anonymous
()
Ответ на: комментарий от byko3y

то C# проник бы на другие платформы

Как бы он проник и зачем? И почему же не проник-то? Java на стояла не пускала что ли?

anonymous
()
Ответ на: комментарий от anonymous

кобол, который тоже был кросс-платформенным

Кросс-платформенным в том же смысле и виде что и Java? Разве?

Нет, кобольная кроссплатформа больше была похожа на Qt.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

то C# проник бы на другие платформы

Как бы он проник и зачем? И почему же не проник-то? Java на стояла не пускала что ли?

В сервера, где окопалась жава, поскольку это последний рубеж обороны - Java EE. ASP.NET уже есть на веб-серверах, но его присутствие довольно скромно. Серьезным ограничением .NET была привязка к винде, но в свете развития моно и эта проблема теряла значение. Однако же, сервера на никсах - это довольно большая дистанция от .NET, и преодолеть ее непросто. Если бы жава стояла на месте, не заимствовала из шарпа вывод типов, wait/async, лямбды, то рано или поздно это отставание стало бы серьезно заметно, и склонило чашу весов на сторону .NET.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

и склонило чашу весов на сторону .NET.

Но для этого нужно было чтобы дотнет на никсах был, но его же не было.

anonymous
()
Ответ на: комментарий от byko3y

кобол, который тоже был кросс-платформенным

Кросс-платформенным в том же смысле и виде что и Java? Разве?

Нет, кобольная кроссплатформа больше была похожа на Qt.

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

anonymous
()
Ответ на: комментарий от byko3y

Чтобы провернуть этот коварный план, Сан должен был убедить всех, что жава - это решение всех проблем

Microsoft хотел уничтожить сановую жаву. Он в твоем понимании положительную роль играл?

anonymous
()
Ответ на: комментарий от anonymous

и склонило чашу весов на сторону .NET.

Но для этого нужно было чтобы дотнет на никсах был, но его же не было.

https://en.wikipedia.org/wiki/Mono_(software) - 2004 год. Конечно, он серьезно отставал от виндовой реализации, но все же. Грубо говоря, на два года позже появлялось в моно то, что уже было в .NET.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

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

Значимой? Знаешь, «черный квадрат» малевича кто-то называет значимым произведением - а я это называю маркетингом и стёбом над умственно отсталыми. В IT было создано великое множество разных ЯП, какие-то из них даже были получше жавы - они были значимыми, но популярной стала только жава. В плане популярности имеет значение только кол-во бабла, которое стоит за технологией.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

про малевича я согласен.

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

anonymous
()
Ответ на: комментарий от anonymous

Чтобы провернуть этот коварный план, Сан должен был убедить всех, что жава - это решение всех проблем

Microsoft хотел уничтожить сановую жаву. Он в твоем понимании положительную роль играл?

Мне глубоко все равно, положительная у него там роль или отрицательная. IT скатилось в говно - это не та индустрия, в которую я хотел вкатиться в детстве, когда мечтал стать программистом: индустрия уничтожила любую возможность творчества, создания новых языков, технологий, разнообразие реализаций софта. Теперь и Linux уже ни разу не свободный, а находится под контролем ограниченного круга корпораций, и в веб браузерах утверждена диктатура трех браузеров - хоть вы и можете скачать исходники двух из них.

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

anonymous
()
Ответ на: комментарий от byko3y

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

что индустрия уничтожила такого, из-за чего ты не можешь заниматься творчеством и делать новые языки? сейчас самое лучше время имхо

anonymous
()
Ответ на: комментарий от anonymous

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

Сейчас подобную коболу кросс-платформенность можно наблюдать в JS. Просто в жаве ты компилируешь байткод, и из-за этого получаешь лютые тормоза при запуске. Так же можно передавать код кобола по сети, компилируя его на целевом устройстве для запуска.

и еще стандартная библиотека абстрагирующая операционную систему

В коболе, Qt, и JS та же ситуация.

byko3y ★★★★
()
Ответ на: комментарий от Aber

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

anonymous
()
Ответ на: комментарий от byko3y

Сейчас подобную коболу кросс-платформенность можно наблюдать в JS.

это как? просто распространение в исходниках мол запускайте на любой архитектуре что ли? ну так и BASIC крутая кросс-платформенность тогда. да и операционку браузерному js не приходится абстрагировать.

anonymous
()
Ответ на: комментарий от anonymous

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

Жава приняла ответные меры в виде открытия исходников и улучшения языка. Присутствие дотнета на никсах есть, но оно довольно скромное:
https://www.mono-project.com/docs/about-mono/showcase/companies-using-mono/
MS не будет бороться за никсы, потому что эта игра не стоит свеч - нет смысла бороться за нишу, которая уже давно контролируется конкурентом, в которую конкурент ввалил кучу ресурсов. Сан завоевал в девяностых годах довольно просторную нишу, и входить туда вторым можно только если ниша расширяется. Дотнет на винде был достаточно просторной нишей, на самом деле, но именно как windows-специфичный инструмент, c WPF и прочими плюшками, которые на форточках выглядят получше жавы.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

что индустрия уничтожила такого, из-за чего ты не можешь заниматься творчеством и делать новые языки? сейчас самое лучше время имхо

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

byko3y ★★★★
()
Ответ на: комментарий от anonymous

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

Ты сейчас описал типового HR-а. Вот типовая история:
https://coderanch.com/t/448752/java/concurrent-access-synchronized-unsynchron...
Собеседующий задал вопрос «может ли несинхронизированный метод исполняться одновременно с синхронизированным?», на что испытуемый ответил «да, может». Правильный ответ? Не тут-то было. Собеседующий утверждал, что ответ неправильный, и несинхронизированный метод не может выполняться одновременно с синхронизированным. В итоге чел собеседование не прошел.

Или вот эта история: Нужен ли я работодателю? (комментарий)

C/C++

Лично я резюме с такой строчкой сразу отправляю в корзину. Если человек после четырех лет работы так и не осознал что C и C++ — это разные языки, то лучше с ним дел не иметь. Понятно, конечно, что скорее всего это означает просто «С++», а чистый C человек просто в глаза не видел, но подозревает что там примерно то же самое, но даже такая интерпретация говорит не в пользу кандидата.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

просто распространение в исходниках мол запускайте на любой архитектуре что ли?

В финансовом секторе и оборонке весь софт только с открытыми исходниками.

ну так и BASIC крутая кросс-платформенность тогда.

На уровне базовых конструкция языка васик кроссплатформенен. На уровне стандартной библиотеки - нет.

да и операционку браузерному js не приходится абстрагировать.

Чиво? Как это не приходится абстрагировать? Сейчас бы сидели тут какие разрабы фаерфокса или хрома - они бы тебе рассказали, сколько десятков тысяч человекочасов им пришлось не абстрагировать браузер от ОС.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

I know that feel bro. Хотя иначе быть и не должно. Рыночек порешал тебя. Кто обязан тебя кормить, если с твоей поделки нет дохода прямо сейчас?

anonymous
()
Ответ на: комментарий от anonymous

I know that feel bro. Хотя иначе быть и не должно. Рыночек порешал тебя. Кто обязан тебя кормить, если с твоей поделки нет дохода прямо сейчас?

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

Во-вторых, у меня есть знания, за которые люди готовы отдавать квартиры и машины. Я умею творить чудеса, но я не умею убеждать и ублажать слепых на голову людей в том, что это чудо - реально; и я не Саи Баба, и не транснациональная корпорация - у меня нет красивого и обманчивого имиджа, дающего возможность втирать человеку что угодно.

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

пре: Каждому своё

вы же не частицы с полуцелым(?!) спином - что бы выталкивать с/

была бы суперпозиция двух васян_функция_хэвисайда_в_кодинге_остальное_ноль

а так есть васянТМ и Царь

anonymous
()
Ответ на: комментарий от byko3y

не умею хитростью убеждать людей отдать мне их вещи.

Что хитрого в том, чтоб прикрутить к своему проекту донатилку, периодически выпускать статьи, релизы, обзоры своего пректа на реддите и форониксе? Если и это тебе не поможет, то твой проект, возможно, действительно *не нужен*.

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Что хитрого в том, чтоб прикрутить к своему проекту донатилку, периодически выпускать статьи, релизы, обзоры своего пректа на реддите и форониксе? Если и это тебе не поможет, то твой проект, возможно, действительно *не нужен*.

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

byko3y ★★★★
()
Ответ на: комментарий от hakavlad

Что хитрого в том, чтоб прикрутить к своему проекту донатилку, периодически выпускать статьи, релизы, обзоры своего пректа на реддите и форониксе? Если и это тебе не поможет, то твой проект, возможно, действительно *не нужен*.

Кстати, на эту тему вспомнился знаменитый лохотронщик Илон Маск. Недавно всплыли откровения бывшего сотрудника Теслы, у которого закончилась NDA, и мы узнали, что происходит по ту сторону рекламных лозунгов балабола Илонюшки: https://twitter.com/atomicthumbs/status/1032939617404645376/photo/1 .

byko3y ★★★★
()
Ответ на: комментарий от byko3y

А был бы умным - молчал бы?

Требовал пруфы.

Зачем мешать чужому бизнесу, правильно?

Так ты осознаешь что мешаешь? К тому же не удостоверившись? Вредитель что-ли или ватник (если это не одно и то же)?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

А был бы умным - молчал бы?

Требовал пруфы.

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

Так ты осознаешь что мешаешь? К тому же не удостоверившись? Вредитель что-ли или ватник (если это не одно и то же)?

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

byko3y ★★★★
()
Ответ на: комментарий от Deleted

Я думал ты умнее.

Похоже очередной поехавший...

foror ★★★★★
()
Ответ на: комментарий от Deleted

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

anonymous
()
Ответ на: комментарий от hakavlad

Прикручивая «донатилку» (а так же, принимая инвестиции, выходя на IPO и т.д.), ты сильно ограничиваешь свою свободу. Без всего этого ты руководствуешься исключительно своими воззрениями, а придётся всё время оглядываться на спонсоров. Не зря многие художники / писатели практиковали какие-то вообще левые ремёсла как основной источник дохода, а искусством занимались в свободное время.

ComradeMajor
() автор топика
Ответ на: комментарий от anonymous

В чем вредительство, болезный?

Незнаю, да мне и не важно. Просто забавно было что чел так свои действия воспринимает.)

Кстати, такая лексика (вата, вредители)

Не нравится?) ватник шоле? 😁

Deleted
()
Ответ на: комментарий от byko3y

Тоесть пруфа нет. Ну ок. Зато ты следишь за ним... И разоряешь... Ой вей, здесь санитары нужны.

Deleted
()
Ответ на: комментарий от hakavlad

придётся всё время оглядываться на спонсоров

это вовсе не обязательно

У тебя етсь прохладные истории, которые могли бы показать другой подход? По моим наблюдениям донаты реально прокатывают только если человек специально уделяет время окучиванию донатеров.

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.