find perl root and push lib modules path to @INC
Changes for 0.08 - 2024-04-14T21:45:49Z
- update tests to fix a cygwin reported error in cpan testers
locate a Perl module and it's version
Changes for 0.06
- add -l and -I parameters to add @INC paths
- fix -v vs -V with Getopt::Long (thanks Andreas Hadjiprocopis)
Prior releases of the 6.x line relied on Lexical::Types, which was a major performance pessimisation over the 5.x releases.
6.0.4 relies on a simple source filter instead, which restores performance levels back to expected levels.
More benchmarks added to the test suite validate the dependency changes.
submitted by /u/joesuf4
[link] [comments]
Tags helpers for HTML elements.
Changes for 0.11 - 2024-04-14T18:16:11+02:00
- Fix test for 'step' parameter on Windows.
HTTP/2 Dynamic Benchmarks (PHP vs. ModPerl2), 2024 edition.
I ram these about four years ago, and the time differentials were about the same then as now. Monolithic POSIX-threaded server architectures like mp2 + mpm_event will always dominate in low-latency/scalability HTTP/2 benchmarks because they leverage zero-copy in the runtime.
Anyways, sexy terminal graphs with smag to enjoy!
submitted by /u/joesuf4
[link] [comments]
 | Lessons learned: A) Performance freaks to stop using #rstat 's runif for random generation. The Hoshiro random number generator arxiv.org/abs/1805.01407 is 10x faster. Implementations in #perl 's #PDL, #rstats (dqrng) and #python #numpy are within 20% of each other B) But does it make a difference in applications? To get to the bottom of this, I coded a truncated random variate generator in #rstats and #perl using #pdl (as well as standard u/perl) using the #GSL packages metacpan.org/pod/PDL::GSL::CDF & metacpan.org/pod/Math::GSL for accessing the CDF & quantile functions. In this context, it's the calculation of the #CDF that is the computationally intensive part, not the drawing of the random number itself. C) I should probably blog about these experiments at some point. Note that #pdl (but not base #perl) are rather competitive choices for large array processing with numerical operations. I mostly stay away of #python , but would not surprise me that for compute intensive stuff (where the heavy duty work is done in C/C++), it does not matter (much) which high level language one uses to build data applications preview.redd.it/qn00sx78gbuc1.… preview.redd.it/4by4jbh9gbuc1.… submitted by /u/ReplacementSlight413 |
