Цитата:
Ну вот, а вы говорили, что С компилятор мегакрут и уделает мой ручной код на ассемблере "как два пальца ...".
Я ни разу этого не говорил. Не надо выдумывать. Я сказал, что чистый ассемблер уделает java-inline в случае постоянного обращения к JNI. Всё. Вопрос про JNI с массивами снят, со структурами остался. В целом, учитывая нормальную работу с массивами, и если со структурами не работать - то разумеется, Java-inline будет работать на равне с обычным ассемблером, т.к. это и есть обычный ассемблер, только до жути неудобный и нечитаемый.
Цитата:
И тем не менее - умный компилятор должен знать много хитрых штучек по экономии байтов и циклов процессора.
Никакой компилятор не может придумать переделать весь алгоритм. Он может только оптимизировать существующий. Если ваш компилятор сам сочиняет алгоритмы - получайте нобеля и живите на дивиденды от его использования, потому что это и есть ИИ.
Цитата:
На 8 Мгц, может и не стоит возиться с Java, но там ведь и задачи-то примитивные, типа выдать сигнал на такой-то ноге с такого-то по такой-то такт.
Когда как. Матрицы мне конечно перемножать не приходилось, но иногда требуются и сортировки, и вычисления геометрии.
Цитата:
Хотя опять же, если вы пишете на Java, понимая, что не стоит заниматься выделением памяти в критически важных местах программы, то сразу все проблемы со сборщиком мусора исчезают магическим образом - он просто не запускается, когда ему нет работы.
А если мне нужна работа с памятью в критически важных местах? Нельзя сказать сборщику, что "вот отсюда до сюда выключи сборщик". Он мог навыделять кучу памяти ранее, и тогда он не освободит всю память к началу критически важного кода и начнет вклиниваться в критические места, даже если вызовов NEW там не так много. Короче говоря, он непредсказуем. А когда запустится - так это всё, прощай скорость.
Цитата:
Я что-то не соображу, какую это формулу можно заменить сотней if-ов ?
Код:
result = a / 100;
некоторые "программисты" (китайцы) запишут как
Код:
if (a >= 0 && a < 100) result = 0;
else if (a >= 100 && a < 200) result = 1;
...
и это не шутка. Хотя чаще у таких убогих программистов встречается свичкейс.
Цитата:
Ну давайте ещё тестов напишем и сравним, а ? И за одно вспомним, что там с обещаным тестом на умножение матриц на С ?
... Повторю то, что уже сказал. Я говорю, что вычисления на java будут работать медленней. Пройти тест на медлительность? Написать самый медленный код на java? Без проблем.
А тест на Си+Асм уже написан и не раз разными людьми. Гуглится без проблем. Исходники участников того же самого сайта Zealint'а.
Цитата:
Я уже в другой ветке рассказывал - байткод на 100% преобразуем в исходный код на Java. Комментарии и форматирование, конечно, потеряются, но всё остальное останется.
А я в той же ветке рассказал, что ЯНУ
никогда не преобразуется на 100% в ЯВУ, и привел примеры и обоснование. Помните про сложные условия, циклы? Я каждый день вижу с десяток файлов, которые частично не подлежат автоматическому восстановлению, и это без всякой обфускации. Все потому, что в ЯНУ (байт-коде), да и вообще в машине Тьюринга, коей является ассемблер нет таких понятий, как "цикл" или "условие". Есть только переход по ленте команд в произвольную точку. И отличить цикл от условия очень трудно, а найти точное условие цикла, например, бывает невозможно при использовании хоть одного break/continue. При наличии же сложных условий получаем множество паттернов для превращения байт-кода в код на ЯВУ, которые сильно конфликтуют друг с другом, и на выходе получаем какую-то бессвязную мешанину IF-ов и while-ов, которые никоим образом не связаны с оригинальным кодом.
Я потратил кучу времени на бодание с декомпиляцией, и понял, что все паттерны все равно не распознать. Если не верите - напишите декомпилятор, который будет всегда распознавать все логические конструкции. Мне как раз такой нужен. Ни один из существующих не справляется. Или хотя бы составьте все паттерны распознавания логических конструкций.
Цитата:
Поэтому компилируйтесь в байткод и будет вам счасть
см выше
Цитата:
Это скорее от вас требуют реализации на конкретном языке, чем вы осознанно что-то под задачу ищете. Например - расскажите про магию выбора между C, C++, Delphi, C# и Java для одной и той же задачи ?
Нет, ну поясните, как так можно читать?
Я пишу: "Я выбираю язык под задачу". Вопрос: "Объясните магию выбора РАЗНЫХ языков для ОДНОЙ задачи".
Объясняю "магию" выбора ОДНОГО языка для ОДНОЙ задачи, потому что я делаю именно так:
Если проект требует работы с железом (микроконтроллеры и операционная система, которую я тут пилю), критичен к скорости
или является грязным хаком какой-нибудь проги, где разработчики не удосужились сделать нужную мне фичу - Ассемблер.
Если проект очень сложной логической структуры и требует постоянного переписывания кусков кода - Си или C++. Чистый си в случае нежелательности ООПшить (например, если делаю ДЛЛ или пишу под систему, где предполагается только структурный код, аля моя ОС или дрова под линукс).
Если проект критичен к скорости, но на ассемблере его реализовать очень тяжело - С++.
Если проекту нужно красивое GUI - Delphi. Для меня нет гуи-строителя удобней, но тут кому что нравится.
Если проект нужно написать быстро, имеются шаблоны готового кода, проект связан с и без того тормозными вещами (БД) или если проект делается "на один раз" - C#.
->Если шаблоны кода на Java - то Java.
Разумеется, иногда задача разбивается на две, и я делаю часть на одном языке, часть на другом, и соединяю. Если проект попадает в несколько из этих категорий, и разделить на части его нельзя - выделяю самую приоритетную и по ней выбираю язык.