mayton2019

Будет использован invokevirtual

class MyClass
{
   public void method()
   {
     System.out.println("OK");
   }


   public static void main(String[] args) {
     MyClass obj = new MyClass();
     obj.method();

   }
}

Compiled from "MyClass.java"
class MyClass {
  MyClass();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void method();
    Code:
       0: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #13                 // String OK
       5: invokevirtual #15                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return

  public static void main(java.lang.String[]);
    Code:
       0: new           #21                 // class MyClass
       3: dup
       4: invokespecial #23                 // Method "<init>":()V
       7: astore_1
       8: aload_1
       9: invokevirtual #24                 // Method method:()V
      12: return
}

Сложно судить о проблемах только по CPU.

Например если у тебя система, которая делатет рендеринг картинок или кодирует видео то она
обычно забирает столько CPU сколько есть в наличии.

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

А очередь диска или загрузка ядер CPU в данной задаче не говорят ни о чем обычно. Может они - высокие
но бизнес чувствует себя нормально. А может быть 1 % CPU занят но база в блокировках и эта проблема не
видима со стороны системных метрик.

Если вы используете хранилище типа S3 то там есть опция - при сохранении файла (объекта в терминологии
S3), можно задать атрибут Time-To-Live

Вся прочая автоматизация - поверх обычных файловых систем требует чтоб был отдельный процесс
который по плану (раз в минуту например) удаляет все файлы по дате создания. Это cron, про который
выше уже сказали или это какой-нибудь quartz в парадигме Spring-Java-разработок например.

Не уверен что регулярки помогут. Но я-бы видел поиску нулей как-то такой интеграцией.

find . -name '*bills*' -exec is_file_contains_zeroes {} \;

здесь find - стандартная утилита а is_file_contains_zeroes вам напишет любой программист за 15 минут.

Но если битый винт содержал именно ДОКУМЕНТЫ то правильнее всего их искать именно валидатором
документов а не искателем нулей. Выше Adamos вобщем-то дал правильную линку на дубль этого вопроса.

Ну и на будущее чтоб не "бились винты" - делай бекапы. Потому что игры в восстановление - это не
production ready сценарий и за такие документы уже никто не даст цену. Грубо говоря они стали
мусором. Сомневаюсь что валидаторы закроют 100% сценариев разрушения.

Говорит нет такого сайта https://repo.implario.dev

Тут ничего не поделать. Доктор сказал - в морг.

Если у тебя будет 100 нод-получателей то полюбому хотя-бы одна из них будет недоступна в момент отправки.
Такова природа вещей. И не стоит требовать от сетей перфекционизма. Сети работают как погода. Как дождь
или снег. Надо это учитывать.

Поэтому брокер сообщений на базе Kafka или Apache Pulsar или Rabbit будет вполне себе реальным решением.

Ты пишешь про p2p. Но какой ценой этот p2p ты собираешся поддержать на продюсере? Ты создашь 100 сокетов
и 100 буферов отправки сообщений?

Потому что другого выхода у тебя на самом деле нет. Или у тебя просто не пройдет транзакция я гарантирую
это.

Очень похоже на шейпер со стороны провайдера. Попробуй понять как его обнулить.
Например закрой торрент клиент и посмотри чтоб все сокеты закрылись. А потом запусти
снова. Будет ли первоначальная картинка? Или там может шейпер сбрасывает по времени.
Через 5 минут. Через час.

Кошки или некоторые породы собак могут эффективно душить крыс.

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

Выше оди чел написал про то что запах кошачьей мочи отпугивает крыс. Подтверждаю.
Я это слышал про мышей. Но думаю что эффет на крыс будет тоже подобный.

Еще где-то слышал что в первую мировую крыс в окопах эффективно душили
собаки питбуль.

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

Еще есть "усы" https://mustache.github.io/

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

Википедия пишет

Достижение устойчивого состояния не гарантирует правильный ответ сети. Это происходит из-за того, что сеть может сойтись к так называемым ложным аттракторам, иногда называемым «химерами» (как правило, химеры склеены из фрагментов различных образов).

Скорее всего это просто особенность этого вида сети.

Попробуй повторить обучение сети с усилением количества тех образов, которые максимально
далеки от этих твоих точек.

Если важна скорость. То я-бы предложил такой вариант. Делай полностью клон БД.
Физически копируй. Потом выключай constraints. И удаляй те 95% данных которые надо удалить.
Справочники - не трогай. Они маленькие обычно и роли не играют в объеме.

После этого - включай констрейнты - и база готова. Возможно в процессе включения будет
ругань на связи между таблиц фактов. Там надо соотв. вручную подчистить.

