491–500 of 553 posts
Earlier quoted context omitted.
Another one that hasn't seen UNIX scripting in shell languages or Perl, Apache modules, before Python came to be.
I wrote tons of perl in my life. I would rather keep writing perl than touching python. Every time I see a nice utility and see that it's written in python - tab closed.
Earlier quoted context omitted.
The only trouble is C packages, which are really really common, right? So you have a performance hit or something (or so I heard) I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy
In my experience, pypy works with basically everything these days. I remember having some struggles with a weird fortran based extension module a few years ago, but it might work now too. Most c extension modules should work in pypy, there's just a performance hit depending on how they're built (cffi is the most compatible). https://doc.pypy.org/en/latest/faq.html#do-c-extension-modul...
People wanting to use Pypy usually do so because they want better performance. Having a performance hit while using pypy is disconcerting.
I was speculating that in the future, C extensions in pypy would be faster, but I now see that the GIL is actually unrelated to this performance hit. Anyway it's really a pity.
Earlier quoted context omitted.
Isn't CL a good counter-example to that "dynamism inherently stunts performances" mantra?
To the contrary. In CL some flexibility was given up (compared to other LISP dialects) in favor of enabling optimizing compilers, e.g. the standard symbols cannot be reassigned (also preserving the sanity of human readers). CL also offers what some now call 'gradual typing', i.e. optional type declarations. And remaining flexibility, e.g. around the OO support, limits how well the compiler can optimize the code.
Earlier quoted context omitted.
5.5% compounded over 5 years is a bit over 30%: not a huge amount but an easily noticeable speed-up. What were you thinking of when you typed “significantly faster”?
Compunding a decrease works differently than an increase. If something gets 10% faster twice it actually got 19% faster. In other words, the runtime is 90% of 90%, i.e. 81%.
Earlier quoted context omitted.
double click selection issue. 0m0,031s vs 0m0,013s. > I don't know how you write your scripts, You know how… I put print hello world in them… that was the test you asked for? > premature optimization Not using something that has 3x startup time, for a short lived command is just "common sense". I'm starting to think that the issue here is that you know java but don't know python or C, and you are unconsciously trying…
I haven't written Java as my day to day for about 5 years. Instead I write... Python :-) It's just that I recognize disingenuous comments. Java is perfectly adequate as a language for writing command line tools. You're likely using one of them weekly and don't even know it. Just don't write your Java CLIs using Spring or DI frameworks in general :-)
doubtful, since I don't have jre installed. I had to install it just to run that benchmark.
What is it really JIT-ing? Given it says that it's only relevant for those building CPython. So it's not JIT-ing my Python code, right? And the interpreter is in C. So what is it JIT-ing? Or am I misunderstanding something? > A copy-and-patch JIT only requires the LLVM JIT tools be installed on the machine where CPython is compiled from source, and for most people that means the machines of the CI that builds and pac…
Code fragments that implement each opcode in the core interpreter loop are additionally compiled in the way that each fragment is compiled into a relocatable binary. Once processed in that way, the runtime code generator can join required fragments by patching relocations, essentially doing the job of dynamic linkers. So it is compiling your Python code, but the compiled result is composed of pre-baked fragments with…
Earlier quoted context omitted.
Pypy actually works really well. It could probably get even farther if people knew about it more. Test your packages on Pypy, people.
The only trouble is C packages, which are really really common, right? So you have a performance hit or something (or so I heard) I guess that now the GIL is going away, pypy will become better at handling packages with native code like numpy
Now, a lot of C packages work - and where they don't it's worth raising bugs: with PyPy, but also in the downstream program - occasionally they can use something else if it looks like the fix will take a while.