Pull to refresh
5
0,1
Rating
1
Subscribers
Send message

Вариант с внешней видюхой не очень хорош тем, что такие видюхи гораздо дороже аналогичных внутренних

Не понял вас, вы покупаете или готовое устройство (относительно дорого), или просто пачку проводов с Али (дешево) и подключаете обычную десктопную видеокарту. Т.к. она на коробочку оказывается непосредственно не завязана ее легко менять, если вдруг хочется.

Даже в этом контексте, есть смысл рассмотреть вариант с 2 ПК: один стационарный с нормальным железом, для дома и один портативный для разъездов.

И удачи вам бесконечно синковать данные между двумя рабочими окружениями, либо покупать сопоставимую по моще с нормальным железом но портативную версию стационарного компа, чтобы всегда работать только на ней.

Тут смысл именно в этом - одно устройство, достаточно мощное чтобы нормально работать, а играть за счет внешней GPU.

Иметь проц от Intel и не ставить Thunderbolt ... но почему? можно было бы внешний GPU подключить, это бы заметно расширило применимость моделей

старая система позволяла ввести только 40 символов — и она не позволяла использовать дефисы, поэтому нельзя было использовать краткую форму, например, «Пн-Ср», чтобы показать, что вы свободны с понедельника по среду.

Интересно чем плохо было бы использовать Пн:Ср, или даже [Пн1000, Пн1630)

Стектрейс покажет вам место ошибки, а не ее причину. Чтобы докопаться до причины бывает полезно понимать нюансы используемого языка - некоторые из этих самых нюансов и спрашивают.

Но нет же, разная архитектура команд дает разницу в реальных вычислениях за такт, впрямую сравнивать циферки некорректно, вы в своем примере сравниваете как раз производительность в задаче (перемещение определенного груза на определенное расстояние за определенное время). Вы сравниваете с какой скоростью может перемещать определенный груз определенный механизм, а не на каких оборотах работает у этого механизма двигатель.

Ровно то что я и написал, мне не нравится аппеляция к цифрам в показателях тактовых частот

Есть ощущение что меня не правильно поняли: я не защищаю ни чью позицию, я только указываю что прямое сравнение циферок выглядит плохо. Можно сравнивать производительность на задачах. Не понял пчм если, допустим, у человека отличная статья, но где-то написано что 2+2=5 (без развернутых пояснений к этому тезису) то указать автору на странность ситуации вызывает такую бурную реакцию.

И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте. И у этого есть вполне определённая причина – особенности архитектуры у VLIW-процессоров. А конкретно для Алексея вопрос можно переформулировать следующим образом – почему Эльбрус(e2k), который постоянно выставляется как главный процессор от МЦСТ и в который вкладываются основные разработческие ресурсы, уступает по частоте процессорам линейки Sparc от МЦСТ, в которые всегда вкладывались намного меньше? Т.е. дело не деньгах и нанометрах, а в принципиальных ограничениях VLIW-архитектур.

А если спидометр у одной машины размечен в милях в час, а у другой в км/ч, это значит что первая машина впринципе не может ехать так же быстро как вторая? Вы говорите о принципиальной разнице в архитектурах процессоров, но при этом предлагаете сравнивать тактовые частоты - как-то странно выглядит.

Случалось пользоваться этим умением когда чинил баги в чужом коде - понимание моментов где может быть подвох иногда помогало быстро найти проблемное место

А куда делся белый воротничок рубашки? Не верится что сетка могла вот так взять и сильно выделяющийся фрагмент картинки выкинуть :)

Возможно вкусовщина, но мне показалось не удобным читать цепочку снизу вверх - такая последовательность сборки правил чем-то обусловлена (кроме "так получилось")?

Похоже я вас задел, прошу прощения, кусочек про ваш проект на Scala как-то выпал у меня из поля зрения при прочтении. Вы абсолютно правы, с sbt я дел никогда не имел, с тех пор как использование для сборки Ant стало достаточно устаревшим пользуюсь Maven.

Отчасти меня извеняет тот факт что Scala я никогда не использовал и не смотрел, а судя по описанию указанного вами инструмента он популярен не для Java.