P.S. Очень жаль что ты не указал тип DBMS. Там есть разные варианты. Экспорт. Бэкап. Горячий холодный.

Knowledge transfer лучше всего делать с включеной трансляцией экрана и с записью.
Вопросы и ответы. Все должно быть на видео. Как всегда у вас будет нехватка времени
и этих двух недель не хватит на документирование всего. Да и невозможно это все писать
в спешке. Поэтому голосом передавайте. Потом будете пересматривать. Вопросы
должна спрашивать вся команда. Потому что новичек может ничего не спросить по причине
перегрузки информаций.

Таких Knowledge transfer должно быть несколько штук. Хотя-б по 1 за 2 дня. Тоесть за две
недели вы можете 5 раз встретится.

Total Commander - это хитрая штука. Она например может копировать файлы в несколько сессий.
Иногда это дает буст к скорости копирования а иногда может оказать "медвежью услугу" для некоторых
источников которые плохо параллелятся.

Провертье настройки Total Commander.

Вообще comparison требует сравнения всего содержимого файлов поэтому по сложности он эквивалентен
копированию "со всех шар" к себе в память. И срезать здесь углы нигде невозможно.

Гит всегда разрешает параллельную разработку. Никто не заблокирован никогда.
Другой вопрос, если ты просто сделал бранч из branchOne, то ты сам как-бы принял риски
того что этот бранч еще может изменится.

И в целом это вопрос не про гит а про организацию процессов и риски.

Без конкретного моделирования угрозы это невозможно.
Самая безопасная ОС как правило это бесполезная и неудобная ОС. Или вообще
отключенная от сети.

По поводу Manjaro. С моей точки зрения бесплатые ОС - всегда хуже чем платные.
Бесплатность в данном случае можно рассматривать как площадку для бета-тестинга.
Где лично вы, пользователь это и есть бета-тестер. Не удивляйтесь если вам будут
прилетать сырые обновления а RedHat Enterprise - будут более зрелые и проверенные.
Поэтому имеет смысл потратить денег на лицензию.

Преобразование Хафа ( https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D... )
позволяет находить на картинках длинные прямые линии. В виде уравнения прямой.
Тоесть точка например и угол.

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

Дизассемблирование и реверс бинарных файлов - это очень сложная задача.
Она стоит денег и обычно под это дело нанимают людей с опытом.

Были такие инструменты как SoftIce, IDA Pro. Они помогали профессионалам в дизассемблере
бинарей. Можешь попробовать но сразу скажу что это не задача на 5 минут. И в этой области
практически нет кухонных советов. Очень многие вещи не документированы и их надо
понимать в суперпозиции с опытом например использования Ассемблера и знания архитектуры CPU.
Короче это очень долгая и самостоятельная активность. И реально очень мало людей смогут
тебе помогать в процессе.

Хотя возможно твоя задача решается проще. Если сам создатель Paint Tool Sai заложил туда
такую возможность - то следует ей сначала воспользоваться. Это будет быстрее и без
лишнего оверхеда.

По поводу факториала 1000 и более толстых факториалов.
Есть формула Стирлинга. Она позволяет приблизительно прикинуть
число в вещественной форме.

Тебе это надо чтобы ответить на вопрос, а вообще принципиально возможно ли посчитать это
число и положить его в память. Например для 1000 последние члены этого ряда в умножении будут
добавлять по 3 десятичных разряда.

.......998 * 998 * 999 =

Должно быть порядка 2500 знаков.

По поводу AVX и прочее. Один регистр AVX будет брать 512 бит. В перерасчете на десятичную
систему - можно делить грубо на 3 и это будет 170 десятичных цифр. Тоесть надо много
таких регистров.

По поводу этого кода.

unsigned long long result = factorial[j] * i + carry;
            factorial[j] = result % BASE;
            carry = result / BASE;

Я не понимаю что здесь происходит. Зачем ты переводишь в систему счисления с основнием 1000000000

Двоичная система нормально работает. Используй ее возможности. А это - какой-то рудимент.

Я просто не программист, это у меня задание такое.
Сторонние библиотеки по условиям нельзя.

Про SIMD слышу впервые.

Это вообще приводит в изумление. По хорошему, мультипоточка и параллелизм это очень
сложная тема. Очень синьорная и в ней много всяких квантовых эффектов. И чтобы ей
просто заниматься нужно иметь хотябы 1-2 года опыта. Сомнительно чтобы новичек
вообще что то написал (и отладил под нагрузкой) работающее. Или разве что тебе
ChatGPT что-то там написал и ты просто случайно где-то проскочил. Повезло наверное.