1. PHP / Говнокод #26465

    +1

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    <?php
    
      class Pet {
      
        protected $name;
    
        public function __construct($name) {
          echo "Setting name to " . $name . "\n";
          $this->name = $name;
        } 
    
        public function eat() {
          echo $this->name . " is eating.\n";
        }
      }
    
      $var = 30;
      $a_pet = new Pet("Spike"); 
      $a_pet->eat();
    ?>
    
    ---
    
    <?php
    
    function Pet__construct(&$objInst, $name)
    {
        echo 'Setting name to ' . $name . '
    ';
        $objInst['name'] = $name;
    }
    function Pet_eat(&$objInst)
    {
        echo $objInst['name'] . ' is eating.
    ';
    }
    $Pet = array('__vars' => array('name' => null));
    $var = 30;
    $a_pet = array_merge($Pet['__vars'], array('__type' => 'Pet'));
    Pet__construct($a_pet, 'Spike');
    Pet_eat($a_pet);

    Конвертер из ООП в процедурный стиль.
    Make PHP great again.

    https://github.com/PatrickZurekUIC/PHP-OOP-Converter

    Запостил: Fike, 05 Марта 2020

    Комментарии (166) RSS

    • Spike may refer to any of the following fictional characters: <очень много>

      А интересно, этому есть реальный пример применения (для совместимости, например), или это потому что могу?
      Ответить
      • Разве только для обфускации, чтоб у любителей солида пердаки поразрывало.
        Ответить
      • Это для царей, которые считают, что ООП тормозит.

        А если серьёзно, то тут какая-то переголова: мы создаём ненужный экземпляр $Pet в качестве рыбы, и при создании нужных экземпляров копируем его (точнее, мержим с новыми данными). В случае, если нам нужен синглтон, у нас будет два экземпляра вместо одного. Пахнет прототипным программированием из жопоскрипта.
        Ответить
        • ООП не томрозит, если методы не виртуальны, и диспатчатся статически (чего никогда не бывает примерно нигде, кроме разве что программ на плюсах и на шарпе)
          Ответить
          • Ну ещё в «Object Pascal» («Delphi» и «FPC», например) бывают невиртуальные методы и статический диспатчинг.

            А в «PHP» даже обычные функции ищутся в глобальной таблице функций по имени. Так что в «PHP» можно не думать о способах вызова подпрограмм, потому что всегда будет хуёво.

            >> и на шарпе

            Интересно. Следует ли из этого, что кишки ООП в «C#» и в «Java» устроены по-разному? Какие принципиальные различия ООП в этих языках?
            Ответить
            • Да, точно, в паскале же. Ключевое слово "virtual" я оттуда и узнал.

              >Интересно.
              В C# метод по-умолчанию не виртуальный, виртуальность надо заказывать явно
              https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/virtual
              Это позволяет мне думать, что невиртуальный метод может быть известен уже на момент компиляции.

              В Java же все методы виртуальны (хотя наверное final не виртуальны, если не забывать их писать)
              Ответить
            • Проверил.
              Javaбялди соснули

              public final  class Foo {
              
                  final void doAll() {
              
                  }
              
                  public static void main(String[] args) {
                      new Foo().doAll();
                  }
              }

              javap -c Foo.class
              
              Compiled from "Foo.java"
              public class Foo {
                public Foo();
                  Code:
                     0: aload_0
                     1: invokespecial #1                  // Method java/lang/Object."<init>":()V
                     4: return
              
                final void doAll();
                  Code:
                     0: return
              
                public static void main(java.lang.String[]);
                  Code:
                     0: new           #2                  // class Foo
                     3: dup
                     4: invokespecial #3                  // Method "<init>":()V
                     7: invokevirtual #4                  // Method doAll:()V
                    10: return
              }


              invokevirtual не смотря на final. Може, джит чото и может, но не JavaC
              Ответить
              • так а там кроме invokevirtual подставлять-то нечего. invokespecial не для обычных методов.
                Ответить
                • Но почему не завести спец вызов как у CLR?
                  Ответить
                  • ты еще спроси почему у них машина 32 бита и type erasure
                    Ответить
                    • Машина 64 бита есть, в ней просто указатели короткие могут быть емнип
                      Ответить
                      • he JVM is fundamentally a 32-bit machine. long and double types, which are 64-bits, are supported natively, but consume two units of storage in a frame's local variables or operand stack, since each unit is 32 bits.
                        Ответить
                        • аа)) ты имеешь ввиду саму JVM с ее стеком, я думал ты про реализацию.

                          Очень смешно конечно, что там везде int, и размер его фиксирован в спеке, и никогда не поменяется.

                          Через 20 лет компы будут 256-ти битные, а инт у JVM все еще будет 4, лол
                          Ответить
                • А кстати да, в жабе только это есть:
                  invokedynamic
                  invokeinterface
                  invokespecial
                  invokestatic
                  invokevirtual

                  https://docs.oracle.com/javase/specs/jvms/se13/html/index.html
                  Но жабоёбы соснули, да.

                  UPD: ораклы охуели, новая спека «Access Denied» выкидывает. Пидорасы.
                  https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.10.1.9.invokedynamic
                  Ответить
                  • причем invokedynamic завезли только в семрку, кажется.
                    Груверы очень радовались: у них все стало чутьменьше томрозить
                    Ответить
                    • Кстати да, в шестёрке его не было: https://docs.oracle.com/javase/specs/jvms/se6/html/Overview.doc.html#31293.
                      Ответить
                • а не, напиздел

                  > The difference between the invokespecial and the invokevirtual instructions is that
                  > invokevirtual invokes method based on the class of the object. The invokespecial
                  > instruction is used to invoke instance initialization methods as well as private
                  > methods and methods of a superclass of the current class.

                  другими словами, invokespecial как раз-таки вызывает методы без динамического биндинга. Какая компиляция )))
                  Ответить
                  • тогда почему для final её не заюзать?
                    Ответить
                    • ты еще спроси, почему поддержки примитивов в дженериках нет
                      Ответить
                  • Смотрите, что нашёл:
                    https://github.com/mtumilowicz/java-bytecode-invokespecial
                    Ответить
                  • >Static, private, final, and/or "special" invocations are easy to inline.
                    >Virtual (and interface) invocations are often demoted to "special" invocations, if the class hierarchy permits it.
                    Ответить
                    • кем они туда demoted ? джитом?
                      Как видно из моего примера -- джавак так не делает: вызов финального метода у финального(!!!) класса он invokevirtual.

                      invokespecial там только конструктор

                      зы: ладно, всё, я почитаю и вернус
                      Ответить
              • короче:

                В хорошем коде 99.9% методов -- финальные. За наследование реализации и переписку ейных методов надо пиздить сковородкой. Это очень плохой паттерн.
                И JVM каждый раз луркает в таблицу (у правда она может луркнуть в момент загрузки класса конечно, всё таки налету там ничего не меняется, это не JavaScript).
                Но всё равно пахнет говном.

                Хотя вообще тот факт, что методы по умолчанийу виртуальны пахнет гавном еще больше
                Ответить
                • [citation needed]
                  Ответить
                  • Что именно показалось тебе неверным?
                    Ответить
                    • Не понимаю этой категоричности из-за non final методов и наследования реализации.

                      Есть реальные примеры мейнстримовых языков, в которых можно легко и просто шарить реализацию без наследования? Сразу скажу, что всякие там default implementation как в Свифте не предлагать: максимум, что ты на них построишь, это синтетику или совсем уж примитивные вещи.
                      Ответить
                      • Да, например Kotlin с его делегейшеном
                        https://kotlinlang.org/docs/reference/delegation.html

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

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

                        Ты понимаешь в чем проблема класса, у которого наследник переопределил какие-то методы, или раскрыть тему?
                        Ответить
                        • Почему у класса, наследник которого переопределил какие-то методы, должны быть какие-то проблемы? Мы же сейчас не говорим про случаи на всю голову отбитых разработчиков, верно?

                          А вот примеры на Котлине я нихуя не понял. Судя по вики, Котлин это чуть ли не единственный йезык, где это чудо поставляется с батарейками, но о чём это, я всё равно не допетрил.
                          Ответить
                          • Проблемы будут у программиста, и да: у родителя и наследника может быть один и тот же автор.

                            Попробую объяснить котлиновое делегирование
                            interface Bird { /*это как pure virtual в C++ или protocol там у вас*/
                                fun talk()
                                fun fly()
                            }
                            
                            class Chicken : Bird { /*обычная реализация*/
                                override fun talk() {
                                    print("koko")
                                }
                            
                                override fun fly() {
                                    print("I can't fly")
                                }
                            }
                            
                            // Этот класс передает все вызовы своему филду "bird", кроме fly
                            class FlyingRooster(private val chicken: Bird = Chicken()) : Bird by chicken {
                                override fun fly() {
                                    print("I am flying")
                                }
                            }
                            Ответить
                            • > передает все вызовы
                              Все, или только те, что определены в Bird?
                              Ответить
                              • Разумеется только те, что в Bird.

                                Bird by chicken
                                Ответить
                            • Ну это синтетика, а в реальной жизни это как используется?
                              Ответить
                              • Я дофига пользуюсь. Вот сегодня у меня был контроллер, который должен был почти все вызовы передать вьюшке as-is, а часть интерсептнуть. Они оба реализовывали спец интерфейс. Уверен, что пользуюсь не только я.
                                Ответить
                                • В общем, весь цимес в том, что компилятор сам вставляет

                                  fun petuh() {
                                     delegate.petuh()
                                  }


                                  ?

                                  Ну так, мило. Но super уже не позовёшь, например.
                                  Ответить
                                  • Ты прав, цимес именно в этом.
                                    Но сам цимес ты оценишь, когда ты добавишь в интерфейс два метода, а третий удалишь. И все 18 его реализаций в коде тебе не нужно будет править.

                                    super сам зовется, если ты занаследовался:)

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

                                      По сути даже в твоём примере выше получается, что и вьюха, и контроллер конформят один и тот же интерфейс, толлько чтобы работал этот delegation, если я правильно понял. Похоже на абьюз.
                                      Ответить
                                      • У них много интерфейсов, часть из них действительно пересекается.

                                        Запросы от клиента поступают в контроллер. Клиент знает, что он хочет вывести какой-то текст, или что хочет сохранить данные.

                                        Методы для вывода текста есть в интерфейсе, допустим, TextView. А для сохранения в Saver.

                                        Котроллер реализует оба интерфейса.
                                        Клиент получает иинстанс контроллера, и работает с ним.

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

                                        Без делегейта мне пришлось бы или писать бойлерлпейт, или реализовывать паттерн Команда -- такой класс, который инкапсулирует все требования клиента, и передавать его инстанс во вью (ну по сути как forwardInvocation, но вручную)
                                        Ответить
                            • Но в чём отличия? Реализация всё равно наследуется. Если кто-то поправит курицу, питушка надо будет оттестировать, иначе он может оказаться сломанным.
                              Ответить
                        • Я не понимаю. Я тупая обезьяна.
                          Ответить
                        • Типа компилятор автоматически генерирует форвардинг вызовов "делегирующему" объекту?

                          Что там под капотом-то происходит? И что делать, если я хочу, чтобы Derived не Base конформил, а какой-то интерфейс, частично совпадающий с Base по сигнатурам?
                          Ответить
                          • >Типа компилятор автоматически генерирует форвардинг вызовов "делегирующему" объекту?

                            именно.

                            >Что там под капотом-то происходит?
                            реализуются все методы типа
                            fun petuh() {
                               delegat.petuh()
                            }


                            > интерфейс, частично совпадающий с Base по сигнатурам?
                            А он как-то связан с Base, или просто методы так же называются?
                            Ответить
                            • Никак не связан. Я хочу делегировать произвольному объекту и и не завязываться на интерфейсы. Что-то типа [NSObject forwardInvocation:] (который сам по себе та ещё шняга)
                              Ответить
                              • Нет, так можно толко в скриптовых языках и у вас в яблоке, в котлине так нельзя.

                                Можно использовать рефлексию, но это очень некрасиво, медленно, и не нужно
                                Ответить
                • > всё таки налету там ничего не меняется
                  На самом деле там динамического питуха гораздо больше, чем в скрипте. Жабьей рефлексией можно менять всё что угодно, включая байткод любых методов и вообще классов (включая те, что в стдлибе), хакать жабокод очень приятно. Правда, это всё очень по-жабьему многословно, но зато нет такого, что из замыкания никакими способами нельзя вытащить захваченные переменные (дядя ПИ недавно замечательный пример приводит). И именно поэтому я за «Java» (в контексте динамичности).
                  Ответить
            • А вот шарпа.


              Сначала тупое
              public class MyClass
                  {
                      public void  Foo()
                      {
              
                      }
                      public static void Main(string[] args)
                      {
                          new MyClass().Foo();
                      }
                  }


              код
              .method public hidebysig static void
                  Main(
                    string[] args
                  ) cil managed
                {
                  .entrypoint
                  .maxstack 8
              
                  IL_0000: nop
                  IL_0001: newobj       instance void dotnent_test.MyClass::.ctor()
                  IL_0006: call         instance void dotnent_test.MyClass::Foo()
                  IL_000b: nop
                  IL_000c: ret
              
                } // end of method MyClass::Main


              Теперь добавляем виртуал
              public virtual void  Foo()
                      {
              
                      }


              и ты не поверишблядь!
              .method public hidebysig static void
                  Main(
                    string[] args
                  ) cil managed
                {
                  .entrypoint
                  .maxstack 8
              
                  // [15 9 - 15 10]
                  IL_0000: nop
              
                  // [16 13 - 16 33]
                  IL_0001: newobj       instance void dotnent_test.MyClass::.ctor()
                  IL_0006: callvirt     instance void dotnent_test.MyClass::Foo()
                  IL_000b: nop
              
                  // [17 9 - 17 10]
                  IL_000c: ret
              
                } // end of method MyClass::Main


              Внимане на строку IL_0006

              Было call, стало callvirt.

              Так что жавабляди соснули у шарпеев. Ну, им не в первой.
              Ответить
              • Ребята, вы если не разбираетесь в теме, то лучше молчите.
                Hotspot с лёгкостью уже лет 10 как инлайнит виртуальные методы.

                1. https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
                2. https://shipilev.net/blog/2015/black-magic-method-dispatch/
                3. https://shipilev.net/jvm/anatomy-quarks/16-megamorphic-virtual-calls/
                4. https://www.nurkiewicz.com/2013/01/how-aggressive-is-method-inlining-in-jvm.html

                Ещё была классная статья с бенчами инлайна джвух наследников. Не могу сходу найти.
                Ответить
                • Иными словами, эта задача переехала в JIT, верно?
                  То-есть это JIT должен доказать, что метод всегда один и тот же, и тогда его можно инлайнуть.

                  При этом это знание можно получить на уровне компиляции, и избавить JIT от ненужной работы. Почему этого не было сделано? Чтобы не вводить еще один байткод?
                  Ответить
                  • >То-есть это JIT должен доказать, что метод всегда один и тот же, и тогда его можно инлайнуть.

                    Нет.
                    Он обходится без виртуальных функций даже когда два потомка и соответственно два метода. Чего C# не умеет в принципе.

                    См. ссылку №1
                    >Methods are often inlined. This increases the compiler's "horizon" of optimization.
                    >Static, private, final, and/or "special" invocations are easy to inline.
                    >Virtual (and interface) invocations are often demoted to "special" invocations, if the class hierarchy permits it. A dependency is registered in case further class loading spoils things.
                    >Virtual (and interface) invocations with a lopsided type profile are compiled with an optimistic check in favor of the historically common type (or two types).


                    > эта задача переехала в JIT, верно?
                    jit ничего не доказывает. Он собирает статистику. И если метод вызывается всегда только на одном классе — его инлайнят.
                    То есть инлайн будет происходить, в случае когда есть несколько наследников, но вызывается только один или два.
                    Ответить
                    • >Чего C# не умеет.
                      Язык и не может этого уметь. Ты говоришь же об оптимизации JIT.
                      Умеет ли это JIT CLR я не знаю.

                      >Static, private, final, and/or "special" invocations are easy to inline.
                      Ну слава богу! Значит, хотябы JIT это понимает.

                      Кстати, а что будет, если потом вызовется всё таки другой метод?
                      И как заинлайнить метод на 900 строк в 900 мест?

                      То, что JIT это умеет, это великолепно конечно.
                      Но у нас в коде есть довольно четкое понимание, что метод не виртуальный, и диспатчить его через виртуальную таблицу не нужно.

                      Компиляторы C++ и C# умеют этим знанием пользоваться, а компилятор Java -- нет.

                      Насколько сильно это бьет по перформансу я не знаю (видимо вон надо брать шипилевский профайлер, и проверять.

                      Зы: кажется, я понял, что это может попорить ABI
                      https://govnokod.xyz/_26465/#comment-513821
                      Ответить
                      • >Кстати, а что будет, если потом вызовется всё таки другой метод?

                        Признайся. Ты не читал ни одну из данных мною ссылок.
                        Будет деоптимизация.

                        >И как заинлайнить метод на 900 строк в 900 мест?
                        Компилятору виднее. Если он решит что этого не стоит делать, то инлайна может и не случиться.

                        А ещё эти сволочи забрали у погромиста ключевое слово inline. Гады, ненавижу.сраказм
                        Ответить
                        • Признаюсь. Не читал. Ладно, пойду-почитаю, ты прав

                          >inline
                          и register, в общем я тебя понял.

                          Кстати, в котлине есть inline, он позволяет делать reified
                          https://kotlinlang.org/docs/reference/inline-functions.html#reified-type-parameters
                          Ответить
                      • >Компиляторы C++ и C# умеют этим знанием пользоваться, а компилятор Java -- нет.

                        В мире джавашков, это принято считать не багом, но фичей.
                        Типа мы оптимизируем на месте, под конкретные машины и конкретные наборы классов.
                        Ну в целом «оптимизировать» байт-код виртуальной машины с jit, это как у реальной машины пытаться на ходу руками крутить колёса, чтобы та ехала побыстрее.
                        Из №4

                        Important remark is that it's the JVM, not the compiler. javac is quite conservative when producing bytecode and leaves all that work onto the JVM. This design decision turned out to be brilliant:

                        * JVM knows more about target environment, CPU, memory, architecture and can optimize more aggressively

                        * JVM can discover runtime characteristics of your code, e.g. which methods are executed most often, which virtual methods have only one implementation, etc.

                        * .class compiled using old Java will run faster on newer JVM. It's much more likely that you'll update Java rather then recompile your source code.
                        Ответить
                        • > на ходу крутить колёса

                          Проехав сотню-другую другую километров на квадратных колёсах, JIT решил, что пора бы их оптимизировать и поменять на круглые.
                          Ответить
                          • Можно прям на какой-то сайт цитат, афоризмов, изречений.

                            С тегом: #так_говорил_Борманд

                            Вкупе с этим:
                            https://govnokod.ru/26356#comment521479

                            «Оптимизировать байткод - это как опрыскивать говно духами.» ⓒ
                            Ответить
                          • но при этом добавил пятое квадратное, чтобы если оно вдруг завращалось, можно было бы деоптимизировать
                            Ответить
                        • 1024--, перелогиньтесь:)))

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

                          Но когда у тебя есть проект размером с Intellij Idea в котором каждую секунду вызываются десятки тысяч методов, может быть даже маленькая оптимизация бы помогла. Черт его знает когда там JIT раздуплится, и что-то починит.

                          И да: сурс мы пересобираем чаще, чем выходят новые джавы.

                          Но аргумент про "JIT работает лучше, потому что знает конкретную архитектуру" я слышал от .NET, и может быть и правда смысл есть.
                          Типа JIT узнает, что у конкретного процессора есть какая-то суперкрутая иинструкция, и заюзает ее. Может быть такое?
                          Ответить
                          • > аргумент про "JIT работает лучше, потому что знает конкретную архитектуру" я слышал от .NET, и может быть и правда

                            Ага.
                            Я тоже его слышал в далёком 2003.
                            Поставил я себе тогда этот «.NET».
                            Мама дорогая, как же оно тупило.

                            Но маркетинг был прекрасен:
                            «Много языков», «одна платформа», «оптимизация под ваш процессор».

                            Я тогда померял и VB.NET сливал по пирфомансу даже старому VB6.
                            Причём вроде даже в P-code. А то что шарпик сливал VC++, думаю и так очевидно.

                            Впрочем с тех пор и жаба сильно ускорилась и .NET тоже.
                            Ответить
                            • Ну в .net хотя бы ngen завезли...

                              И эта идея про оптимизацию во время установки софта мне очень нравится - не надо 100500 бинарей под разные рахитектуры, но при этом можно заточить код под конкретный проц и даже под конкретные либы которые сейчас стоят в системе.
                              Ответить
                              • >оптимизацию во время установки софта
                                Знаю одну такую оптимизацию. Популярна во {фри,нет}бзди, линукс генте и пр (думаю что и в арче)

                                Прописываешь в make.conf CFLAGS и CPUTYPE, и ставишь софт:))
                                Ответить
                                • Ну это уже слишком опенсурсно.
                                  Ответить
                                  • На самом деле это всё примитивное фуфло.

                                    Реальная оптимизация «под конкретную архитектуру» и задачу, это профилирование ( -fprofile )

                                    Однако довольно мало либ поддерживают профилирование прямо из make.

                                    libx264 один из примеров.
                                    Ответить
                                • Да.
                                  -mcpu=native -march=native наше всё.

                                  Я так делаю, НО ИСКЛЮЧИТЕЛЬНО для тех либ и программ, которыми пользуюсь и где мне наверняка нужен пирфоманс.
                                  Ответить
                                  • Году в 2001-м я видел срач между собирателями всего из сырцов и сторонниками пакетов (кажется, дебиановцы).

                                    Вот там приводились такие числа, что для большинства программ, собранных для i386, прирост перформанса был не выше двух процентов. Так что в целом игра не стоила свеч, кроме высоконагруженного софта конечно
                                    Ответить
                                    • > что для большинства программ, собранных для i386
                                      Тогда не было столько инструкций.
                                      SSE, MMX. Ну и немного 3DNow.

                                      >2001
                                      SSE2 либо не вышел, либо только-только и все сидели на P3 и Атлонах. И это был на тот момент наиболее массивный набор новых комманд. 140+ инструкций, емнип.

                                      Сейчас же SSE2 — baseline для x64. Под него можно собирать все 64-битные пакеты.

                                      А после него идут: SSE3, SSSE3, SSE4.1, SSE4.2 (строки) AVX, AVX2, BMI, FMA, AVX512 (с кучей профилей)
                                      Простор для оптимизаций гораздо шире.
                                      Ответить
                                    • > собирателями всего из сырцов
                                      Бля, сумасшедшие какие-то…
                                      Ответить
                                      • вовсе нет

                                        во-первых собирать из сырцов можно с помощью системы портов/пеекджей/портеджей, и тогда не надо ебаться

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

                                        и наконец есть прекрасный слакварь со слакбилдом, где ебаться как бы и не надо, а все же надо

                                        ну и наконец когда у тебя на сервере 486 с 8-ю метрами памяти (это нормально для 2001-го года), то тебе может хотеться не грузить в память лишний код
                                        Ответить
                                        • А потом ебаться пару дней, потому что окружение не то, инклуды не там лежат, с кодировками проблемы, для сборки нужна куча левых утилит (ёбанный буст с его зависимостью от «Питона»), а в особо запущенных случаях это всё говно ещё и заточено исключительно под хуйцэцэ 1.2.345, а у тебя 1.2.346 и нихуя не работает.
                                          Спасибо, не надо, я лучше бинарь поставлю.
                                          Ответить
                                          • Да, естественно ебаться. Никто и не говорил, что собирать что-то из сырцов это легко и приятно.

                                            Именно по-этому я за указанные выше порты и их вариации: собирается всё само, зависимости сами приезжают, тебе нужно только сказать make.
                                            Правда, сборка, например, иксов с KDE -- дело не быстрое, можно устать ждать.
                                            Ответить
                                        • > на сервере 486 с 8-ю метрами памяти (это нормально для 2001-го года
                                          Проснись, ты обосрался даже проецируя свой цєлерон под Шиндошс XP образца 2020 года.
                                          Даже прыщепердолики в 2001 давно повыкидывали на помойку такие высококопроизводительные платформы класса Писюк
                                          Ответить
                                    • Ввод-вывод сливает в хламину этот ваш прирост пирфоманса. Чтобы заметить прирост, программа должна редко обращаться к вводу-выводу, а основное время что-нибудь вычислять.
                                      Ответить
                                      • Это правда. От сборки супероптимизированной под твой CPU версии vim, mutt или postfix бусты перформанса будет мало.

                                        А вот ffmpeg кажется что в теории может стать лучше
                                        Ответить
                                        • >А вот ffmpeg кажется что в теории может стать лучше

                                          Да. И то. Ну 3-5% максимум что я выжимал.

                                          Там же ручного ассемблера очень много.

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

                                          Причём --cpu=native --extra-cflags="-march=native" --extra-cxxflags="-march=native" даже немного просаживало пирфоманс при использовании clang.
                                          Почему так, я не знаю до сих пор.

                                          В ffmpeg code-base огромный, на старых процессорах он довольно долго собирается.
                                          Как это всё профилировать, хз.
                                          Ответить
                                          • А есть задача, которую лучше решает gcc, чем шланг?
                                            НУ, кроме сборки специфичного для него кода
                                            Ответить
                                            • Есть. На phoronix.com регулярно публикуются бенчи.

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

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

                                              А программы, которым не нужна скорость, и пересобирать бессмысленно.
                                              Ответить
                                              • тогда я вообще не понимаю, зачем что-то собирать под конкретную арихтектуру: ffmpeg все равно асмблерует, а сандербёрду как-то пофиг
                                                Ответить
                                                • Ну там же не везде ассемблерные вставки.
                                                  А только на самые проблемные места, и самые частоиспользуемые кодеки.
                                                  Страшно заточенный декодинг H.264 сильно не ускорит.

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

                                                  >зачем что-то собирать под конкретную арихтектуру
                                                  Профит есть. Всё-равно там сишка есть.

                                                  > зачем что-то собирать под конкретную арихтектуру
                                                  Я руками собирал ffmpeg, когда его из убунты выпилили.
                                                  Плюс самая свежая версия, плюс своя сборка быстрее.
                                                  Ответить
                                                  • >убунты
                                                    хм
                                                    ffmpeg version 3.4.6-0ubuntu0.18.04.1 Copyright (c) 2000-2019 the FFmpeg developers
                                                      built with gcc 7 (Ubuntu 7.3.0-16ubuntu3)

                                                    я для слаки тоже собирал (правда из слакбилдов всё таки), а то там даже H264 не работал
                                                    Ответить
                                                    • >убунты
                                                      В 14 LTS эти анскильные отбросы завезли avconv/libav.

                                                      Я уже травил стори про это:
                                                      https://govnokod.ru/26372#comment522890
                                                      https://govnokod.ru/15663#comment225480


                                                      >ffmpeg version 3.4.6-0ubuntu0.18.04.1
                                                      Тоже не годится. Гавно старое.
                                                      Везде 4.2 давно.

                                                      Нидернмайер раньше на все жалобы так и отвечал: use CVS, use git.
                                                      Ответить
                                                      • ну видимо вернули обратно уже.
                                                        говно правда, ждем 20.04:)]

                                                        зы у мну 18
                                                        Ответить
                                                        • >ubuntu0.18.04.1
                                                          Я вижу.

                                                          >ну видимо вернули обратно уже
                                                          Это происходило с большим скрипом, срачем и жуткими проблемами.
                                                          Жаль потерял ссылку (или её удалили) на страницу где был целый ПЛАН по переводу убунты обратно.

                                                          Ответить
                              • >оптимизацию во время установки софта
                                GENTOO
                                Ответить
                              • Просто было обидно, как меня подло наебали маркетологи.

                                Я ведь ждал царского пирфоманса, SSE2 всяких, а получил Microsoft™ Java, которая сливала даже Бейсику!
                                Ответить
                                • А ещё оно ну о-о-о-очень долго ставилось. Шло емнип на 3х CD.

                                  Я ради интереса наформошлёпал обычное оконное приложение. Запустил, и оно сожрало 50Мб памяти!

                                  ПЯТЬДЕСЯТ МЕТРОВ. Для понимания у меня тогда было 512Мб, и это было МНОГО, т.к. большинство тогда сидело на 256.

                                  Хорошо что я .NET ломаный взял. А кто-то ведь мог и купить это говно.
                                  Ответить
                                  • Справедливости ради, JVM в ту пору тоже не супер быстро работала в каком-нить pentium 3 tualatin:)

                                    Я дотнет первый раз потрогал году в 2007-м, это был .NET 2.0 и C# тоже 2.0 (и решарпер, лол), студия была 2005.

                                    WinForms довольно неплохо работали, и ASP.NET тоже, но конечно памяти у меня был где-то гиг, и проц какой-то на 775-м.

                                    Но студия запускалась вечность.
                                    Теперь у меня Студия 2017 и Coffe lake i7, а студия все равно запускается вечность
                                    Ответить
                                    • >Но студия запускалась вечность.

                                      Ага. Я субъективно помню что всё дико тупило. Ставилось ну очееень долго.

                                      >Теперь у меня Студия 2017 и Coffe lake i7, а студия все равно запускается вечность

                                      Между прочим IDE от МS раньше считались очень шустрыми.
                                      VB и VC на слабых машинах грузились пулей по сравнению с Дельфями и Быдлером.
                                      Но потом в Майкрософт переманили главного борландовца и понеслась.

                                      >JVM в ту пору тоже не супер быстро работала в каком-нить pentium 3 tualatin:)

                                      Java тогда считалась самым медленным языком вообще. Но кроссплатформенным.
                                      Ответить
                                      • Visual Studio 6 очень быстро грузилась, кстати
                                        Ответить
                                    • Я ещё тогда мечтал о MSDN на куче дисков. Ибо интернет был очень лимитирован, да и инфы было не так много.

                                      Вот как выглядела визуал-студия мечты
                                      http://img.xz7.com/up/2016-12/2016122883447.jpg
                                      Ответить
                                      • да-да, msdn на дисках, ф формате chm!! шустрый, и с кучей полезной инфы про кишки винды:)))
                                        Ответить
                                        • У меня был такой. Как раз по нему первые проги под винапи и писал...

                                          З.Ы. Обидно, что MSDN сейчас скатили в какую-то хуйню с битыми ссылками и корявым переводом.
                                          Ответить
                                          • а у кого был вижуал ассист с помидором?

                                            А кто помнит Source safe? А spy++?
                                            Ответить
                                            • >кто помнит Source safe? А spy++?

                                              Да, помню. Но source safe дрянь, не греющая душу.
                                              А аналог spy++ я и сам писал на winapi, причём куда информативнее.
                                              Ответить
                                              • >Но source safe дрянь, не греющая душу.

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

                                                может был и другой режим, но я помню именно такой
                                                Ответить
                                                • Я слышал там какие-то странные проблемы возникали, можно было похерить файл.

                                                  Благо у нас CVS был. Я на православном CVSNT года до 2007 просидел.
                                                  Ответить
                                          • Я помню, как в студии .net переделали MSDN с chm на что-то такое, что стало грузиться пол часа (не дай тебе бог СЛУЧАЙНО нажать F1!) и грузить половину инфы из инета в перемешку с 404
                                            Ответить
                                            • >Я помню, как в студии .net переделали MSDN с chm на что-то такое, что стало грузиться пол часа

                                              Вот именно такое чувство от этого говёного .NETа было.

                                              Тупило вообще всё: инсталл, хелп, IDE и написнаные на нём программы.

                                              После VS 6.0 (немного проапдейченой Visual Studio 1997) это казалось просто каким-то тошнотворным тормозным ужасом.

                                              .NET это первая фрустрация от MS, а второй была Виста.

                                              Причём оба были долгостроями, и в итоге эталонный багор.
                                              Ответить
                                    • То ли дело Notepad++. Запускается быстро и не тормозит.
                                      Проверял свежие версии на Sandy Bridge питухе, на Coffee Lake питухе, и на Core 2 Duo питухе в марте 2020.
                                      Ответить
                                      • И кстати одинаково поддерживает все языки: от ассемблера, до tcl. От C++ до CoffeScript.
                                        Ответить
                                      • Справедливости ради, «Notepad++», при всей моей любви к нему, сильно тупит при загрузке больших файлов (у меня — где-то от нескольких сотен мегабайт). А уж если в крупном файле включается подсветка синтаксиса — всё, пиздец, дальше только «taskkill /im "notepad++.exe" /f» (там, видимо, O(N^2) где-то обнаружилось, ведь математику учат только в рашке).
                                        Ответить
                                        • > больших файлов

                                          Причём вот он нормально работает с файлами гига на 3-4, но периодически какие-то фризы по полминуты, как-будто gc работает.
                                          Ответить
                                          • Да вы там поехавшие с суперкомпьютерами. У меня на ~6МБ уже начинает тормозить.

                                            * Тормозит, если включен спеллчекер
                                            * Тормозит, когда меняется длина количества строк (проскроллил с 999 на 1000 строки)
                                            * Тормозит, когда длинные строки не разбиваются \n и включён автоперенос
                                            Ответить
                                            • попробуй Editplus
                                              Ответить
                                            • less is more

                                              >У меня на ~6МБ уже начинает тормозить.
                                              А гоcть за vim совсем не зря топил.
                                              Ответить
                                              • > за vim не зря топил

                                                Ну да, проверил, vim на 5 гиговом файле вполне сносно работает. По крайней мере поиск и чтение. А редактировать такие файлы я и не собирался.
                                                Ответить
                                                • https://govnokod.ru/26423#comment527011

                                                  1024-- 15.02.2020 03:23
                                                  >Они там поехавшие совсем были?
                                                  >Или компьютеры настолько тормозили, что перерисовывать экран после нажатия кнопки было долго?


                                                  Ахахахах. Так компьютеры и сейчас ТОРМОЗЯТ.

                                                  1024-- 18 минут назад #>>531542 +2
                                                  Да вы там поехавшие с суперкомпьютерами. У меня на ~6МБ уже начинает тормозить.

                                                  Пока анскильные отбросы ждут ответа от редактора «What You See Is What You Get».
                                                  Настоящие Цари с vim и ed на 486 обгоняют суперкомпьютеры.
                                                  Ответить
                                                  • > на 6МБ уже начинает тормозить

                                                    Обмажутся своими экмаскриптами и электронами, а потом жалуются, что редактор на 6МБ текста тормозит.
                                                    Ответить
                                                    • И тут мы приходим к тому, о чём я уже говорил...
                                                      Ответить
                                                    • Питушня. Нет там электронов. Эта питушня ведь выросла из Сцинтиллы и внутри себя имеет быстрый C++ питух.
                                                      Ответить
                                                      • > ведь выросла из Сцинтиллы и внутри себя имеет быстрый C++ питух
                                                        Скриптуха бы сдохла на первом мегабайте.

                                                        Я уже говорил, что «problem with these editors is that Real Programmers consider "What You See Is What You Get" to be just as bad a concept in Text Editors as it is in women»

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

                                                        Хотя, казалось бы - зачем?

                                                        Они просто показывают свои мечты, своё желание быть чем-то большим, нежели веб-макака.

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

                                                        Но проблема не в этом. Проблема в том, что каждый сектант с очередным недоредактором прибегает и рассказывает о том как же vim/less/ed/teco ненужны и как он всех победил.
                                                        Ответить
                                                        • А можешь привести пример визивиг эдитора для програмиста?
                                                          Ответить
                                                        • Высокосинтаксильно.
                                                          Ответить
                                                          • Они понимают, что WYSIWYG - говно. Они понимают, что они домохозяйки.

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

                                                            И пропаганда это так же использует.

                                                            Она как-бы даёт веб-макаке недоредактор на котором она может насрать хелворд и даёт возможность сообщить "дак я же как teco", "дак я же как vim".

                                                            Чего рядовой адепт сделать не может. Хотя они и пытались.

                                                            Все эти Notepad++ сектанты - это вчерашние адепты notepad.exe — ещё вчера они орали, что консоль — говно, а MS Word убьёт vim и вообще лучше vima.

                                                            Очевидно, что абсолютно неважно как человек действует тогда, когда он мнит себя хозяином и гладит холопа.

                                                            Всё проявляться тогда, когда нужно отвечать и обосновывать.

                                                            И вот он спокойно сидел пока были файлы на 6 килобайт и начал обмазываться говном и тебя им закидывать тогда, когда ты предложил открыть большой файл.

                                                            WYSIWYG-сектант просто мразь. Сектант попросту не осознаёт своей деятельности.

                                                            Он может свято верить в том, что валять в говне и кидаться говном - это и есть ответ и аргументация.

                                                            Важно показать, что это не так.
                                                            Ответить
                                                            • Я припал к источнику мудрости
                                                              https://tsar1997.blogspot.com/
                                                              Ответить
                                                              • > Я припал к источнику мудрости
                                                                Теперь аккуратно совершай возвратно-поступательные движения рукой.
                                                                Ответить
                                                                • царь изобрел isspace
                                                                  const uint8_t is_space[256] = {[' '] = 1, ['\n'] = 1, ['\t'] = 1, ['\v'] = 1, ['\r'] = 1, ['\f'] = 1};

                                                                  а чем можешь похвастаться ты?
                                                                  Ответить
                                                                  • >царь изобрел isspace
                                                                    Это не новость:
                                                                    https://govnokod.ru/26351#comment521224
                                                                    Ответить
                                                              • Я перечитываю https://govnokod.ru/26423#comment526827

                                                                И понимаю что Царь как всегда прав.

                                                                Гость топивший за vim тоже достойный боярин. А божественные редакторы опять плеснули мочи в рожи WYSIWYG-сектантов.
                                                                Ответить
                                                      • >и внутри себя имеет быстрый C++ питух

                                                        А teco, ed, ex, vim, less написаны на божественной Сишке!
                                                        В этом всё дело.
                                                        Ответить
                                                  • Питушня. Помню, видел WinHex. Открываешь диск на гигабайты, а ничего не тормозит. И графический питух, и визивиг.
                                                    Ответить
                                                    • Подтверждаю. «Hexplore», «HxD» не тормозят на любых файлах, рагулярно ими пользуюсь.
                                                      «Large Text File Viewer» тоже не тормозит на гигабайтах.
                                                      Ответить
                                                      • Virtual Dub Hex Editor. Самое быстрое что я видел из gui.

                                                        Специально написан для многогигабайтных файлов.
                                                        Ответить
                                                    • Ну у винхекса задача проще на порядок - ему не надо разбивать на строки.
                                                      Ответить
                                                      • а так же запускать автомат лексера
                                                        Ответить
                                                        • Вот лексер питушня уже правдоподобнее звучит. Разбить на строки - это однопроходный питух сложности O(1)..O(n) - от текущей точки на экран вверх, а лексер или даже парсер - это уже тормозящая питушня.
                                                          Ответить
                                                          • Парсер пиздец тормозит, особенно когда тебе надо восстаналиваться от ошибок (а в отличие от компилятора тебе это надо: ты не можешь из за одной опечатки весь файл покрасить в серый цвет, хотя например xcode когда-то так делал).

                                                            Собссно, парсер именно и тормозит кмк
                                                            Ответить
                                                            • Там не только парсер. Вон, я ж говорю, нажал «PageUp» — всё зависло нахуй. Видимо, какая-то поебота в работе со строками/страницами.
                                                              Плюс он очень хуёво обрабатывает крупные файлы с непечатными символами. NP++ их отображает как псевдосимволы (HEX-код в прямоугольнике), и когда их много — всё начинает адово тормозить. Подозреваю, что на каждую отрисовку такого символа он перерисовывает весь предыдущий текст, вот и получается квадрат.
                                                              Ответить
                                                • >vim на 5 гиговом файле вполне сносно работает. По крайней мере поиск и чтение

                                                  Я гигабайтные логи смотрю строго через less.

                                                  Пайпы, нумерация строк, поиск, синтаксис такой же как у vima. Полёт отличный.

                                                  Короче царские редакторы опять слили в хламину гыгыкавших анскильных мразей.
                                                  Ответить
                                                  • Для логов и питушни less, для программирования, где сотня килобайт на редкий файл наберётся - npp.
                                                    Ответить
                                            • Да, он нестабилен на крупных файлах. Только что открыл .csv (без подсветки, но с переносом строк) на 155 мегабайт: всё летает, загрузил где-то за секунду, прокрутка мгновенная. Нажал «PageUp» — «Notepad++» ушёл думать секунд на тридцать. Какой багор )))
                                              Ответить
                                              • Я за F4 в фаре
                                                Ответить
                                                • > F4

                                                  F3 же. Ну хотя с 64-битным фаром может быть и F4 прокатит...
                                                  Ответить
                                                  • +1.
                                                    F3 вообще огонь.
                                                    Ответить
                                                    • а можно выделить памяти под икран * 50, и читать просто кусками из файла?
                                                      Ответить
                                                      • Да, примерно так редакторы для крупных файлов и работают.
                                                        Ответить
                                        • именно по этому я за вим
                                          Ответить
                                  • О, MSDN на трех CD... Помню, купил диск с Visual Studio 6.0 и еще кучей всего, включая WinRAR - потом пришлось в магазин возвращать, извините, там хелпы почему-то не работают. Привык, что в Borland C++ просто F1 нажимаешь и enjoy. Диск поменяли, а там то же самое T_T. Потом разобрался... Но баттхерт был, что документация в три раза дороже самой программы!
                                    Ответить
                                    • > MSDN
                                      > на трех CD
                                      Да у нас же тут инторнет-консервы!
                                      Ответить
                              • Кстати, про ngen: есть экзешник, а есть служба.

                                Если постоянно запущена служба «Microsoft .NET Framework NGEN v4.0.30319_X86» (она же clr_optimization_что-то-там), то всё тупит и вечно мало свободной памяти.

                                Всё работает намного быстрее, если выключить эту службу и вручную отправлять команду «ngen update» после установки программ. Тогда ресурсы будут потрачены только на перекомпиляцию новых модулей.
                                Ответить
                                • > постоянно запущена служба «Microsoft .NET Framework NGEN v4.0.30319_X86»

                                  Так и в жабе тоже какая-то служба под винду была.
                                  Java Quick Runner или Java Starter, что-то такое.
                                  Ответить
                  • >При этом это знание можно получить на уровне компиляции, и избавить JIT от ненужной работы

                    Зачем? Зачем?

                    Какие знания?

                    А если новую реализацию класса подгрузят класслоадером?
                    А если cglib сгенерит новый класс на лету?
                    А если просто подложат jar с классом-наследником?

                    Если класс не финальный нельзя делать такие допущения.
                    Ответить
                    • >Какие знания?
                      Знания о том, что финальный метод класса не может быть переопределен.

                      >А если новую реализацию грузят класслоадером?
                      Валидный кейс. А что сделает джит со своим инлайном? Выкинет?

                      >Если класс не финальный нельзя делать такие допущения.
                      Окей, пусть бы это работало только для финального класса. Но ведь и для него нет специальной инструкции.

                      С другой стороны финальность класса могут поменять, и тогда получится что надо перекомпилировать клиента: ABI сломается
                      Ответить
                      • > пусть бы это работало только для финального класса. Но ведь и для него нет специальной инструкции.

                        invokespecial недостаточно специальна?
                        Ответить
                        • >invokespecial недостаточно специальна?
                          public final class Foo {
                          
                              final void doAll() {
                          
                              }
                          
                              public static void main(String[] args) {
                                  new Foo().doAll();
                              }
                          }


                          7: invokevirtual #4                  // Method doAll:()V
                          Ответить
                          • Проверил, свежие версии явы даже приваты компилят как invokevirtual.
                            Интересно.

                            А старые версии javac вроде как превращали private final в invokespecial.

                            По крайней мере в JLS раньше так и писали
                            https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html
                            invokespecial

                            Invoke instance method; special handling for superclass, private, and instance initialization method invocations

                            Ответить
                            • Интересно, почему так сделали?
                              Ответить
                              • Хз. Может HotSpot настолько по-царски питумизирует invokevirtual, что нужда в чём-то другом просто отпала.

                                Но раньше там целое объяснение было почему именно invokespecial на приватных методах.

                                class Pituz {
                                
                                    private void foo() {
                                        System.out.println("1");
                                    }
                                
                                    void print() {
                                        foo(); //invokespecial Pituz::foo
                                    }
                                }
                                
                                class FloatPituz extends Pituz {
                                
                                    void foo() {
                                        System.out.println("1.0f");
                                    }
                                
                                    public static void main(String args[]) {
                                        FloatPituz float = new FloatPituz();
                                        float.print();
                                    }
                                }
                                Ответить
                                • внезапно котлин умеет в invokespecial
                                  class Foo {
                                      private fun buz() {
                                          print("A")
                                      }
                                  
                                      fun bar() {
                                          Foo().buz()
                                      }
                                  }


                                  7: invokespecial #28                 // Method buz:()V


                                  Но стоит снять private, как станет invokevirtual
                                  Ответить
                                  • Вот раньше так себя и ява вела.

                                    Блять, вот как же я люблю оракл. Ссылка на баг, почему они поменяли invokespecial на invokevirtual

                                    https://bugs.java.com/bugdatabase/view_bug.do?bug_id=7160765
                                    Ответить
                                  • Это кстати стало источником багров. Oracle похеру на обратную совместимость.

                                    https://blog.overops.com/oracles-latest-java-8-update-broke-your-tools-how-did-it-happen/
                                    Ответить
                              • Нашёл. В 8ой яве это убрали.
                                Я же точно помню, что раньше private превращался в invokespecial.

                                Release 8u20

                                Area: Specification / vm and HotSpot
                                Standard/Platform: Java SE 8
                                Synopsis: The verification of invokespecial instructions has been tightened so that only an instance initialization method in the current class or its direct superclass may be invoked.
                                RFE: 7160765

                                https://docs.oracle.com/javase/8/docs/technotes/guides/vm/enhancements-8.html
                                Ответить
                    • > Зачем? Зачем?

                      Действительно, зачем нам писать нормальный байткод?
                      Ответить
                    • > А если новую реализацию класса подгрузят класслоадером?
                      > А если cglib сгенерит новый класс на лету?

                      Пусть жит с этим и разбирается. Со стороны байткода никаких проблем нет.
                      Ответить
            • > А в «PHP» даже обычные функции ищутся в глобальной таблице функций по имени. Так что в «PHP» можно не думать о способах вызова подпрограмм, потому что всегда будет хуёво.

              Там еще и статика вынуждена каждый раз искать вызываемый метод. Какой late static binding )))
              Ответить
    • Куклы Petooz с птичками Chou Chou
      https://v3toys.ru/index.php?nid=88390
      Ответить
    • Переведите на функциональщину, JAVA SCRIPT или HASKELL
      Ответить

    Добавить комментарий