OSDev

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

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

Что ж, хорошо. Хотя почему-то везде где я видел работу с JNI, она делалась как-то криво. Раз можно прямо - отлично, этот вопрос снимается. Хотя работа со структурами (полями классов) остается под вопросом, а также работа с массивами нетривиальных типов (классов).

Си вышел, да не очень. Си тоже далеко не является идеалом.
Писать системные вещи на чистом Си как правило глупо и костыльно, а писать на Си под слабые МК, к примеру, на какие-нить 8-битные 10-рублевые схемки, зачастую просто невозможно, и приходится использовать ассемблер.
Так что это не C++ вышел за свои пределы, а программистам стало лень учить другие языки, в то время как мощность процессоров позволяет реализовывать все на C++, хоть и медленно (относительно ассемблера), из-за чего и стали писать на си все, что возможно. Но вот по кодам, выигрывавшим соревнования Zealint'а понятно, что даже в математике чистый си мало применяется.
Скажем так. Ассемблер в общем случае может быть оптимален. C++ - это первый уровень неоптимальности (т.к. это ЯВУ, имеет ООП и все дела). Java - уже второй уровень (из-за сборщиков мусора, безопасности и т.д.).
Когда-нибудь, возможно, у процессоров будет хватать мощности на выполнение дважды неоптимального кода, и тогда Java действительно можно будет кое-как применять для тех областей, где она сейчас бесполезна. Но постойте, если у процессора избыток мощности, то почему бы не направить ее на решение более сложных задач, вместо того, чтобы решать существующие неоптимальным методом? Поэтому я не считаю, что так должно быть. Не вижу ничего хорошего в том, что Intel выпускает очередной супермощный процессор, после чего набегают индусы и тратят всю его мощность на выполнение каких-то ненужных вещей.
И я более чем уверен, что когда мощность процессоров будет позволять, в моду войдут средства визуального программирования, когда интерфейс просто рисуется мышкой, а весь код до последней команды задается всякими "мастерами" создания кода. Прототипы есть уже сегодня. И когда этот день настанет, на этом форуме (если он будет еще жив) появится человек, который будет заявлять, что Java - прошлый век, а все задачи надо решать на этой новомодной системе, где потыкал мышкой - и всё. Разработка абсолютно безопасна, и делается все очень быстро и легко. Так будет просто потому, что чем меньше знаний требуется для написания кода, тем дешевле соответствующий специалист, а значит, меньше себестоимость продукта.
Только вот в некоторых областях ассемблеру по-прежнему не будет замены. Где-то будет всё еще нужен Си, а где-то - Java с C#-ом.
И я совершенно не понимаю вашего рвения использовать один инструмент для всех целей, в том числе для тех, для которых он не был создан и оптимизирован.

P.S. некоторые знакомые физики, например, обожают маткад. Там ведь тоже свой язык есть, вообще почти скриптовый вроде. Почему обожают? Потому, что чтобы на нем писать, не надо быть программистом вообще: просто записал формулу, и он ее посчитал, да еще и графики построил. Маткад - тоже инструмент, тоже решает свои задачи. И вот объясните этим физикам, что им надо использовать Java, что всё, что им надо, есть в джаве, надо просто немного покодить.

Достало уже.

Я требую доказательств этого обвинения.

С полями да, нужно каждый раз просить разрешения у JVM на "пощупать". Поэтому в случае полей требуется конвертер из объектов в набор массивов. Ну а с массивами уже всё быстро.

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

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

Хорошее там - скорость получения нужной программы. А эффективность да, не очень. Поэтому я и предлагаю вариант умного компилятора, встроенного в ОС на базе Java. Что бы пусть даже индусы под это дело писали, но компилятор бы выжимал из индуистского кода побольше, чем тот же JIT сегодня. Хотя на верхнем уровне, конечно же, алгоритмы нужно уметь правильно выбирать, для начала. Ну да, надеюсь, этим вместо индусов грамотный архитектор занимается.

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

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

Вот вам трудно будет сейчас всё бросить и перейти на Java ? Вот так же и мне, но в другую сторону.

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

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

Вы явно не писали под МК. Никакая "красивая" компиляция не поможет, потому что иногда приходится бодаться за байты и делать какие-то неочевидные переделки алгоритма для скорости, чтобы уложиться на дешевом камне в отведенное время. А уж про Java можно и вовсе забыть, т.к. java требует наличия какого-либо управления памятью, а попытка реализовать такое на слабых МК займет 3/4 памяти кристалла, не говоря уже о том, что резолв java-вызовов (с учетом его ООПшности) на 8 МГЦ процессоре будет занимать, наверно, секунду, а при запуске сборки мусора ее окончания можно вообще не дождаться.

