Raspberry Pi

[xilman]

Originally Posted by ET_

Did you also test PI with multiple instances of gmp-ecm? I suspect that a memory bottleneck may appear sooner there .

Working on it now. To be precise, I'm running four ecmclients with each restricted to 200M memory.

[Gordon]

Originally Posted by xilman

Working on it now. To be precise, I'm running four ecmclients with each restricted to 200M memory.

Originally Posted by xilman

Working on it now. To be precise, I'm running four ecmclients with each restricted to 200M memory.

No good for M4007 then, just ran a curve with B1=2900M and B2=enormous (12E14), only needed 325Gb...

[Dubslow]

The time of the first post in this thread is very interesting. I did not know that the mods had the power to set time (with my time zone adjustment, it looks like negative time!)

[xilman]

Originally Posted by Dubslow

The time of the first post in this thread is very interesting. I did not know that the mods had the power to set time (with my time zone adjustment, it looks like negative time!)

Mods don't. I asked Xyzzy to set the date to be earlier than any other post in the thread. The thread was created by moving earlier posts from the Happy Me thread.

[Dubslow]

Originally Posted by xilman

Mods don't. I asked Xyzzy to set the date to be earlier than any other post in the thread.

Aha, the magical super being has once again made his presence known.

Carry on as if I hadn't distracted everyone!

[Xyzzy]

The date (in the database) is represented as the number of seconds since the Unix Epoch. We set it to "0". For some reason, it displays wrong.

[xilman]

Originally Posted by Xyzzy

The date (in the database) is represented as the number of seconds since the Unix Epoch. We set it to "0". For some reason, it displays wrong.

The reason is actually quite clear and Dubslow has it right. It's a timezone issue.

In my timezone it displays as 00:00 1st January 1970 because I'm in UTC and that is indeed the time of the epoch.

Set it any time after, say, 1,000,000 seconds and the value should display as a positive time because 1M seconds is over 11 days after the epoch and way beyond any timezone settings.

[Mark Rose]

Originally Posted by Xyzzy

The date (in the database) is represented as the number of seconds since the Unix Epoch. We set it to "0". For some reason, it displays wrong.

Why not use http://unixtimestamp.com and pick something more reasonable like 1476403200?

[Dubslow]

For me it displays as 1969-12-31, 1900, which combined with my UTC-5 immediately made it obvious (to e.g. me and xilman at least) what the date storage format is.

Originally Posted by Mark Rose

Why not use http://unixtimestamp.com and pick something more reasonable like 1476403200?

I vote for something more fun, possibly something that still predates the forum founding https://en.wikipedia.org/wiki/Unix_t...s_in_Unix_time One such possibility is the billenium, or maybe 314159265 or 271828183.

[ET_]

Originally Posted by xilman

Working on it now. To be precise, I'm running four ecmclients with each restricted to 200M memory.

Any memory bottleneck discovered?

Another question, if I may... the site gmplib.org here says its ARM branch is tuned for the cortex-A15platform: are there projects to develop for the PI 3 cortex-A53?

[ldesnogu]

Originally Posted by ET_

Another question, if I may... the site gmplib.org here says its ARM branch is tuned for the cortex-A15platform: are there projects to develop for the PI 3 cortex-A53?

That page is obsolete, look at the date: "Last modified: 2014-08-22".

64-bit is now supported:
https://gmplib.org/repo/gmp/file/tip/mpn/arm64

OTOH it seems Cortex-A53 is slower than A15:
https://gmplib.org/gmpbench.html