По вашему комментарию добавил в код обработку унарного минуса, а также рекурсивный разбор выражения в скобках. Плюс добавил иллюстрацию к правилам синтаксического разбора. Спасибо за обратную связь!
Да, я в самом начале процесса изучения современного C++ и многого о языке просто не знаю (smart pointers) - скатываюсь в C. По мере изучения новых (для меня) возможностей постараюсь переписать почище. Спасибо.
Спасибо за комментарий! Действительно смесь C и C++ - "дикая". Всё банально - я просто этого не знал. Теперь хоть пойму что изучать, почитаю и перепишу почище.
Спасибо за ссылку. В начале первой части рассказал о своих мотивах - размять мозг, вспомнить C/C++, на котором не писал 18 лет (после Java). Для такой цели использовать генераторы смысла нет.
Почитал вашу статью - очень интересно. У меня нет такого глубокого знания ассемблера x86. Сейчас как раз дописал разбор и генерацию кода простых арифметических выражений с константами. В следующей части опубликую, очень интересно ваше мнение и опыт.
Как быстро вы делаете заключение, кто что понимает. Думаю, я осознаю разницу между переменными примитивных типов и ссылками на объекты, а также где они аллоцируются на стеке или в куче.
Думаю, мой вопрос скорее не о сравнении языков Java vs C/C++ (пишу на обоих и у каждого свои сильные стороны), а о компиляторах (Android Runtime vs Clang). Если есть способы безусловно на всех устройствах получить преимущество в производительности на C/C++, то напишу важные части движка на нём. Если нет, тогда оставлю на Java. Поэтому и советуюсь с сообществом.
Вы правы. Поэтому вначале и написал disclaimer, что это очень тупой и простой бенчмарк. По идее много чего не учтено. К этому короткому исследовантю я пришел тогда, когда решил переписать с Java на C++ свой рендер (sprite batching). Когда увидел, что это мало что дало на новых устройствах (на старых дало). Решил провести такой вот простой бенч. Никаких амбиций по поводу высокой точности. Но множество итераций было проведено, чтобы более менее среднее посчитать.
Вы правы. Я осознанно не занулял отдельно массив, чтобы сравнение произошло более менее справедливо (вдруг Android Runtime это делает отдельно). Отсутствие зануления влияет лишь на результат расчетов, а не снижает скорость C функции.
Мне нужно было добиться максимальной схожести логики на Java и C. Специально использовал new, а не локальные аллокацию (на стеке), чтобы сравнение было справедливым. Ведь, на сколько мне известно, Java все равно будет брать память в куче. По этой же причине осознанно закомментил delete[] для теста.
Тоже грешил на это вначале. Вызовы JNI безусловно имеют overhead. Чтобы удостовериться отдельно измерял время в самой C функции - примерно такое же соотношение времени. Видимо, если выполняется много работы в самой C функции - overhead не имеет большого влияния.
Спасибо за наводку! Почитал про BNF и EBNF (слышал в студенчестве, но не вникал). Действительно, хорошо упорядочивает мысль такое формальное описание языка на примере ANSI C: https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20syntax%20of%20C%20in%20Backus-Naur%20form.htm
Сразу наглядно видно все упущения и неопределённости моей реализации.
Да, есть неправильное применение терминов. Исправлю.
Да, я в самом начале процесса изучения современного C++ и многого о языке просто не знаю (smart pointers) - скатываюсь в C. По мере изучения новых (для меня) возможностей постараюсь переписать почище. Спасибо.
Спасибо за комментарий! Действительно смесь C и C++ - "дикая". Всё банально - я просто этого не знал. Теперь хоть пойму что изучать, почитаю и перепишу почище.
Спасибо за ссылку. В начале первой части рассказал о своих мотивах - размять мозг, вспомнить C/C++, на котором не писал 18 лет (после Java). Для такой цели использовать генераторы смысла нет.
Готово - https://m.habr.com/ru/post/560986/
Спасибо! Даже не подозревал о существовании такого стандарта. Почитаю.
Наши с вами тестовые программы для виртуальных машин делают одно и тоже, почти каждая инструкция байт кода один в один. Ничосе совпадение )))
О супер! Спасибо.
Почитал вашу статью - очень интересно. У меня нет такого глубокого знания ассемблера x86. Сейчас как раз дописал разбор и генерацию кода простых арифметических выражений с константами. В следующей части опубликую, очень интересно ваше мнение и опыт.
Тем не менее при изменении параметра теста size в сторону увеличения, время всё таки увеличивается, а значит код выполняется.
Хороший аргумент. Имеет смысл.
Как быстро вы делаете заключение, кто что понимает. Думаю, я осознаю разницу между переменными примитивных типов и ссылками на объекты, а также где они аллоцируются на стеке или в куче.
Думаю, мой вопрос скорее не о сравнении языков Java vs C/C++ (пишу на обоих и у каждого свои сильные стороны), а о компиляторах (Android Runtime vs Clang). Если есть способы безусловно на всех устройствах получить преимущество в производительности на C/C++, то напишу важные части движка на нём. Если нет, тогда оставлю на Java. Поэтому и советуюсь с сообществом.
Вы правы. Поэтому вначале и написал disclaimer, что это очень тупой и простой бенчмарк. По идее много чего не учтено. К этому короткому исследовантю я пришел тогда, когда решил переписать с Java на C++ свой рендер (sprite batching). Когда увидел, что это мало что дало на новых устройствах (на старых дало). Решил провести такой вот простой бенч. Никаких амбиций по поводу высокой точности. Но множество итераций было проведено, чтобы более менее среднее посчитать.
Вы правы. Я осознанно не занулял отдельно массив, чтобы сравнение произошло более менее справедливо (вдруг Android Runtime это делает отдельно). Отсутствие зануления влияет лишь на результат расчетов, а не снижает скорость C функции.
Мне нужно было добиться максимальной схожести логики на Java и C. Специально использовал new, а не локальные аллокацию (на стеке), чтобы сравнение было справедливым. Ведь, на сколько мне известно, Java все равно будет брать память в куче. По этой же причине осознанно закомментил delete[] для теста.
Тоже грешил на это вначале. Вызовы JNI безусловно имеют overhead. Чтобы удостовериться отдельно измерял время в самой C функции - примерно такое же соотношение времени. Видимо, если выполняется много работы в самой C функции - overhead не имеет большого влияния.