Внимательно читая фрагмент про ваш проект бросились в глаза достаточно странно формируемые строки s"""strategy/target/scala-2.13/strategy_2.13-0.1.0-SNAPSHOT.jar""" , я конечно совершенно не знаю как работает build.sbt, но не содержит ли "strategy_2.13-0.1.0-SNAPSHOT.jar" жестко захаркоженную версию используемого в сценарии кода?

Описанная вами методика ускорения загрузки очень интересна, подскажите пожалуйста, если вы могли себе позволить один раз прогреть JVM и обогатить ее память данными из СУБД, а после по необходимости загружать в нее регулярно изменяемые классы над которыми работаете, у вас получается загружаемые классы никак не изменяли эти загруженные данные?

Судя по "scala-2.13" вы писали свой проект пару лет назад, с учетом интересных примененных решений может быть расскажете о его текущем состоянии?

Я правильно понял что автор работавший Java-разработчиком и разрабатывавший либо без инструментов сборки типа maven, либо не умеющий в них настраивать профили сборки кого-то учит жизни?

Законы Вселенной учат нас не только тому, что в Мире нет единого расписания всех событий, но и тому, что сам Мир многовариантен и живет одновременно в огромном количестве временных срезов. В нашем временном срезе «Столпы творения» сияют в центральной части туманности «Орёл» в созвездии Змеи, но для гипотетического наблюдателя одной из звезд скопления М16 актуален другой временной срез, где иное положение дел

В кинотеатре Земли прокатывают первую часть космооперы "Столпы Творения", в кинотеатре в районе М16 прокатывают вторую часть, а на съемочной площадке давным давно снимают другое. Ровно такая же история у нас на Земле повторяется с множеством фильмов, и что, Земля тоже живет одновременно в разных временных срезах? Какие-то странные выводы делаются из того факта, что радиоволны проходят разное расстояние за разное время.

Есть мнение что основные положения логики высказываний были описаны несколько раньше, и до "кобыл" современности этим положениям примерно все равно. Не надо совать свой квантр общности туда где в явном виде об общности не говорили, и проблемы с трактовкой не будет :)

В конце (42-ая 43-яя минуты) сказана откровенная преднамеренная ложь, цитата: "при идеальном раскладе у такой двухкомпонентной ядерной энергетики практически нет никаких вредных выбросов или отходов"

В цитируемом вами высказывании есть целых 2 явно введенных допущения, учитывая их оно истинно примерно всегда и ложью не является.

А какая разница какой архиватор, если он работает и задачу выполняет? 7zip, например, без проблем открывает такой архив

Ни один из выделенных вами пунктов в данной ситуации не выглядит приминимым - цена не является ложной (после показа ценового предложения оно не меняется и после авторизации) рассчеты за товары/услуги происходят как и всегда, в соответсвии с законодательством, доверительные отношения тут вообще ни каким боком не подходят - цена (хоть высокая, хоть низкая) с доверием вообще никак не связана

А было бы круто если бы эти самые новые формы само разрабатывающее их ведомство публиковало сразу и в каком-нибудь открытом машинночитаемом шаблонном формате, xml-xsd / JSON-SCHEMA и т.п., выглядит как чуточка стандартизации, и очень большая экономия трудозатрат

Зачем отъедать столько места на экране выводя 6 раз слово целиком, когда пользователь уже выбрал какое именно он слово хочет напечатать?

похоже что если после выбора слова оставлять только варианты различающие формы слова (например с вариантом быстрого подтверждения автоматически поставленного) будет значительно аккуратнее

Противоречия тут похоже что нет: ленивая загрузка полей класса достаточно распространена среди ORM

Вам бы чуть-чуть дополнить статью, упомянуть что Rich Domain не единственный вариант, бывают ещё и другие. А то получается двояко - вроде и по делу, например, про Entity написано, и одновременно нет - вполне может быть вариант, например, где ответственность за правильность создания сущности (сообразность укладываемых в нее данных) лежит на пораждающем классе, а сама сущность вообще immutable.

Information

Rating
4,130-th
Registered
Activity