Возникает вопрос — а так ли нужен гелий? азотом не выйдет, если охладить его до 4К? Соответственно, охлаждение будет тогда не за счет испарения, а просто теплопередачей. Наверное это получится менее эффективно — но можно больше азота прокачивать, ведь он очень дешевый.
И плюс это ослабит требования к оборудованию. Гелий сверхтекуч, и через микротрещины уходит, с азотом этой проблемы не будет.
Разгребая последствия одного вейпоинта, весь тренд не остановить. Будут и дальше различные ужесточения ограничительных мер.
Так что вы б там лучше ориентировались, что так или иначе, но вашу деятельность придется прекратить. Надавят если не на вас — то на ваших покупателей. Если не прямо — то косвенно, и если не одним махом — то за несколько приемов. И когда это произойдет, то степеней свободы которые есть сейчас, уже не будет.
Специалисты бывают двух типов:
1 — я знаю технологию Х — буду делать на ней и ничего нового ненужно
2 — появилась технология У, которая лучше Х, давайте все перепишем на У
Первый тип никак не переманишь — второй сам перейдет и будет влиять на приток новых специалистов.
Для системного программирования раст хорош тем, что лучше продуман в плане безопасности. Если си подходит к решению задачи «можно все, но если напортачишь — ты ССЗБ» — то раст подходит к решению этой задачи с обратной стороны. Запрещено все, исключая белый список. Есть проверки выхода за границы массивов и тд. И поэтому ты не напортачишь так чтоб совсем все плохо стало. Вызвать сегментацию или UB можно только используя блок unsafe. И эти блоки — маленькие.
Кроме того, есть мелкие ништяки: например стрикт алиасинг в си идет для единиц трансляции, а в раст — каждом месте использования. Указатели на виртуальную таблицу в раст хранятся вместе с указателем, а не с данными (свои плюсы и минусы).
То, что BSP написаны на С — тоже не технический момент, а «организационный», и исторически сложившаяся в текущий момент времени данность. Раст, кстати, сопрягается с другими языками. В первую очередь с си. Так что вобщем «в железо» это тоже можно шить, теоретически. Но там скорей всего придется шпарить без растовской stdlib.
Думаю, си и плюсы — устарели, и их преимущество лишь в том, что к ним много написано кода и много есть специалистов.
Был проведён в 1953 году Стэнли Миллером и Гарольдом Юри. Аппарат, спроектированный для проведения эксперимента, включал смесь газов, соответствующую тогдашним представлениям о составе атмосферы ранней Земли, и пропускавшиеся через неё электрические разряды.
То есть, по сути, финны подобрали ток и частоту импульсов?
А почему ремонт после квенча — дорогой? где-то выше в каментах кто-то называл цифру 200тыс евро. Это продиктовано объективными техническими причинами, или монопольной составляющей?
Насколько я понял, ремонт заключается в заправке жидким гелием и накачке катушки током. Первое — обычное обслуживание криотехники. Подъехала машина — и заправила бак. Второе — процесс, который делается автоматически, специальным дэвайсом.
На ютуб по запросу «mri quench» есть некоторое кол-во видео, в которых группа людей специально вызывает квенч — и радуется этому явлению. Чему там можно радоваться?
Почему обязательно гелий? Есть же высокотемпературные сверхпроводники, у которых температура сверхпроводимости выше температуры кипения жидкого азота. По идее с такими сверхпроводниками все должно быть вообще дешево.
Ну стул — понятно. Медицинское оборудование — тоже понятно. И даже понятно, когда туда затягивает шуруповерт. Но каким образом в эти магниты прилетает тележка из супермаркета??? КАК?
Хм, тогда в чем разница, подключать ток ненагревая, или выключать нагрев после достижения нужного тока? Ведь, когда нагрев отключают, и сопротивление участка падает до 0 — по участкам начинает течь такой же ток, как если бы изначально все подключили ненагревая.
Насколько я понимаю из картинки — если не греть часть проводника, то ток через оба плеча будет бежать примерно равный, и тогда при отключении источника тока токи в плечах «уравновесят» друг друга и течь там вообще ничего не будет.
Тут больше интересно, зачем ток наращивают медленно, почему нельзя быстро?
И как источник тока отключают от обмотки. Там же резистор этот, получается, надо мгновенно охладить, иначе ток упадет.
Зачем в списке моделирование и моделирование железных дорог? Если их разделили — чем авторов обидело авиамоделирование?
Зачем в списке работа с деревом и резка по дереву?
Писательство и ведение дневника — это одно хобби, а ведение блога — это другое. Зачем их разделили? И если их разделили, то почему в отдельную категорию не выделили виндсерфинг, кайтинг, парапланеризм, диггерство, руфинг, урбантуризм, бейсджампнг и роупджампинг?
Гортранспорт — это отдельный вид хобби, только не спрашивайте меня как это. Хотя это и экзотика, но экзотика не более, чем некоторые позиции в списке.
И да, спасибо что смотрение футбола в список не попало. Это не хобби, а стадный инстинкт. Но вот устраивание драк после спортивных состязаний — это форма хобби. Хотя, стенка на стенку — тоже вобщем-то хобби.
Несколько странно, что бильярд попал в отдельную категорию. Тогда надо идти на сайт министерства спорта — и брать оттуда весь список видов спорта.
По правилам криптографии, непроверяемо = скомпрометировано.
Так что, абсолютно неважно, сливает Дуров инфу в ФСБ, или не сливает.
Думаю, если конфликт действительно был бы, то его бы живым с россии не выпустили б.
насколько знаю — на андроидах не jvm, а псевдо-jvm. Там что-то с правами гугл и оракл не поделили. Работает она, насколько знаю, хуже, в нее вложено гораздо меньше человеко-часов. Все, что я писал о jvm, относилось к оракловской. Про андроид я не могу сказать ничего.
в ответ на жалобы про то, что всё тормозит и «дёргается» мне заявляют, что в последней версии этих проблем нету,
нет, почему же. В андроидовской это может быть, и, вероятно, есть. И, подозреваю, в последней версии это не починят. И вряд ли в обозримом будущем починят.
Если говорить про IDE, это весьма поверхностное рассуждение. Запустите ту IDE, которой на XT пользовались — тормозить не будет. А то что вы решили пользоваться более новой IDE — так тут никто ничего не обещал :))) На практике в IDE прикручивают фичи до тех пор, пока она не начинает тормозить. Но эти фичи настолько удобны, что все с этими тормозами миряться — и никто не хочет брать старую IDE. Кстати, idea не тормозит особо, и часть ее тормозов связаны с операциями ввода-вывода.
И это — одно из самых больших достоинств C/C++!
Тут вы просто мыслите эмоциями. Для индустрии то, что нужна высокая квалификация программистов — недостаток, и весь мир идет по пути снижения планки.
Не знаю, о чем вы. Если это при первом вызове, то возможно что-то такое и есть. А если бы каждый вызов такого pritln добавлял что-то в кучу — вероятно оно бы не работало совсем. Вообще, набор стандартных библиотек действительно хреновастенький, и то что оно не всегда оптимально все делает — исторически сложившийся факт. В настоящее время, желание сломать обратную совместимость и все исправить — все больше. У сишников в этом плане все оказалось настолько сломанным, что чинить уже особо никто не пытается. Хочешь новое — пользуй rust.
Касаемо возражений по существу — на «прогретом» коде, помоему начиная с jvm6, это все будет аллоцироваться в стеке и оптимизироваться (и в седьмой это будет делаться — лучше чем 6), так что масштаб трагедии снова преувеличен.
Что касается локалей — тут все плохо. К нашему вопросу это не относится, но насколько я помню, glib каждый раз когда ты делаешь какой-нибудь %f лазит в файлы локалей. То есть не 1 раз при старте, а вообще каждый раз. (возможно, это уже починили) Так что я бы не сравнивал.
это не недостаток, а достоинство
Это достоинство если под другим углом смотреть. А область применения такого подхода это ограничивает. Так что недостаток. Да, в редких случаях действительно можно получить профит, но на практике обычно профит нужен не в этом месте.
Если вы перепишите «идеоматический Java-код» на C/C++ — то вы замучаетесь бороться с утечками памяти и ресурсов полученный монстр будет тратить больше, чем в Java!
Да, так и есть.
На бенчмарках как раз можно заставить всю эту машинерию с многоуровневыми GC в Java работать прилично
да, но в данном случае там все проще: люди получили 4х кратную просадку в производительности используя разные подходы к распараллеливанию. И утверждают, что это тормоза языка. В результате периодически вижу людей, которые особо не вникая пользуются результатами их сравнения как эталоном — и потом показывают другим. Я рад, что вы туда не ходите. Вы и дальше туда не ходите, там меряют неправильно.
программа уже в таком состоянии, что ей мало что помочь может
С си до такого состояния хрен дорастешь, используя тех же людей который накодили говнокод на жабе :)). Раньше упрешься в какую-нибудь архитектурную сложность, понадобится рефакторинг, ты его не сможешь сделать нормально и тд.
На жабе я уже несколько раз пытался _специально_ создать такую фрагментацию, которая бы долго чистила и уплотняла хип. У меня это выходило более-менее только с мягкими ссылками. Вот если хип загадить SoftReference-ами, то да, может быть full gc, который их грохать будет по одному (если механизм их устаревания не сработает). То есть примерно так: Забиваем весь хип SoftReference-ами, а потом создаем 100 объектов, и можно (теоретически) подобрать так, что что full gc дернется 100 раз, подчищая каждый раз по 1 мягкой ссылке. А вот без мягких ссылок вызвать долгий full gc вообще не получалось. Хотя в интернете есть сведения, что у людей бывало, что хип чистился десятки минут. Вероятно, они нарывались на описанный случай или что-то похожее.
Вообще, тем кому ненравится java и нравится си, надо на rust смотреть. На мой взгляд, си — устаревшая небезопасная штука, и потому должна уйти.
Так. Ок. А какую позицию я отстаивал?
Шучу. Это помню, конечно.
Только вот то, что java тратит больше памяти — вы должны знать. А то, что java уплотняет — я уже рассказал выше. Так что, по всей видимости, вы тоже забыли, в чем стояла задача. Так что, возможно, проблема обсуждалась несколько шире. :)
Вкладывать структуры в си можно, но Все перечисленные вами достоинства этого метода не относятся к фрагментации. Кроме того, вы не упомянули недостатки метода — используя вложенные структуры, нельзя создавать циклические ссылки.
Идея о виртуальной памяти — ну ок. Но насколько понимаю, при наличии дырки размером в страницу в хипе, full gc не вызовется. То есть, большие дырки — это не тот случай, когда проблема фрагментации актуальна.
У меня выходило воспроизводить ситуации, в которых активно вызывается full gc только когда использовал SoftReference. В си аналогии нет — и считайте, что его просто не используют. Если его не использовать в и java, то тормозов gc добиться будет практически нереально.
Кстати, а вы посетитель Benchmarks Game? Просто для статистики хочу знать, сколько человек клюнуло на эту удочку.
Честно говоря, мы это обсуждали так давно, что я не помню концепцию.
Ваш камент сам по себе, в отрыве от контекста, выглядит разумным, и мой выше — точно так же.
Возможно, в рамках концепции я бы что-то возразил, но я уже не помню, в чем там у нас заключалась идея, и какую задачу мы решали — а вспоминать нет смысла.
Возникает вопрос — а так ли нужен гелий? азотом не выйдет, если охладить его до 4К? Соответственно, охлаждение будет тогда не за счет испарения, а просто теплопередачей. Наверное это получится менее эффективно — но можно больше азота прокачивать, ведь он очень дешевый.
И плюс это ослабит требования к оборудованию. Гелий сверхтекуч, и через микротрещины уходит, с азотом этой проблемы не будет.
Так что вы б там лучше ориентировались, что так или иначе, но вашу деятельность придется прекратить. Надавят если не на вас — то на ваших покупателей. Если не прямо — то косвенно, и если не одним махом — то за несколько приемов. И когда это произойдет, то степеней свободы которые есть сейчас, уже не будет.
1 — я знаю технологию Х — буду делать на ней и ничего нового ненужно
2 — появилась технология У, которая лучше Х, давайте все перепишем на У
Первый тип никак не переманишь — второй сам перейдет и будет влиять на приток новых специалистов.
Кроме того, есть мелкие ништяки: например стрикт алиасинг в си идет для единиц трансляции, а в раст — каждом месте использования. Указатели на виртуальную таблицу в раст хранятся вместе с указателем, а не с данными (свои плюсы и минусы).
То, что BSP написаны на С — тоже не технический момент, а «организационный», и исторически сложившаяся в текущий момент времени данность. Раст, кстати, сопрягается с другими языками. В первую очередь с си. Так что вобщем «в железо» это тоже можно шить, теоретически. Но там скорей всего придется шпарить без растовской stdlib.
Думаю, си и плюсы — устарели, и их преимущество лишь в том, что к ним много написано кода и много есть специалистов.
Был проведён в 1953 году Стэнли Миллером и Гарольдом Юри. Аппарат, спроектированный для проведения эксперимента, включал смесь газов, соответствующую тогдашним представлениям о составе атмосферы ранней Земли, и пропускавшиеся через неё электрические разряды.
То есть, по сути, финны подобрали ток и частоту импульсов?
Насколько я понял, ремонт заключается в заправке жидким гелием и накачке катушки током. Первое — обычное обслуживание криотехники. Подъехала машина — и заправила бак. Второе — процесс, который делается автоматически, специальным дэвайсом.
На ютуб по запросу «mri quench» есть некоторое кол-во видео, в которых группа людей специально вызывает квенч — и радуется этому явлению. Чему там можно радоваться?
Почему обязательно гелий? Есть же высокотемпературные сверхпроводники, у которых температура сверхпроводимости выше температуры кипения жидкого азота. По идее с такими сверхпроводниками все должно быть вообще дешево.
Тут больше интересно, зачем ток наращивают медленно, почему нельзя быстро?
И как источник тока отключают от обмотки. Там же резистор этот, получается, надо мгновенно охладить, иначе ток упадет.
Столбцы — ясно. Но что означают строки — непонятно.
Зачем в списке работа с деревом и резка по дереву?
Писательство и ведение дневника — это одно хобби, а ведение блога — это другое. Зачем их разделили? И если их разделили, то почему в отдельную категорию не выделили виндсерфинг, кайтинг, парапланеризм, диггерство, руфинг, урбантуризм, бейсджампнг и роупджампинг?
Гортранспорт — это отдельный вид хобби, только не спрашивайте меня как это. Хотя это и экзотика, но экзотика не более, чем некоторые позиции в списке.
И да, спасибо что смотрение футбола в список не попало. Это не хобби, а стадный инстинкт. Но вот устраивание драк после спортивных состязаний — это форма хобби. Хотя, стенка на стенку — тоже вобщем-то хобби.
Несколько странно, что бильярд попал в отдельную категорию. Тогда надо идти на сайт министерства спорта — и брать оттуда весь список видов спорта.
ну и так далее.
а эти ресурсы в винде что — незапаролены? Так написано, как будто вирь влез не через дырку, а через штатную возможность.
Так что, абсолютно неважно, сливает Дуров инфу в ФСБ, или не сливает.
Думаю, если конфликт действительно был бы, то его бы живым с россии не выпустили б.
насколько знаю — на андроидах не jvm, а псевдо-jvm. Там что-то с правами гугл и оракл не поделили. Работает она, насколько знаю, хуже, в нее вложено гораздо меньше человеко-часов. Все, что я писал о jvm, относилось к оракловской. Про андроид я не могу сказать ничего.
нет, почему же. В андроидовской это может быть, и, вероятно, есть. И, подозреваю, в последней версии это не починят. И вряд ли в обозримом будущем починят.
Если говорить про IDE, это весьма поверхностное рассуждение. Запустите ту IDE, которой на XT пользовались — тормозить не будет. А то что вы решили пользоваться более новой IDE — так тут никто ничего не обещал :))) На практике в IDE прикручивают фичи до тех пор, пока она не начинает тормозить. Но эти фичи настолько удобны, что все с этими тормозами миряться — и никто не хочет брать старую IDE. Кстати, idea не тормозит особо, и часть ее тормозов связаны с операциями ввода-вывода.
Тут вы просто мыслите эмоциями. Для индустрии то, что нужна высокая квалификация программистов — недостаток, и весь мир идет по пути снижения планки.
Не знаю, о чем вы. Если это при первом вызове, то возможно что-то такое и есть. А если бы каждый вызов такого pritln добавлял что-то в кучу — вероятно оно бы не работало совсем. Вообще, набор стандартных библиотек действительно хреновастенький, и то что оно не всегда оптимально все делает — исторически сложившийся факт. В настоящее время, желание сломать обратную совместимость и все исправить — все больше. У сишников в этом плане все оказалось настолько сломанным, что чинить уже особо никто не пытается. Хочешь новое — пользуй rust.
Касаемо возражений по существу — на «прогретом» коде, помоему начиная с jvm6, это все будет аллоцироваться в стеке и оптимизироваться (и в седьмой это будет делаться — лучше чем 6), так что масштаб трагедии снова преувеличен.
Что касается локалей — тут все плохо. К нашему вопросу это не относится, но насколько я помню, glib каждый раз когда ты делаешь какой-нибудь %f лазит в файлы локалей. То есть не 1 раз при старте, а вообще каждый раз. (возможно, это уже починили) Так что я бы не сравнивал.
Это достоинство если под другим углом смотреть. А область применения такого подхода это ограничивает. Так что недостаток. Да, в редких случаях действительно можно получить профит, но на практике обычно профит нужен не в этом месте.
Да, так и есть.
да, но в данном случае там все проще: люди получили 4х кратную просадку в производительности используя разные подходы к распараллеливанию. И утверждают, что это тормоза языка. В результате периодически вижу людей, которые особо не вникая пользуются результатами их сравнения как эталоном — и потом показывают другим. Я рад, что вы туда не ходите. Вы и дальше туда не ходите, там меряют неправильно.
С си до такого состояния хрен дорастешь, используя тех же людей который накодили говнокод на жабе :)). Раньше упрешься в какую-нибудь архитектурную сложность, понадобится рефакторинг, ты его не сможешь сделать нормально и тд.
На жабе я уже несколько раз пытался _специально_ создать такую фрагментацию, которая бы долго чистила и уплотняла хип. У меня это выходило более-менее только с мягкими ссылками. Вот если хип загадить SoftReference-ами, то да, может быть full gc, который их грохать будет по одному (если механизм их устаревания не сработает). То есть примерно так: Забиваем весь хип SoftReference-ами, а потом создаем 100 объектов, и можно (теоретически) подобрать так, что что full gc дернется 100 раз, подчищая каждый раз по 1 мягкой ссылке. А вот без мягких ссылок вызвать долгий full gc вообще не получалось. Хотя в интернете есть сведения, что у людей бывало, что хип чистился десятки минут. Вероятно, они нарывались на описанный случай или что-то похожее.
Вообще, тем кому ненравится java и нравится си, надо на rust смотреть. На мой взгляд, си — устаревшая небезопасная штука, и потому должна уйти.
Шучу. Это помню, конечно.
Только вот то, что java тратит больше памяти — вы должны знать. А то, что java уплотняет — я уже рассказал выше. Так что, по всей видимости, вы тоже забыли, в чем стояла задача. Так что, возможно, проблема обсуждалась несколько шире. :)
Вкладывать структуры в си можно, но Все перечисленные вами достоинства этого метода не относятся к фрагментации. Кроме того, вы не упомянули недостатки метода — используя вложенные структуры, нельзя создавать циклические ссылки.
Идея о виртуальной памяти — ну ок. Но насколько понимаю, при наличии дырки размером в страницу в хипе, full gc не вызовется. То есть, большие дырки — это не тот случай, когда проблема фрагментации актуальна.
У меня выходило воспроизводить ситуации, в которых активно вызывается full gc только когда использовал SoftReference. В си аналогии нет — и считайте, что его просто не используют. Если его не использовать в и java, то тормозов gc добиться будет практически нереально.
Кстати, а вы посетитель Benchmarks Game? Просто для статистики хочу знать, сколько человек клюнуло на эту удочку.
Ваш камент сам по себе, в отрыве от контекста, выглядит разумным, и мой выше — точно так же.
Возможно, в рамках концепции я бы что-то возразил, но я уже не помню, в чем там у нас заключалась идея, и какую задачу мы решали — а вспоминать нет смысла.