Телеграмм чат группы pofftop страница 11602

85 мест на весь го

19:59пожаловаться #1

AK

Anton Korotkikh in Programming Offtop

возможно)))
интересно правда, почему тогда
и в Go, и в ОС Windows, часть кода всегда оптимизировали с помощью asm, ибо компиляторы не справлялись)))
но возможно мы уже в будущем))) и Java стала быстрее чем прямые операции с памятью)))

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

19:59пожаловаться #2

A

85 мест на весь го

то есть, есть моменты, где надо, правда?)

19:59пожаловаться #3

AN

то есть, есть моменты, где надо, правда?)

Кто спорил-то? Тем более все места, которые я вижу, это именно тот самый доступ к железячным регистрам.

20:00пожаловаться #4

A

Anton Korotkikh

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

я честно не представляю, куда может исчезнуть overhead JVM в процессе работы)
но может что-то поменялось в современности)))

20:00пожаловаться #5

AN

Вы умеете писать на нструкциях процессора?

20:00пожаловаться #6

AN

я честно не представляю, куда может исчезнуть overhead JVM в процессе работы)
но может что-то поменялось в современности)))

Вы этот оверхед меряли?

20:00пожаловаться #7

A

Кто спорил-то? Тем более все места, которые я вижу, это именно тот самый доступ к железячным регистрам.

там ещё есть копирование буфера)

20:00пожаловаться #8

A

самый такой момент)
возвращаясь к строкам и числам)

20:01пожаловаться #9

A

Вы этот оверхед меряли?

я нет) другие меряли) писали когда то, на boundaries check уходит до 10% времени)))

20:01пожаловаться #10

AK

Anton Korotkikh in Programming Offtop

я честно не представляю, куда может исчезнуть overhead JVM в процессе работы)
но может что-то поменялось в современности)))

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

20:01пожаловаться #11

A

то есть, в реальной жизни, так чтобы и безопасно и быстро - редко получаеться)))

20:01пожаловаться #12

AN

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

20:02пожаловаться #13

A

Anton Korotkikh

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

это то пусть, кушает, но...
момент 1, если что-то потребляет больше оперативной памяти, очевидно оно на это потребление ресурсы тратит)))

20:02пожаловаться #14

AK

Anton Korotkikh in Programming Offtop

это то пусть, кушает, но...
момент 1, если что-то потребляет больше оперативной памяти, очевидно оно на это потребление ресурсы тратит)))

нуу... зато она хитрая, хорошо тратит и хорошо оптимзирует

20:02пожаловаться #15

AN

я нет) другие меряли) писали когда то, на boundaries check уходит до 10% времени)))

Какого времени? С чем сравнивать? Вы реально умеете оптимизировать алгоритм так, чтобы 10% играли роль? Вы под размер кэшей затачиваете код?

20:03пожаловаться #16

AN

Я извините, просто задолбался с этими заявлениями про то, что С++ быстрый потому что он С++.

20:03пожаловаться #17

AN

От людей, которые профайлер в руках не держали

20:04пожаловаться #18

A

Какого времени? С чем сравнивать? Вы реально умеете оптимизировать алгоритм так, чтобы 10% играли роль? Вы под размер кэшей затачиваете код?

так) отмечу интересный момент
если я знаю чётко что будет в моей задаче, в отличии от компилятора)
то могу пожертвовать "safety" в угоду performance)
не всегда язык высокого уровня это понимает)
ибо он не для того создан)))

20:04пожаловаться #19

A

Я извините, просто задолбался с этими заявлениями про то, что С++ быстрый потому что он С++.

он быстрый в некоторых задачах)))
в правильных руках, он может быть медленнее Java)))