Как-то это вообще неправильно, что критичные для старта компоненты подгружаются из интернета.
В том же спринге, например, xml-конфиг ссылается на какие-то внешние ресурсы, но эти xml так же есть внутри jar, и он их берет из jar, а не подтягивает из интернета. Как это сделано, я не разбирался.
Вероятно, тут подразумевается, что если в другом потоке obj1 и obj2 могут захватываться в обратном порядке, то тогда может быть дедлок. Это произойдет если сначала оба потока войдут в свой внешний synchronized (то есть первых захватывает obj1, второй захватывает obj2), а потом оба попытаются войти во внутренний.
Только это не грабля java, а грабля из области concurrency.
Как показал челябинский метеорит, до земли незамеченным долететь практически нереально. Если это метеорит — он будет гореть в атмосфере, и если он будет насколько большой, что сможет достичь поверхности земли — процесс горения будет заметен и слышен. А если он будет маленьким — то сгорит весь и не достигнет земли.
«Уронить» что-то с орбиты так, чтобы оно долетело целым — довольно сложная техническая задача.
Владельцы ловушек, работающих по такому принципу, пишут в отзывах, что эти ловушки неэффективны.
«Наверное, насекомые чувствуют ионный ветер, и они его не любят, поэтому не залетают туда» — это по отзыву радиолюбителя, который такую ловушку когда-то спаял.
Не согласен с некоторыми тезисами, местами они даже вредны, плюс набор тезисов не полный.
back-ups я бы не назвал бесполезным, а тем более «бесполезным на редкость», и «пустой тратой». Например, если речь идет о питании компьютера, то может быть так, что все что круче back-ups — излишество. Конечно, речь о случаях, когда БП в компьютере стоит хороший — но обычно только такой и нужен, если речь заходит о том, что компу нельзя перегружаться из за случайных глюков. Хороший компьютерный БП поддерживает колебания входного напряжения на входе в довольно широком диапазоне (у меня ~160вольт тянул) — и в упсе такая регулировка просто ненужна. Так же, особо неважно насколько там хорошо аппроксимируется синусоида — потому что БП компьютера все равно ее выпрямляет. Строго говоря, для компьютера синусоида вообще ненужна, он совершенно спокойно работает от самопального ибп который делает меандр с паузами в нуле.
При этом, например, online упсы — это дополнительная схемотехника на входе питания, со своим уровнем надежности. Еще и за деньги. Результирующая вероятность безотказной работы равна произведению вероятностей безотказной работы каждого элемента. То есть от плохой сети мы защищаемся — но надежность оборудования получается ниже. Наверное, если сеть плохая, то в этом может быть смысл, но бывает что основная проблема — это не колебания, а отключения.
Что касается практики, то например у меня smart-ups известной торговой марки приходится вообще отключать от сети, когда дом переключаю на китайский безногенератор. Он не может понять, все хорошо с питанием, или все плохо — и щелкает своей релюхой. Но при этом, back-ups работает нормально от того же генератора.
Странный вопрос.
А что вообще мог сделать не так министр экономического развития за 6 лет в стране, где развития не оказалось? Очевидно, развивать другие отрасли и прийти к тому, чтобы цена на нефть и курс вообще не волновали почти никого. Вместо этого в стране был внедрен oil-driven development.
ИМХО, проблема leap second кроется не в java (хотя может и в ней тоже), а в ОС, и в самом принципе високосных секунд: их вводят административно когда захотят, и эти секунды приходят по ntp. Это значит, что в будущем мы не можем точно прогнозировать временные интервалы.
Под убунтой все печательней. (наверное, под виндой тоже)
Дело в том, что System.currentTimemillis выдает время в миллисекундах, и оно не монотонно: в момент високосной секунды это время прыгает на 1000мс назад, но при этом запланированные с интервалом такси — выполняются с этим интервалом более-менее нормально — как будто время линейно. И получается этот прыжок назад надо как-то обрабатывать, если это важно.
Якобы в кернеле могут быть альтернативные time discipline при который часы ведут себя по другому, но есть ли они там и как их можно включить — я не разбирался.
Видимо, у него было что-то с мозгом, болезнь обострилась — и он начал действовать нехарактерно, а когда его задерживали, скорей всего приложили, чем еще и усугубили. К сожалению, от этого никто не защищен.
А вскрытия не будет? Экспертизы. Могло ведь и убийство быть.
Я так и не понял, суть претензии в самом принципе предоставить выбор из 8 картинок, или в безидейно подобранных картинках и вопросах?
Если в безидейно подобранных вопросах, то я согласен, а если претензии к самому принципу, то не соглашусь.
Например, на сайте киевстара для отправки смс надо выбрать из набора 2 или 3 картинки с живой природой(когда-то так было, как сейчас — не знаю). Помоему, нормальный вариант капчи. По крайней мере, лучше, чем ввести буквы, на которых не сидит кот.
Я тут еще подумал. Ведь стек — достаточно специфичная штука для многопоточной работы. Если у нас есть схема, когда в одном потоке в стек что-то кладется, а в другом снимается — фактически порядок съема обратным не будет, из за того что push и pop в разных потоках чередуются по-разному. И если в стек будет ложиться и приниматься по 1 записи — оно будет работать как очередь. Если же у нас в потоке-потребителе получится reverse ordered, это будет означать, что у нас на самом деле было не многопоточное выполнение, а последовательное выполнение двух задач в разных потоках. Реально же, на таком длительном тесте, стек будет работать почти как unordered collection.
Но. Если нас устраивает последовательное выполнение, то эффективней выполнить задачи в одном потоке — это более cache-frendly. А если нас устраивает unordered, то может лучше не стек? Если потоки действительно одновременно пишут и читают вершину, там же на вершине на этой будет false sharing (в данном случае наверное даже true sharing). Время будет съедаться на миграцию кэшлайна между ядрами, можно словить 1000 кратную просадку производительности.
Вобщем, достаточно искуственный пример. И тесты, (предположу, что в них скорей всего нет оценки степени «разупорядоченности») неясно что меряют. Набор различных эффектов, проявивших себя в различной мере, и наложенных друг на друга случайным образом.
Можете добавить в тесты следующую фишку: Через стек передаем последовательный набор чисел: 1,2,3,4,5,6..., Снимаются эти числа (когда снимаем в том же потоке) в обратной последовательности. На снимающей стороне мы смотрим, действительно ли последовательность съема обратная. Если происходит скачок по отношению к предыдущему снятому значению в сторону увеличения — значит потоком-производителем была засунута новая порция данных. Мы заводим счетчик таких событий.
И дальше мы говорим, мол всего элементов было столько-то, а конкуррентных вставок было столько-то, и отношение этих величин такое-то.
И когда мы сравниваем реализацию с мутексами с реализацией на cas-ах и спинлоках, то сравнивать имеет смысл прогоны теста, с оглядкой на отношение этих величин. Потому, что ОС, когда она обрабатывает мутексы, то может будить потоки по-разному.
И потом еще надо прогнать сначала push а потом pop этих элементов в одном потоке. Причем, прогнать в двух вариантах:
1 — сначала push всех, потом pop всех. (элементов должны быть сотни мб)
2 — push и pop порциями размером не более 64 байт (чтоб гарантированно работать в одном кэшлайне), вершина стека должна быть выровненной по 64 байтам.
И тут сравнивать время обработки с многопоточным временем обработки. Неисключено, что по варианту 2 будет выигрыш.
а потом прогоните через разные многопоточные очереди такой же обьем данных. И сравние. Это крректно потому, что мы выше решили, что стек может дать как ordered так и unordered данные на принимающей стороне. Нормальная очередь будет более cache-frendly, по идее должно получится существенно быстрей.
malloc/free должно быть тоже lock-free. Но стандартные malloc/free такими не являются. Более того, такой вызов — это же уход в kernel space, и он не может быть быстрым. То есть, кардинально повысить производительность не выйдет, потому что значительную часть сьест malloc. Но выход есть. Тут должен быть специальный lock-free malloc.
Конечно, это все на уровне догадок. Реально чтоб сравнить, надо мерять как оно будет в конкретных числах.
А надо как-то в градле включать процессинг груви-аннотаций для java-классов? java-классы в src/main/groovy компилятся без применения этих аннотаций. Документация говорит, что есть инкубационный флажок, но вот так не помогло:
А что означает L+1 в верхнем пределе? Конкретно — смущает эта единица. Там же L стремится к бесконечности, так какой математический смысл вкладывается, когда пишут L+1?
Насколько понимаю, в такой схеме перелив энергии будет только по цепочке. То есть, если у нас аккумулятор 1 заряжен сильней, а аккумулятор 15 заряжен слабей всего, то энергия из первого в 15 будет перекачиваться через 2..14 аккумуляторы. Как быстро энергия перетечет через 13 банок?
Такое устройство балансирует аккумуляторы по напряжению. Насколько будет хуже или лучше по сравнению с предложенной схемой, если вывести с каждого аккумулятора оба вывода на разъем и разъемом-заглушкой включать их либо параллельно — для зарядки, либо последовательно — для работы?
Да, действительно. Виноват. Но в контексте вопроса это не особо важно. Не опережения зажигания — так моменты начала и конца впрыска. Принцип-то один и тот же: не превышать некоторую пороговую температуру, после которой азот в воздухе начинает соединяться с кислородом. И этот принцип идет вразрез с мощностью — на дизелях в том числе.
Просто отключили и нигде ничего не сказали? Наверное, это связано или с оптимизацией или с антитеррористическими мерами. Будем надеяться, что это временное.
Не знаю как вы выбираете, но очевидно индустрия дорогих моющих средств держится на таких как вы. Это не самый дешевый вариант, а раза в 3-4 дороже реальных цен.
В том же спринге, например, xml-конфиг ссылается на какие-то внешние ресурсы, но эти xml так же есть внутри jar, и он их берет из jar, а не подтягивает из интернета. Как это сделано, я не разбирался.
Только это не грабля java, а грабля из области concurrency.
«Уронить» что-то с орбиты так, чтобы оно долетело целым — довольно сложная техническая задача.
«Наверное, насекомые чувствуют ионный ветер, и они его не любят, поэтому не залетают туда» — это по отзыву радиолюбителя, который такую ловушку когда-то спаял.
Именно в этом и заключается преимущество back-ups. Он практически ничего не делает — и при этом хорошо работает.
back-ups я бы не назвал бесполезным, а тем более «бесполезным на редкость», и «пустой тратой». Например, если речь идет о питании компьютера, то может быть так, что все что круче back-ups — излишество. Конечно, речь о случаях, когда БП в компьютере стоит хороший — но обычно только такой и нужен, если речь заходит о том, что компу нельзя перегружаться из за случайных глюков. Хороший компьютерный БП поддерживает колебания входного напряжения на входе в довольно широком диапазоне (у меня ~160вольт тянул) — и в упсе такая регулировка просто ненужна. Так же, особо неважно насколько там хорошо аппроксимируется синусоида — потому что БП компьютера все равно ее выпрямляет. Строго говоря, для компьютера синусоида вообще ненужна, он совершенно спокойно работает от самопального ибп который делает меандр с паузами в нуле.
При этом, например, online упсы — это дополнительная схемотехника на входе питания, со своим уровнем надежности. Еще и за деньги. Результирующая вероятность безотказной работы равна произведению вероятностей безотказной работы каждого элемента. То есть от плохой сети мы защищаемся — но надежность оборудования получается ниже. Наверное, если сеть плохая, то в этом может быть смысл, но бывает что основная проблема — это не колебания, а отключения.
Что касается практики, то например у меня smart-ups известной торговой марки приходится вообще отключать от сети, когда дом переключаю на китайский безногенератор. Он не может понять, все хорошо с питанием, или все плохо — и щелкает своей релюхой. Но при этом, back-ups работает нормально от того же генератора.
А что вообще мог сделать не так министр экономического развития за 6 лет в стране, где развития не оказалось? Очевидно, развивать другие отрасли и прийти к тому, чтобы цена на нефть и курс вообще не волновали почти никого. Вместо этого в стране был внедрен oil-driven development.
Под убунтой все печательней. (наверное, под виндой тоже)
Дело в том, что System.currentTimemillis выдает время в миллисекундах, и оно не монотонно: в момент високосной секунды это время прыгает на 1000мс назад, но при этом запланированные с интервалом такси — выполняются с этим интервалом более-менее нормально — как будто время линейно. И получается этот прыжок назад надо как-то обрабатывать, если это важно.
Якобы в кернеле могут быть альтернативные time discipline при который часы ведут себя по другому, но есть ли они там и как их можно включить — я не разбирался.
А вскрытия не будет? Экспертизы. Могло ведь и убийство быть.
Если в безидейно подобранных вопросах, то я согласен, а если претензии к самому принципу, то не соглашусь.
Например, на сайте киевстара для отправки смс надо выбрать из набора 2 или 3 картинки с живой природой(когда-то так было, как сейчас — не знаю). Помоему, нормальный вариант капчи. По крайней мере, лучше, чем ввести буквы, на которых не сидит кот.
Но. Если нас устраивает последовательное выполнение, то эффективней выполнить задачи в одном потоке — это более cache-frendly. А если нас устраивает unordered, то может лучше не стек? Если потоки действительно одновременно пишут и читают вершину, там же на вершине на этой будет false sharing (в данном случае наверное даже true sharing). Время будет съедаться на миграцию кэшлайна между ядрами, можно словить 1000 кратную просадку производительности.
Вобщем, достаточно искуственный пример. И тесты, (предположу, что в них скорей всего нет оценки степени «разупорядоченности») неясно что меряют. Набор различных эффектов, проявивших себя в различной мере, и наложенных друг на друга случайным образом.
Можете добавить в тесты следующую фишку: Через стек передаем последовательный набор чисел: 1,2,3,4,5,6..., Снимаются эти числа (когда снимаем в том же потоке) в обратной последовательности. На снимающей стороне мы смотрим, действительно ли последовательность съема обратная. Если происходит скачок по отношению к предыдущему снятому значению в сторону увеличения — значит потоком-производителем была засунута новая порция данных. Мы заводим счетчик таких событий.
И дальше мы говорим, мол всего элементов было столько-то, а конкуррентных вставок было столько-то, и отношение этих величин такое-то.
И когда мы сравниваем реализацию с мутексами с реализацией на cas-ах и спинлоках, то сравнивать имеет смысл прогоны теста, с оглядкой на отношение этих величин. Потому, что ОС, когда она обрабатывает мутексы, то может будить потоки по-разному.
И потом еще надо прогнать сначала push а потом pop этих элементов в одном потоке. Причем, прогнать в двух вариантах:
1 — сначала push всех, потом pop всех. (элементов должны быть сотни мб)
2 — push и pop порциями размером не более 64 байт (чтоб гарантированно работать в одном кэшлайне), вершина стека должна быть выровненной по 64 байтам.
И тут сравнивать время обработки с многопоточным временем обработки. Неисключено, что по варианту 2 будет выигрыш.
а потом прогоните через разные многопоточные очереди такой же обьем данных. И сравние. Это крректно потому, что мы выше решили, что стек может дать как ordered так и unordered данные на принимающей стороне. Нормальная очередь будет более cache-frendly, по идее должно получится существенно быстрей.
Конечно, это все на уровне догадок. Реально чтоб сравнить, надо мерять как оно будет в конкретных числах.
tasks.withType(GroovyCompile) {groovyOptions.javaAnnotationProcessing = true}
при этом в груви-классах ast выполняются.
Такое устройство балансирует аккумуляторы по напряжению. Насколько будет хуже или лучше по сравнению с предложенной схемой, если вывести с каждого аккумулятора оба вывода на разъем и разъемом-заглушкой включать их либо параллельно — для зарядки, либо последовательно — для работы?