Программирование, т. 8

omegalul

объясни

только если без слака

8гб оперативки на ноуте хватит для фонтенд хуйни чи не? 

нод жс сервер, вс код, браузер, +спотифай, дискорд, видосики на ютубе

да должно. у меня 16 но даже при большем кол-ве запущенного софта и задач - 8 не набирается. и да у меня линукс под работу.

Вскод+спотифай+дискорд+браузер это уже минимум 64 гб оперативки

angular-cli + webstorm + opera = почти все 8 заняты, хуй что еще откроешь

+хром + Стим + телега trollface

8гб оперативки на ноуте хватит для фонтенд хуйни чи не?

нод жс сервер, вс код, браузер, +спотифай, дискорд, видосики на ютубе

Хватит, ещё 3-4 останется. Тут зависит от того, сколько вкладок в браузере и на какой операционке.

сделайте зарплатный опрос в новой теме, хочу самоутвердиться 

Занес тебя в список ебучих буржуев

Да у него 1 сироп в офисе, вот и пытается за счет зарплаты выехать.

Есть в топане уважаемые фронтендеры с опытом разделения билда на версию для старых браузеров и версию для браузеров с поддержкой модулей?

 

 

только если без слака

  

 

Ну вот. Правда здесь по другому расписано, но ситуация та же.  

Там не могу изменить поле другого класса, хз почему. Но при этому существует функция получения координаты касания по экрану, а затем по этим координатам рисуется прямоугольник - там все ок передается. ХЗ  biblethump 

 

с

 

https://ru.stackoverflow.com/questions/939140/Не-могу-обратиться-к-другому-классу-drawview?noredirect=1#comment1561163_939140

 

 

 (разве что создание объектов в методе отрисовки будет пожирать тебе память, заставлять активно работать gc и всё будет плохо)

бред

 

(разве что создание объектов в методе отрисовки будет пожирать тебе память, заставлять активно работать gc и всё будет плохо)

бред

 

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

 

Если я не ошибаюсь, то в жабе synchronize всегда на каком то объекте, если synchronize просто на методе - то на объекте, который вызывает этот метод, если на статическом методе - на объекте метакласса.
И ключевое слово volatile неоч объяснил, я бы не понял, вряд ли оно поможет бтв.
Суть такова - у каждого потока есть свой кеш, куда они сохраняют переменные для ускорения обработки - у каких то реальное пространство в кеше, у каких то в оперативе, но это вас ебать не должно - это проблема ОС. Ну так вот, делая переменную volatile вы запрещаете кешировать потокам значение этой переменной. В чем смысл - поток может изменить значение переменной НО У СЕБЯ В КЕШЕ, все остальные потоки об этом не узнают, volatile запрещает потокам это делать, но на практике это не решает проблему состояния гонки, зато существенно замедляет работу с этой переменной, я даж сходу не могу придумать реальный пример, где volatile реально помогло.
Кеш это супер важная хуйня - если сравнивать скорость работы кеша 1-2 лвл, кеша 3лвл и оперативы, то кеш 1-2 уровня будет феррари, кеш 3 уровня запорожец, а оператива - велосипедист.

Изменено 3 февраля 2019 пользователем Matriarch

 

 

 

Ну вот. Правда здесь по другому расписано, но ситуация та же.  

Там не могу изменить поле другого класса, хз почему. Но при этому существует функция получения координаты касания по экрану, а затем по этим координатам рисуется прямоугольник - там все ок передается. ХЗ  biblethump 

 

с

 

https://ru.stackoverflow.com/questions/939140/%D0%9D%D0%B5-%D0%BC%D0%BE%D0%B3%D1%83-%D0%BE%D0%B1%D1%80%D0%B0%D1%82%D0%B8%D1%82%D1%8C%D1%81%D1%8F-%D0%BA-%D0%B4%D1%80%D1%83%D0%B3%D0%BE%D0%BC%D1%83-%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D1%83-drawview?noredirect=1#comment1561163_939140

 

 

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

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

для того чтобы что-то гарантировать сделай выполнение нужных кусков однопоточным - делается это через лок на монитор какого-то одного объекта, для простоты можешь создать новый класс с названием ru.debil.myproject.MyLock и делать synchronize по "объекту класса", т.е. помоему в джаве это будет выглядеть так - "synchronize(ru.debil.myproject.MyLock.getClass()) { ... }

внутри таких блоков у тебя будет однопоточность.

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

затем залоггируй что там в них происходит + таймштамп лога

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

 

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

PS

попробовал загуглить тупо текст эксепшны который автор описывает на стековерфлоу

и, О ЧУДО, кажется я нашел ответ на проблему https://ru.stackoverflow.com/questions/514856/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-attempt-to-invoke-virtual-method-on-a-null-object-reference

 

 

 

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

И ключевое слово volatile неоч объяснил, я бы не понял, вряд ли оно поможет бтв.

Суть такова - у каждого потока есть свой кеш, куда они сохраняют переменные для ускорения обработки - у каких то реальное пространство в кеше, у каких то в оперативе, но это вас ебать не должно - это проблема ОС. Ну так вот, делая переменную volatile вы запрещаете кешировать потокам значение этой переменной. В чем смысл - поток может изменить значение переменной НО У СЕБЯ В КЕШЕ, все остальные потоки об этом не узнают, volatile запрещает потокам это делать, но на практике это не решает проблему состояния гонки, зато существенно замедляет работу с этой переменной, я даж сходу не могу придумать реальный пример, где volatile реально помогло.

Кеш это супер важная хуйня - если сравнивать скорость работы кеша 1-2 лвл, кеша 3лвл и оперативы, то кеш 1-2 уровня будет феррари, кеш 3 уровня запорожец, а оператива - велосипедист.

ну volatile поможет в том случае если запись в такую переменную реально происходит перед последующим его чтением в других потоках. без volatile нет никаких гарантий, с volatile есть семантика happens-before на read/write переменной

вы правы в том что проблему состояния гонки волатайл не решает. про волатайл я вообще не объяснял - я предложил впилить в код и протестировать

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

 

 

(разве что создание объектов в методе отрисовки будет пожирать тебе память, заставлять активно работать gc и всё будет плохо)

бред

 

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

 

обоснуй

у меня есть 2 контраргумента -

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

- современные оптимизации в jvm могут отработать так что форич скаляризуется до интов на стеке

есть какая-то статья или что-то еще в подтверждение твоих слов?

В JVM несколько видов GC это раз.
Стековые объекты (созданные в функциях и отработавшие без сохранения ссылок на них) умирают сразу же.
Свежие объекты не которые не сохранилось ссылок умирают тоже быстро.

создание итератора на каждый форич

Создание итератора не затратнее автобоксинга. И то и то создание объекта.

Итератор уже за пределами foreach цикла может быть утилизирован GC

Плюс итератор занимает хуйню места сам по себе.
 
А вот такая хуйня

private static long sum() {
Long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++)
  sum += i;
return sum;
}

Создаст хуилиард иммутабельных Лонгов и несколько раз вызовет stop the world

Изменено 3 февраля 2019 пользователем Index

что такое "стековые объекты"? объекты, созданные внутри метода не умирают сразу же, умирают только ссылки на них (т.к на стеке хранятся только примитивы и ссылки на объекты, сами объекты в любом случае всегда хранятся в хипе). соответственно созданный внутри метода объект умрет тогда, когда gc решит его подчистить (естественно при отсутствии каких либо ссылок на объект), а удаление фрейма со стека (завершение метода) почистит только ссылку на объект (но не сам объект), которая создалась в ходе работы метода

Изменено 3 февраля 2019 пользователем AskMe-