Hi
Generally I'm factoring numbers that I can do in less than a day, so in the
order of 60 to 100 decimal digits.
JT
On Monday, July 17, 2017 at 4:02:29 PM UTC+2, Jan Mercl wrote:
>
> On Mon, Jul 17, 2017 at 3:57 PM Jeff Templon <jeff.temp...@gmail.com
> > wrote:
&g
Coming back to this, now that my Go knowledge is increasing:
On Saturday, July 8, 2017 at 5:58:59 PM UTC+2, Andy Balholm wrote:
>
> I noticed your “naive explanation” after I sent my message. But I think it
> is the real explanation.
>
it turns out that 77% of the time of the program is spent
Hi,
On Friday, July 7, 2017 at 6:48:01 PM UTC+2, Andy Balholm wrote:
>
> That’s normal for languages like Python. The code that is actually running
> in Python is slow, but library functions are fast, because they are written
> in C.
>
Sure ... that's why I wrote the 'naive explanation' that
disappeared,
resulting in a bit more than 10% overall performance improvement in the
entire code. Now I understand better the comments about reuse of arguments
in the math/big documentation! Thanks for your suggestion.
On Tuesday, July 18, 2017 at 9:09:54 AM UTC+2, Jeff Templon wrote:
>
&
Hi Remy,
On Monday, July 17, 2017 at 10:39:56 PM UTC+2, Rémy Oudompheng wrote:
>
> 2017-07-17 15:56 GMT+02:00 Jeff Templon <jeff.temp...@gmail.com
> >:
>
> > it turns out that 77% of the time of the program is spent in
> > runtime.mallocgc :-) I thin
One more bit of progress which shaved off more time: following this page,
https://blog.golang.org/profiling-go-programs
I introduced a pair of global cache big.Int variables for the function
which was consuming most of the time; one for the smaller intermediate
results and one for the
I managed to do quite a bit better (30% savings in execution time)
proceeding along these lines. Finally I got to the point where
runtime.makeslice, and underneath runtime.mallocgc, are responsible for 50%
of the run time, with no other real hotspots. Almost all of the makeslice
time is
Hi
A followup message ... I managed to increase the speed of my little prime
factorization program by a bit more than a factor of two, the performance
win is hardware-dependent.
After I learned how to profile the code, I discovered a few things:
- 70% of the time was taken in
Hi
Exploring Go, 1st project is to port over my favourite playground (prime
number factorisation) from Python to Go.
Aside: I was a big Oberon-2 fan back in the day, so I'm pretty excited
about Go making possible what never was in Oberon.
Back to business: I was disappointed that Go is only