Компилятор не сможет выжать из кода очень много. Если программист не умеет писать код и, образно говоря, делает вместо формулы вычисления результата сотню IF-ов, то никакой компилятор ему не поможет.
Что же касается Java - само наличие сборки мусора резко снижает ее эффективность, потому что сборка мусора - это сначала проход по всем регистрам/стеку с поиском всех объектов и рекурсивным или циклическим проходом по всем их ссылкам, а потом брутфорс таблицы объектов с удалением всего, до чего на предыдущем шаге не дошли. То, что она компилируется в байткод, и только потом JIT-ится в нормальный ассемблер, приводит к тому, что JIT уже не сильно много знает о структуре изначального кода, а перевод одного ЯНУ в другой не может повысить качество кода. Единственный вариант однозначно получать оптимальную компиляцию и иметь при этом кроссплатформенность - распространять программы в виде исходников, т.е. делать опенсорц. Но эта идеология имеет свои серьёзные проблемы и мне не нравится.

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

Я выбираю язык под задачу. Пишу на Asm, C, C++, Delphi, C#, иногда Java и иногда некоторые скрипты аля JS/Python. Так что нет, мне не трудно, когда в этом действительно есть смысл.

Доказательства тоже сюда, пожалуйста.


Простыми.


Ещё раз объясняю. Вы влезли в мою область исследований, где я пытался рассуждать над языком программирования для HPC и сказали, что жава уже решает те вопросы, что я ставлю. Я объяснил, что для того, чтобы делать подобные заявления, нужно разбираться в моей области. Затем я сказал, что вы не сможете решить на жаве задачи, которые я назову простыми. Вы согласились пройти испытание. Однако не учли того факта, что влезание в мою область потребует понимание моей области. Вы показали, что понимания нет, а значит Вы НЕ можете знать, может что-то жава или нет, так как не знаете, какие задачи я решаю. Теперь Вы познакомились с простыми задачами. Я уверен, что даже если я напишу вам код на C++, а Вы перепишите его на жаве, то получится поклёп.


В тесте попроще нет смысла. Тесты попроще я могу решить в Exсel. Считая себя обывателем, зачем впихивать человеку, который уже имеет доказательства мёртвости жавы для HPC, что жава жива и там? Я думаете зря привёл Вам пример, как человек, не разбирающийся в строительстве, начинает пропихивать свои инструменты против тех, что сформировались в результате многолетнего опыта?

Вы сами ставите себя в позицию ущемлённого и вынужденного защищаться человека. На Вашем месте я придумал десяток способов выйти из ситуации не с помощью пустых деклараций, унижающих Вас, а более достойно. Привожу на вскидку некоторые из идей, что мне моментально пришли бы в голову, будь я на Вашем месте:
- Пригласить крутого математика-программиста, уважающего жаву, который заткнёт за пояс этого "зарвавшегося юношу".
- Попросить у кого-нибудь разбирающегося состряпать код на другом языке, который проходит тесты в системе, а потом переписать код на жаве и сравнить.
- Спросить у кого-нибудь, что такое блочное перемножение матриц и в чём принципиальная разница между этим алгоритмом и обычным тройным циклом.
- Взять другую задачу, требующую сложных расчётов (например, из моего архива short-cycles в соседней теме), попытаться решить на жаве и сравнить. Похожим образом, например (но без переписывания), поступил тов. Himik, защищая современный компилятор GCC от моих убеждений в убогости оного (судя по старым моим проверкам), что ему вполне достойно и удалось сделать.
И т. д. Если подумать ещё несколько минут, можно найти и другие выходы из сложившейся ситуации. Но Вы же не хотите, Вам же приятно думать, что над Вами издеваются. Так это выглядит со стороны.

Ну вот, а вы говорили, что С компилятор мегакрут и уделает мой ручной код на ассемблере "как два пальца ...".

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

На 8 Мгц, может и не стоит возиться с Java, но там ведь и задачи-то примитивные, типа выдать сигнал на такой-то ноге с такого-то по такой-то такт.

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

Я что-то не соображу, какую это формулу можно заменить сотней if-ов ?

Ну давайте ещё тестов напишем и сравним, а ? И за одно вспомним, что там с обещаным тестом на умножение матриц на С ?

Я уже в другой ветке рассказывал - байткод на 100% преобразуем в исходный код на Java. Комментарии и форматирование, конечно, потеряются, но всё остальное останется.

Поэтому компилируйтесь в байткод и будет вам счастье

Все начинают с робких и неудачных шагов. А потом чемпионами мира по бегу становятся.

Это скорее от вас требуют реализации на конкретном языке, чем вы осознанно что-то под задачу ищете. Например - расскажите про магию выбора между C, C++, Delphi, C# и Java для одной и той же задачи ?

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

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

Без всякой зауми про перестановки ферзей ваша задача решена простейшим алгоритмом и укладывается в ваши 100 секунд на вашем железе. Могу выложить код, если вам не верится. Так что опять ваш замок залепил вам глаза своим мнимым величием.

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

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

Java мертва, но Excel жив ! Вот она какая, истина. Вас остаётся только пожалеть ...