It is not a goal to guarantee any particular optimization strategy or memory layout. This JEP enables many potential optimizations; only some will be implemented initially. Future JEPs will pursue optimizations related to null exclusion and generic specialization.
Пока не прилагается. Если мне не изменяет память, в предыдущей версии прилагалось (которая оказалась настолько сложной, что лично мне хотелось плакать, глядя на изменения в спецификациях).
Мне кажется, у меня достаточно хорошо развит навык предсказания будущего кода. Помогают регулярные тренировки и понимание предметной области.
Но самое главное, что чем лучше умеешь предсказывать будущее, тем реже пишешь "расширяемый" код на пустом месте. Всё-таки намного проще расширять и модифицировать малое количество кода, условные 2+2, чем анализировать закрученные абстракции, которые требуют тотального и длительного погружения в голову автора.
Мне бы хотелось верить, что в независимости от того, писалось по одному байту или по 3, на нижнем слое всё равно стоит буфер перед сисколом. Иначе ну совсем грустно)
Не чтобы оспорить тезис, но просто дополню: в Java 1 миллион вызовов виртуальной функции занимает нисколько, если окажется в рантайме, что имплементация всегда одна и та же - JiT увидит мономорфизм, поставит trap и заинлайнит всё под корень.
Для меня проблема в миллиардах интерфейсов чаще не столько в производительности, сколько в том, что читать становится сложнее, а модифицировать - вообще хоть вешайся, хотя автор декларировал, казалось бы, что будет наоборот)
Кстати, я только обратил внимание, что вы используете Фибоначчиеву кучу, на wiki поговаривают, что с ней не всё так однозначно:
скрытые константы в асимптотических оценках трудоёмкости велики и использование фибоначчиевых куч редко оказывается целесообразным: обычные двоичные (d-ичные[англ.]) кучи на практике эффективнее.
Альтернативами им служат толстые кучи, тонкие кучи и кучи Бродала[англ.], обладающие теми же асимптотическими оценками, но меньшими константами[4].
Например во многих алгоритмах при описании есть фраза "берём оставшиеся", а при реализации получается так, что чтобы взять те самые оставшиеся нужно сломать мозг, так как на пальцах всё красиво, а на деле всё не так просто.
Направление мысли верное, но выводы не до конца точные.
Давайте в качестве примера.
array[0] + array[1] может работать на порядки быстрее чем array[0] + array[1000000000], потому что array[0] и array[1] скорее всего будут находиться в одной кэш-линии, а во втором случае мы вылетаем даже за L3 кэш.
Таких загагулин в современных процессорах вагон и парочка тележек. Конвейеры, предсказание ветвлений, префетч памяти и т.д.
Поэтому выбор правильного алгоритма - только первый шаг. Дальше, если производительность проседает неадекватным образом, обычно смотрят почему, а не сразу меняют алгоритм. Для этого существуют инструменты профилирования, которые показывают какие участки кода занимают наибольшее время (в идеале - результирующего, ассемблерного кода). Также они часто могут показывать с чем это связано, например, отдельно можно профильтровать выходы за кэш, ошибки предсказания ветвления и так далее.
Алгоритмы часто могут быть ускорены и замедлены на порядки тем, как именно данные "упакованы" в памяти и как (в том числе в каком порядке) к ним осуществляется доступ.
При этом так же отмечу, что поскольку у вас некоторый частный случай, разумеется, в этом частном случае может существовать (а может и не существовать) алгоритм, который ведёт себя лучше.
Но в общем случае, когда о данных ничего не известно, Дейкстра вполне себе оптимален (а как показано в статье, не вполне себе, а оптимален).
Мне помогает разобраться в предметных областях, в которых я ещё не бывал до этого. Тупо подыскать термины для гугления. Говоришь ему "мне надо сделать то и то", оно пыхтит, выдает невнятную дичь, но по по дороге выплёвывает достаточное количество терминологии, чтобы ты понял, куда вообще можно копать.
У меня да, основное использование chat gpt - объяснять ему как глубоко он заблуждается, тем самым разбираясь в вопросе самому. Раньше для этого мне требовались либо студенты, либо джуны)
Дело не в том, считаю ли я, есть ли что-то более быстрое с алгоритмической точки зрения. Дело в том, что без кода и/или профиля рассуждать в воздухе что быстрее абсолютно бесперспективно.
Разумеется есть частные случаи, когда разные алгоритмы, как тот же волновой, эффективнее Дейкстры. Но не в общем случае.
Если мы говорим, что что-то работает медленно, совершенно не факт, что это вообще как-то связано с алгоритмом. Часто (чаще всего) - дело в реализации. Способ организации данных, например, влияет на работу кэшей, а это, извините, несколько порядков по разнице производительности.
В общем, утверждения характера "я написал А, оно медленнее Б, и все кто утверждает обратное - дураки и не лечатся" без возможности "дуракам" проверить, в чем дело, почему у них с А всё в порядке, а у автора сложности, выглядят... Ну мягко скажем, не обоснованно.
Простите, алгоритм? Кажется, любой инженер справится с написанием вот этого куска кода абсолютно механически, даже не подключая мозг. И в этом кажется суть собеседования - узнать, умеет ли человек в принципе нажимать на кнопки таким образом, чтобы из под рук выходил код.
Такие простенькие задачки, на мой взгляд, вполне позволяют это оценить.
Да, конечно, бывает разное, и можно от волнения затупить даже на чем-то элементарном, но нормальный интервьюер поможет справиться с волнением.
Профиль - это результат профилирования. Без профиля утверждать, что проблема в алгоритме, а не в реализации, как минимум странно.
A* ищет кратчайшее расстояние только до одной точки, в отличие от Дейкстры, поэтому они не взаимозаменяемы. Кроме того, его качество сильно зависит от выбранной эвристики, которую построить таким образом, чтобы алгоритм всё ещё оставался корректным, не всегда вообще возможно.
Bfs же вообще не учитывает вес ребер.
Ваше оригинальное утверждение про 40 минут и 6к вершин предельно контринтуитивно, даже при квадратичной сложности так долго работать не должно, именно поэтому люди просят посмотреть код, чтобы понять, в чём же дело.
Community Edition is free to use for personal and commercial development. The IDE and most of it bundled plugins are open-source, licensed under Apache 2.0.
Жил и в Питере, и в Москве, и в глубинке. Всё вышеперечисленное не страхи, а регулярные ситуации, в разных городах. Европа с точки зрения безопасности от насилия и произвола силовиков, на мой взгляд, несопоставима с Россией. Статистику по насильственным преступлениям можете загуглить самостоятельно, она тоже подтверждает мои слова, но между живыми людьми обмен мнениями обычно происходит как раз в субъективном поле, и этим и ценен.
У меня всё диаметрально противоположно. Живу не в самом центре, но близко, и слоняться по ночам вызывает 0 дискомфорта или страхов быть убитым/побитым/ограбленным. А вот вездесущие велосипедисты как раз предельно бесят)
Ну во-первых, что значит не связано с политикой? С политикой связано всё или почти всё.
Агрессивная среда, в которой мужчине, например, даже волосы нельзя покрасить, потому что "будут вопросики".
Алконавты на улице, ищущие приключений, и уверенные (не безосновательно), что им ничего не будет в случае чего.
Представители силового блока, ведущие себя как короли жизни везде и всюду. Настолько, что даже в качестве потерпевшего связываться с полицией хочется далеко не всегда.
Проблемы сегодняшнего дня, которые уже совсем переполнили чашу терпения и дискомфорта, вы, наверное относите к политике, хотя не понимаю, почему это что-то меняет.
С одной стороны согласен, плюсик поставил, с другой стороны есть ещё и дети, у которых больше времени и возможностей натурализоваться.
Сейчас живу в Амстердаме, с женой и детьми, доволен, как поросёнок. Но да, доходы для этого требуются действительно очень далёкие от медианных/средних.
В России я за любые деньги/доходы не мог обеспечить себе тот же уровень комфорта и личной безопасности. С другой стороны, де-социализация ощущается достаточно остро, т.к. работаю удаленно. И по борщу скучаю)
Пока не прилагается. Если мне не изменяет память, в предыдущей версии прилагалось (которая оказалась настолько сложной, что лично мне хотелось плакать, глядя на изменения в спецификациях).
Мне кажется, у меня достаточно хорошо развит навык предсказания будущего кода. Помогают регулярные тренировки и понимание предметной области.
Но самое главное, что чем лучше умеешь предсказывать будущее, тем реже пишешь "расширяемый" код на пустом месте. Всё-таки намного проще расширять и модифицировать малое количество кода, условные 2+2, чем анализировать закрученные абстракции, которые требуют тотального и длительного погружения в голову автора.
Мне бы хотелось верить, что в независимости от того, писалось по одному байту или по 3, на нижнем слое всё равно стоит буфер перед сисколом. Иначе ну совсем грустно)
Не чтобы оспорить тезис, но просто дополню: в Java 1 миллион вызовов виртуальной функции занимает нисколько, если окажется в рантайме, что имплементация всегда одна и та же - JiT увидит мономорфизм, поставит trap и заинлайнит всё под корень.
Для меня проблема в миллиардах интерфейсов чаще не столько в производительности, сколько в том, что читать становится сложнее, а модифицировать - вообще хоть вешайся, хотя автор декларировал, казалось бы, что будет наоборот)
Кстати, я только обратил внимание, что вы используете Фибоначчиеву кучу, на wiki поговаривают, что с ней не всё так однозначно:
скрытые константы в асимптотических оценках трудоёмкости велики и использование фибоначчиевых куч редко оказывается целесообразным: обычные двоичные (d-ичные[англ.]) кучи на практике эффективнее.
Альтернативами им служат толстые кучи, тонкие кучи и кучи Бродала[англ.], обладающие теми же асимптотическими оценками, но меньшими константами[4].
Направление мысли верное, но выводы не до конца точные.
Давайте в качестве примера.
array[0] + array[1] может работать на порядки быстрее чем array[0] + array[1000000000], потому что array[0] и array[1] скорее всего будут находиться в одной кэш-линии, а во втором случае мы вылетаем даже за L3 кэш.
Таких загагулин в современных процессорах вагон и парочка тележек. Конвейеры, предсказание ветвлений, префетч памяти и т.д.
Поэтому выбор правильного алгоритма - только первый шаг. Дальше, если производительность проседает неадекватным образом, обычно смотрят почему, а не сразу меняют алгоритм. Для этого существуют инструменты профилирования, которые показывают какие участки кода занимают наибольшее время (в идеале - результирующего, ассемблерного кода). Также они часто могут показывать с чем это связано, например, отдельно можно профильтровать выходы за кэш, ошибки предсказания ветвления и так далее.
Алгоритмы часто могут быть ускорены и замедлены на порядки тем, как именно данные "упакованы" в памяти и как (в том числе в каком порядке) к ним осуществляется доступ.
При этом так же отмечу, что поскольку у вас некоторый частный случай, разумеется, в этом частном случае может существовать (а может и не существовать) алгоритм, который ведёт себя лучше.
Но в общем случае, когда о данных ничего не известно, Дейкстра вполне себе оптимален (а как показано в статье, не вполне себе, а оптимален).
Уточка умнее меня, с ней так не работает.
Мне помогает разобраться в предметных областях, в которых я ещё не бывал до этого. Тупо подыскать термины для гугления. Говоришь ему "мне надо сделать то и то", оно пыхтит, выдает невнятную дичь, но по по дороге выплёвывает достаточное количество терминологии, чтобы ты понял, куда вообще можно копать.
У меня да, основное использование chat gpt - объяснять ему как глубоко он заблуждается, тем самым разбираясь в вопросе самому. Раньше для этого мне требовались либо студенты, либо джуны)
Дело не в том, считаю ли я, есть ли что-то более быстрое с алгоритмической точки зрения. Дело в том, что без кода и/или профиля рассуждать в воздухе что быстрее абсолютно бесперспективно.
Разумеется есть частные случаи, когда разные алгоритмы, как тот же волновой, эффективнее Дейкстры. Но не в общем случае.
Если мы говорим, что что-то работает медленно, совершенно не факт, что это вообще как-то связано с алгоритмом. Часто (чаще всего) - дело в реализации. Способ организации данных, например, влияет на работу кэшей, а это, извините, несколько порядков по разнице производительности.
В общем, утверждения характера "я написал А, оно медленнее Б, и все кто утверждает обратное - дураки и не лечатся" без возможности "дуракам" проверить, в чем дело, почему у них с А всё в порядке, а у автора сложности, выглядят... Ну мягко скажем, не обоснованно.
Простите, алгоритм? Кажется, любой инженер справится с написанием вот этого куска кода абсолютно механически, даже не подключая мозг. И в этом кажется суть собеседования - узнать, умеет ли человек в принципе нажимать на кнопки таким образом, чтобы из под рук выходил код.
Такие простенькие задачки, на мой взгляд, вполне позволяют это оценить.
Да, конечно, бывает разное, и можно от волнения затупить даже на чем-то элементарном, но нормальный интервьюер поможет справиться с волнением.
Профиль - это результат профилирования. Без профиля утверждать, что проблема в алгоритме, а не в реализации, как минимум странно.
A* ищет кратчайшее расстояние только до одной точки, в отличие от Дейкстры, поэтому они не взаимозаменяемы. Кроме того, его качество сильно зависит от выбранной эвристики, которую построить таким образом, чтобы алгоритм всё ещё оставался корректным, не всегда вообще возможно.
Bfs же вообще не учитывает вес ребер.
Ваше оригинальное утверждение про 40 минут и 6к вершин предельно контринтуитивно, даже при квадратичной сложности так долго работать не должно, именно поэтому люди просят посмотреть код, чтобы понять, в чём же дело.
И профиль!
Так community edition реально бесплатная IDE.
Community Edition is free to use for personal and commercial development. The IDE and most of it bundled plugins are open-source, licensed under Apache 2.0.
С официального сайта JB.
Жил и в Питере, и в Москве, и в глубинке. Всё вышеперечисленное не страхи, а регулярные ситуации, в разных городах. Европа с точки зрения безопасности от насилия и произвола силовиков, на мой взгляд, несопоставима с Россией. Статистику по насильственным преступлениям можете загуглить самостоятельно, она тоже подтверждает мои слова, но между живыми людьми обмен мнениями обычно происходит как раз в субъективном поле, и этим и ценен.
У меня всё диаметрально противоположно. Живу не в самом центре, но близко, и слоняться по ночам вызывает 0 дискомфорта или страхов быть убитым/побитым/ограбленным. А вот вездесущие велосипедисты как раз предельно бесят)
Ну во-первых, что значит не связано с политикой? С политикой связано всё или почти всё.
Агрессивная среда, в которой мужчине, например, даже волосы нельзя покрасить, потому что "будут вопросики".
Алконавты на улице, ищущие приключений, и уверенные (не безосновательно), что им ничего не будет в случае чего.
Представители силового блока, ведущие себя как короли жизни везде и всюду. Настолько, что даже в качестве потерпевшего связываться с полицией хочется далеко не всегда.
Проблемы сегодняшнего дня, которые уже совсем переполнили чашу терпения и дискомфорта, вы, наверное относите к политике, хотя не понимаю, почему это что-то меняет.
Был недавно в Париже, и удивился, как чисто. Не то что у нас. В Амстердаме.
С одной стороны согласен, плюсик поставил, с другой стороны есть ещё и дети, у которых больше времени и возможностей натурализоваться.
Сейчас живу в Амстердаме, с женой и детьми, доволен, как поросёнок. Но да, доходы для этого требуются действительно очень далёкие от медианных/средних.
В России я за любые деньги/доходы не мог обеспечить себе тот же уровень комфорта и личной безопасности. С другой стороны, де-социализация ощущается достаточно остро, т.к. работаю удаленно. И по борщу скучаю)