In most cases, I think it’s better to mask heated but legal posts with a moderator note and allow expand-to-view. Then, give the authors time to edit their posts, with one-click moderator approval instead of an instant re-flag. This approach may help avoid alienating grown adults from the community.
I’m very sorry, this is outside my scope. :- )
Head up. :- )
My suggestion:
-
Restrict all general discussions about AI/LLM to one specific topic in Offtopic. General in this context means “not related to a particular package or concrete problem, event, or announcement”. (The opening post of this topic would not be general, it is about a specific announcement.)
-
Modify the forum guidelines to reflect this, and encourage the users to report violations. Maybe add a specific flag too?
-
Moderators move all generic posts and their replies to this one particular topic. No hard feelings, no censorship.
Have you tried JET.jl on the old code to see if it can catch the type stability? You probably know it, but there are well-known type stability pitfalls with IO, e.g. Base.stdout being type-unstable.
In fact, that’s is why it is so difficult to work with PrettyTables.jl. What improved the performance was not a type-instability that was removed, but one that was introduced. Hence, the difficulty to find it. In the previous code, the JIT needed to compile something in many cases, leading to a slow down when the type is new. By making a specific function type unstable, the precompilation takes care of a sane default and the printing happens without this step. The print itself is slower, but unnoticeable given the printing bottleneck, but the removal of the precompilation step leads to a significant usage gain.
The vast majority of time I worked in PrettyTables.jl was trying to find which instability I can introduce without harming too much other parts. Fable 5 found specifically one (of course, I told it what I wanted) that improved a lot without any measurable side effect.
That’s so nice to see! Thanks! AWESOME website by the way! When I applied to this subscription, I used the information in https://juliapkgstats.com, but it seems outdated (last update was in July).
Oh that sounds interesting. Can you tell us more? Sometimes we think simple and perfect is best but it is not. Golf balls are not nice little spheres, they have dimples. Would like to know how your “dimple” works, and why.
Congrats, Ronis! Your work is amazing, don’t let the negative comments get you down or make you give up, greetings from Brazil.
I will try!
For example, if I remove all type instabilities, make Julia run as fast as possible, and precompile usual values, Julia will be able to print a Matrix{Int64} very fast with default configuration. However, if someone pass something slight different, like Matrix{Int32} or different customizations that is not precompiled, it will take a long time because the compiler will need to recompile the functions for this new type or configuration.
Hence, what we do is to transform that input data into a common type (like Matrix{String}), as fast as possible so that everything after that is already precompiled. However, since the amount of customizations you can do with PrettyTables.jl is very large, it is almost impossible to do this every time.
The solution was to suspend the compilation using @nospecialize so that the compiler does not recompile a method for a more specific type. For example, there is functions in which the input is a data::Any and it will not recompile it in any circumstance.
The conclusion is: those functions will run really slow, but since we are print tables, it does not matter if a printing functions takes 0,2 ms or 2 ms. Hence, I am in an eternal battle between make functions not specialize vs the output generation performance.
Thank you. Definitely interesting.
FYI, I also got the same reward for maintaining DifferentiationInterface.jl, which is less popular than PrettyTables.jl. Worth applying even if your package isn’t one of the top ones!