Спасибо за пост, приятно видеть сочетание велотуринга и технологий.
Пришёл задавать вопрос, упомянутый в посте: сотню в день можно и на педалях ехать. Да, с палаткой, вещами и едой на неделю, ещё и с набором высоты под километр. И нет это не какие-то рекорды, это весьма спокойный туринг. Упоротые спортсмены ездят кратно больше.
А сам вопрос звучит на самом деле не так: неужели на велосипеде интересно ехать без кручения педалей? Половина кайфа же в этом. С мотором есть мотоциклы, машины и тд, у которых нет проблем с электричеством. Имхо, велосипед для того и нужен чтобы двигать его своими мышцами. Посадка на велосипеде заточена под работу ногами, без этого можно гораздо удобнее устроиться, как на скутерах например.
Если совсем упростить, то радиоактивная вода не наводит радиацию. Основным источником наведённой радиации являются нейтроны, а вода не будет их излучать. Радиация всё же не вирус, который чудом пролазит сквозь стены.
Ну как-то очень притянуто. const должен быть там, где данные не меняются. Если функция/объект не меняют данные, то должен быть const. Иначе ломается вся const корректность. Я так и не понял, ради чего надо жертвовать корректностью? В одном месте мы якобы получим больше явного, зато когда уже есть const объект единственным выбором будет копирование.
Я взял ваш код на C++ и Java и сравнил без JNI, просто две разных программы. На обеих версиях, что линейной, что квадратичной, результаты идентичны для обоих языков. Разницей в 4 раза даже не пахнет.
Debian 11, AMD Ryzen Threadripper 3970X
openjdk 11.0.13 2021-10-19 запускал через java main.java.
gcc version 10.2.1 g++ -O2 -o cmp_java java.cc && ./cmp_java
В обоих случаях около 1.8 секунды при размере задачи 50_000
И это вполне ожидаемые разультаты для числодробилки, потому что на подобном коде jit особо не уступает aot.
Но возьмите задачу, которая требует больше разнородных действий, сильнее нагружает GC, использует системные api и увидите, что всё уже совсем не в пользу Java. Поэтому заявления, что java быстрее jni мягко говоря необоснованы.
Не спорю, на java можно писать высокопроизводительный код, но начиная с некоторой сложности задачи, это становится слишком тяжело - мест, где можно потерять всю скорость, язык и библиотеки предоставляют массу.
Весь раздел про синтаксис - демонстрация его полного незнания и непонимания. Хоть бы почитали, откуда взялась эта точка с запятой, особенно после классов.
В некоторых других моментах есть зерно истины, но накидали в одну кучу так, что пользы - ноль. Даже крик души полезно структурировать.
Хоть и не нашёл по ссылкам, но уверен, что температура и давления "управляемы" это manageable в оригинале, то есть скорее "терпимы", "допустимы" в этом контексте. И дословный перевод даёт вот такое совершенно неправильное значение. Имхо, человек осмысленно этот текст даже не читал после перевода.
Русский для этого не приспособлен. У нас ни порядка слов зафиксированного, ни хотя бы отличия пассива от актива. Кто кого высылает без правильных склонений не понять.
Тенденция ясна, и да, я согласен, что падежи будут упрощаться, но не так и не с потерей смысла.
И да, и нет. Для хороших трейсов на C++ backtrace_symbols совершенно недостаточен. То есть что-то вполне читаемое он выведет, но если сравните это с стеком из gdb, то удивитесь, насколько лучше бывает. backtrace_symbols содержит только символы, поэтому все неэкспортируемые функции, внезапно, лямбды оказываются совершенно неинформативными. Опять же нет номеров строк.
Поэтому для хорошего стека приходится тащить libdwarf и по дебажной информации восстанваливать качественнее. Но да, начинается всё с банального backtrace.
Но proposal-ы стабильно не проходят голосование, потому что вечно находятся причины против UFCS
Вот это, к сожалению, правда. Даже версия с вывернутым наизнанку UFCS не прошла, когда предлагали begin(vec) трактовать как vec.begin(), а не наоборот. В том же D на этом Ranges работают и не надо дополнительно перегружать |. Я не всегда понимаю комитет, порой они уж слишком осторожны.
Я большой любитель ADL и не в курсе, как UFCS его ломает. Может быть есть примеры? Если взять идею из D, где не надо ничего указывать специально и любая функция может быть вызвана как метод на своём первом аргументе, то алгоритм простой:
1) Ищем метод на объекте, если есть зовём
2) Если нет, то ищем функцию по старым правилам, включая ADL.
Имхо, объяснение неверное, или я его не так понял. Компилятор всегда предполагает, что UB в коде нет. Он может так считать, потому что, если оно есть, то любое поведение корректно. Так как UB нет, то цикл не может дойти до индекса i == 4. Единственный вариант не дойти до i == 4 - выйти с true раньше. А дальше уже удаляется ненужный код, так как он не имеет побочных эффектов.
Про поиск столкновений - любой, заявляющий Continuous collision detection, например Unity, или тот же Box2D.
Со стенками из кубиков всё сложнее, общее решение не очень практично, так как требует честного решения СЛАУ. Но небольшими хаками это тоже чинится, например ещё 13 лет назад в Havok стопки из кубиков были вполне стабильны. Если не ошибаюсь, то там было многопроходное решение столкновений.
Это уже давным-давно научились делать правильно. Вместо тел в геометрии поиска столкновений используются вытянутые по их скорости "капсулы". Это позволяет определять все столкновения и высчитывать точный момент столкновения. И шаг времени не приходится избыточно уменьшать.
И статические стенки из коробок тоже уже нормальные движки умеют держать стабильными без этих прыжков и взаимопроникновений. Выглядит как Box2D 10, если не 15 лет назад.
Спасибо за пост, приятно видеть сочетание велотуринга и технологий.
Пришёл задавать вопрос, упомянутый в посте: сотню в день можно и на педалях ехать. Да, с палаткой, вещами и едой на неделю, ещё и с набором высоты под километр. И нет это не какие-то рекорды, это весьма спокойный туринг. Упоротые спортсмены ездят кратно больше.
А сам вопрос звучит на самом деле не так: неужели на велосипеде интересно ехать без кручения педалей? Половина кайфа же в этом. С мотором есть мотоциклы, машины и тд, у которых нет проблем с электричеством. Имхо, велосипед для того и нужен чтобы двигать его своими мышцами. Посадка на велосипеде заточена под работу ногами, без этого можно гораздо удобнее устроиться, как на скутерах например.
P.S. Поделитесь ссылками на маршруты.
Ничего лучше, чем поиск картинок в гугле предложить не могу. Там есть удачные пары
https://www.google.com/search?q=обратная+сторона+луны
<offtopic>
От изображения видимой стороны Луны у меня глаз задёргался. https://habrastorage.org/r/w1560/webt/ig/8z/sd/ig8zsdexev81_ysfey03_or-joq.jpeg Кто её так склеил? Разные части с разных фаз и совсем не солнечно синхронно, что я бы понял, а наоборот в полный рассинхрон.
Если совсем упростить, то радиоактивная вода не наводит радиацию. Основным источником наведённой радиации являются нейтроны, а вода не будет их излучать. Радиация всё же не вирус, который чудом пролазит сквозь стены.
Там выдадут и совсем не то, что в посте.
Ну как-то очень притянуто. const должен быть там, где данные не меняются. Если функция/объект не меняют данные, то должен быть const. Иначе ломается вся const корректность. Я так и не понял, ради чего надо жертвовать корректностью? В одном месте мы якобы получим больше явного, зато когда уже есть const объект единственным выбором будет копирование.
2 бита для разницы в 10 <zanuda/>
Нургл не ставит точки, а лишь запускает перерождение. Бесконечно.
Я взял ваш код на C++ и Java и сравнил без JNI, просто две разных программы. На обеих версиях, что линейной, что квадратичной, результаты идентичны для обоих языков. Разницей в 4 раза даже не пахнет.
Debian 11, AMD Ryzen Threadripper 3970X
openjdk 11.0.13 2021-10-19 запускал через
java main.java.gcc version 10.2.1
g++ -O2 -o cmp_java java.cc && ./cmp_javaВ обоих случаях около 1.8 секунды при размере задачи 50_000
И это вполне ожидаемые разультаты для числодробилки, потому что на подобном коде jit особо не уступает aot.
Но возьмите задачу, которая требует больше разнородных действий, сильнее нагружает GC, использует системные api и увидите, что всё уже совсем не в пользу Java. Поэтому заявления, что java быстрее jni мягко говоря необоснованы.
Не спорю, на java можно писать высокопроизводительный код, но начиная с некоторой сложности задачи, это становится слишком тяжело - мест, где можно потерять всю скорость, язык и библиотеки предоставляют массу.
Весь раздел про синтаксис - демонстрация его полного незнания и непонимания. Хоть бы почитали, откуда взялась эта точка с запятой, особенно после классов.
В некоторых других моментах есть зерно истины, но накидали в одну кучу так, что пользы - ноль. Даже крик души полезно структурировать.
Хоть и не нашёл по ссылкам, но уверен, что температура и давления "управляемы" это manageable в оригинале, то есть скорее "терпимы", "допустимы" в этом контексте. И дословный перевод даёт вот такое совершенно неправильное значение. Имхо, человек осмысленно этот текст даже не читал после перевода.
Простите, но вы на каком языке сейчас общаетесь. Выглядит, как очень плохой перевод.
Русский для этого не приспособлен. У нас ни порядка слов зафиксированного, ни хотя бы отличия пассива от актива. Кто кого высылает без правильных склонений не понять.
Тенденция ясна, и да, я согласен, что падежи будут упрощаться, но не так и не с потерей смысла.
И да, и нет. Для хороших трейсов на C++ backtrace_symbols совершенно недостаточен. То есть что-то вполне читаемое он выведет, но если сравните это с стеком из gdb, то удивитесь, насколько лучше бывает. backtrace_symbols содержит только символы, поэтому все неэкспортируемые функции, внезапно, лямбды оказываются совершенно неинформативными. Опять же нет номеров строк.
Поэтому для хорошего стека приходится тащить libdwarf и по дебажной информации восстанваливать качественнее. Но да, начинается всё с банального backtrace.
Мой личный топ это https://habr.com/ru/company/infopulse/blog/338812/
Форматирование диска одним вызовом по нулевому указателю гораздо эмоциональнее опровержения старой теоремы. Хотя, о вкусах UB не спорят.
Вот это, к сожалению, правда. Даже версия с вывернутым наизнанку UFCS не прошла, когда предлагали begin(vec) трактовать как vec.begin(), а не наоборот. В том же D на этом Ranges работают и не надо дополнительно перегружать |. Я не всегда понимаю комитет, порой они уж слишком осторожны.
Я большой любитель ADL и не в курсе, как UFCS его ломает. Может быть есть примеры? Если взять идею из D, где не надо ничего указывать специально и любая функция может быть вызвана как метод на своём первом аргументе, то алгоритм простой:
1) Ищем метод на объекте, если есть зовём
2) Если нет, то ищем функцию по старым правилам, включая ADL.
Что не так?
Имхо, объяснение неверное, или я его не так понял. Компилятор всегда предполагает, что UB в коде нет. Он может так считать, потому что, если оно есть, то любое поведение корректно. Так как UB нет, то цикл не может дойти до индекса i == 4. Единственный вариант не дойти до i == 4 - выйти с true раньше. А дальше уже удаляется ненужный код, так как он не имеет побочных эффектов.
Про поиск столкновений - любой, заявляющий Continuous collision detection, например Unity, или тот же Box2D.
Со стенками из кубиков всё сложнее, общее решение не очень практично, так как требует честного решения СЛАУ. Но небольшими хаками это тоже чинится, например ещё 13 лет назад в Havok стопки из кубиков были вполне стабильны. Если не ошибаюсь, то там было многопроходное решение столкновений.
Это уже давным-давно научились делать правильно. Вместо тел в геометрии поиска столкновений используются вытянутые по их скорости "капсулы". Это позволяет определять все столкновения и высчитывать точный момент столкновения. И шаг времени не приходится избыточно уменьшать.
И статические стенки из коробок тоже уже нормальные движки умеют держать стабильными без этих прыжков и взаимопроникновений. Выглядит как Box2D 10, если не 15 лет назад.