in reply to Anyway to Have Strong-Like Typing

Perl is actually a very strongly typed language; the issue is that those types are scalar, array, and hash (plus some other fun ones that generally stay in the background). Scalars are essentially all strings with a bunch of magic around numerical data content (again, simplification). I think we've got a bit of an XY Problem - I think what you really want to know is how to heavily optimize some mathematical operations.

First, profile your code. Make sure the slow chunks really are where you think they are. I like Devel::NYTProf, particularly with its nytprofhtml utility. It makes drilling though profiles fast and easy.

Second, assuming the math is the slow part, I can think of two fairly easy solutions:

  1. PDL. From the docs:

    PDL is the Perl Data Language, a perl extension that is designed for scientific and bulk numeric data processing and display.
    I haven't used it, but depending on the math you want to do, it's probably the lowest overhead dive to get good performance.

  2. Inline::C. In this case, I have used it, and I like it a lot. However, it will require that you program in C in order to do your fast operations. It buys you ease in terms of getting the Perl code to call C.

You can't get something for nothing, but if you are doing heavy numerics in Perl, there is almost assuredly opportunity for growth.

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Replies are listed 'Best First'.
Re^2: Anyway to Have Strong-Like Typing
by jmmitc06 (Beadle) on Aug 13, 2014 at 04:35 UTC

    Thanks for the responses, I have seen Math::Integer before and have played with it.

    I have heavily profiled the code with NYTProf making improvements here and there for the last few months with a major rewrite the other day. The slow part is the math, mainly one nasty do { } while ( ) construct. I think that I've reached the limit of what I can optimize, this implementation is already a heavily optimized / rewrite of another algorithm, and my question was a long shot and curiosity. Normally, I wouldn't really bother optimizing it since it is "fast enough", but it's been a slow week at work lol. Yeah, I'll probably try an Inline::C implementation before a true C rewrite when the free time comes to do it.

    I do think it would be interesting if we could have access to strongly typing all the variable types in C when we need it, and the more easy to work with standard Perl types the rest of the time.

[reply]
      The slow part is the math, mainly one nasty do { } while ( ) construct.

      Post it. It often helps to have fresh eyes look at these things, and there are people around here that have unique ways of looking at code.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      I fully agree with BrowserUK's thought: for numeric processing, PDL is highly likely to be the best solution - both for actual numerical performance (in many cases it can automatically use multiple CPU cores "for free"), and for speed of development (the REPL, "perldl" or "pdl2", are genuinely quite fun to use).
[reply]

In Section Seekers of Perl Wisdom