SoB! Macintosh Client. 17oB!

[Death]

Yeah.

Really want one of this.

G5 can make a very large difference. Or 10 G5. :D

[Ken_g6[TA]]

Feel free to write one! :D

http://glucas.sourceforge.net/ would seem to be a good place for you (or any such author) to get started.

[Death]

Originally posted by Ken_g6[TA]
Feel free to write one! :D

http://glucas.sourceforge.net/ would seem to be a good place for you (or any such author) to get started.

That's not funny. :bang:

Why do you think I ask???? :bonk:

If only I was programmer and knows a lot about Altivec and stuff, I can make a lot of money and better job....

[allio]

I think what Ken was getting at is that if you want a Macintosh client, you're going to have to do something about it yourself. The project admins have said before that it would require too much work for them to do it - the vast majority of the userbase use Windows and Linux - and any work done by the admins would probably be better spent on ironing out the bugs in those. If you, or someone else, want to work on a Mac client, I'm sure there'll be a great number of thankful people out there :)

[Death]

Originally posted by allio
I think what Ken was getting at is that if you want a Macintosh client, you're going to have to do something about it yourself. The project admins have said before that it would require too much work for them to do it - the vast majority of the userbase use Windows and Linux - and any work done by the admins would probably be better spent on ironing out the bugs in those. If you, or someone else, want to work on a Mac client, I'm sure there'll be a great number of thankful people out there :)

So sad that i know nothing about programming for Mac (same for PC =).

I can try a little, but is there source code for client? At least I can try to compile it.

But I know nothing about Altivec and specific Mac optimization, so it can not be so fast as PC client.

If you know about d.NET =) so you may know about situation that Mac client on 2000 MHz PPC is 10 times faster than P4 3060 MHz. I wish something like this for 17 of Bust!

[Ken_g6[TA]]

Actually, I was looking at that page I posted, and it looks like the FFT is entirely coded in C. This might mean you could compile it on an x86 for testing, and then be able to compile it on a Mac with few or no changes.

'Course, cross-platform compatibility is frequently like :trash: .

[rogue]

You could also try to contact the authors of glucas (or the authors of mlucas) about it. They wrote the code, so they should be most familiar with determining what it would take to modify it to do a PRP or primality test for numbers of other forms. I had asked the authors of glucas about using their FFT in PFGW. They had no problem in the code being used in PFGW, but they were not willing to integrate it. I would have done it myself as I do know a number of programming languages, but knowing how to program is not the problem. The problem is that one needs to have a strong knowledge of FFTs in order to do it, and I don't know enough to even start.

Another thing to know is that you need double precision floats in order to do a DWT. Altivec does not support doubles, so it is useless for DWTs. I'm certain that if it could be done, Richard Crandall and the Advanced Computation Group at Apple would have done it by now.

--Mark

[Death]

from previous year.

you might hearâ that MacOS X is FreeBSD based. you have bash, terminal, and other linux stuff on mAc.

so maybe somebody can compile linux sources for mac?

wrapper can a pain, but at least I want a core....

[Stricker]

i forget where i had read it (a while back) but they were saying that glucas was slower on the mac than it was on the pc and that it would be faster if you implemented a different algorithm altogether

[scrap]

:notworthy I want SoB client for my Alpha-NT !!! :notworthy

It gots native 64 bits integer and floating point registers :D


http://www.mrs.umn.edu/~hauckjj/sandbox/3401/alphaPages/images/alpha-21264.jpg

[Death]

http://images.apple.com/powermac/images/indexg506082004.jpg

That's BETTER!!

[scrap]

LOL ! :D :D

Same fight :cheers:

[Death]

actually Apple has now TWO processors at current macs...

:cheers:

[Death]

well havin almost the same discussion in a sieve thread, i wand to ask admins for source code for sob client.

I'm having now gcc 3.3 for mac os x and at least i can try to 'make' a client.
I believe that it can't be maked, cuz compiler shows a lot of warning and errors, but at least i can give a try.

my programming knowledge is too low, but if it works it can be a great improvement for SoB! community.

and also I want to know, who lend a mac for FatPhil to make a sieving client called Nbe_Gon_010_osx? he said that was some SoBer =), but he cant remember who...

i have a few q about nge_gon

[Stricker]

i'd be willing to help in the port process i have 2 friends w/ mac that have been wanting a client and glucas has the 970 sources on sourceforge (if i were to help i could only test on a dual g4 tho)

[royanee]

The problem is that the heavy lifting in the SoB client is done by x86 code. It'd be easier to emulate an x86 machine on a Mac than to port the code...

[Death]

bad bad bad

:cry:

[Stricker]

I was fairly certain that the code had been fully optimized for the x86 platorm but i wasn't 100% sure

[tqft]

rather than rewrite the assembler


link is to a quick and dirty google search - no warranty , no guarantee etc.
http://www.google.com.au/search?q=lucas+lehmer+test+c+code

someone else said sourceforge

compile it and see how fast it goes - ie how long a test takes

if you don't get within two orders of magnitude (one order of magnitude for assembler, one order of magnitude for optimization) of speed I don't think optimization will help

then look at lifting the prp code into the gui and wrapper code

if you get close without too much hard work, then why not just "publish" that to start with and find some ppc junkie to do the nasty assembler

[Death]

well, http://glukas.sf.net have all binaries that i need, so i havn't compile them...

they have ppc G4 and G5 versions. also they have source available.

but what I supposed to do with this binaries??

[Mystwalker]

I'm not sure if Glucas can test Proth numbers - haven't found anything on this. AFAI see it, only LLR is possible, which only works for Mersenne numbers.

[scrap]

What about running an emulator like qemu (http://fabrice.bellard.free.fr/qemu/) or bochs or wine ?

[Stricker]

i don't mean to sound mean but emulators are never going to be the answer to the problems faced w/ this project, no matter if it is SSE2 (see other thread) or the PPC architecture emulators add at least one step to the process which will slow down the overal performance the best option which will provide the best performance is to build/tweak the code for the architecture that the code will be run on, in this case it may even be better to avoid FFT (Fast Fourier Transform) altogether since the altivec processor which is on all g4 and newer macs is able to process 128-bit ints the drawback of FFT is it requires floats which are not possible on the altivec, i remember hearing about another prime calculation system that works only w/ ints but i forget what is called right now

[scrap]

the best option which will provide the best performance is to build/tweak the code for the architecture that the code will be run on

I know that, and I agree with you.
But AFAIK, there is no Mac port of the client. You should see an emulator as a temporary solution. I prefer computing via slow emulated SoB client than no computing at all.

[Stricker]

Originally posted by scrap
There is no Mac port of the client.
Right and that was the original point of this thread to discuss creating a port for the mac

You should see an emulator as a temporary solution. I prefer computing via slow emulated SoB client than no computing at all. if you want to use an emulator go ahead but the results are probably going to compare somewhere around a p2 or at best a slow p3 and at those speeds w/ the large numbers we are dealing with now it would almost be better to do seiving or something else

[larsivi]

Note that the win32 version of proth_sieve has been observed to be faster under Wine than in native Windows mode...

[Mystwalker]

Originally posted by larsivi
Note that the win32 version of proth_sieve has been observed to be faster under Wine than in native Windows mode...

Actually, the the Win32 version under Wine is faster than the Linux version. This could be due to different compilers used (maybe ICC for Win32 and GCC for Linux) and shows that there is next to no loss in this situation.
When it comes to emulating a completely distinct system architecture, things look different...



Originally posted by scrap
I prefer computing via slow emulated SoB client than no computing at all.

I'd prefer trading work with someone else - look for other people running "suboptimal" setups where Macs scream (like distributed.net). Then you can agree on a trade ratio and have a "win-win situation" *marketingLanguageOff* ;) .

[rogue]

Originally posted by Mystwalker
I'm not sure if Glucas can test Proth numbers - haven't found anything on this. AFAI see it, only LLR is possible, which only works for Mersenne numbers.

Glucas and its rival Mlucas can only test Mersenne's. You could suggest to the software authors to add support for Proths.

[Death]

little correction - http://gluCas.sf.net

and on a sf.net exist a compile farm.

maybe one can compile a client for mac on it?

http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1

[Death]

http://darwinports.opendarwin.org/ports/?by=name&substr=fft

FFT written on C for Darwin (Mac OS X core).

3 Portfiles Selected

djbfft 0.76
D.J. Bernstein's fast fourier transform library
Maintained by: [email protected]
Categories: math
Platforms: darwin


fftw 2.1.5
Fast C routines to compute the Discrete Fourier Transform
Maintained by: [email protected]
Categories: math devel
Platforms: darwin


fftw-3 3.0.1-fma
Fast C routines to compute the Discrete Fourier Transform
Maintained by: [email protected]
Categories: math
Platforms: darwin

[rogue]

Originally posted by Death
little correction - http://gluCas.sf.net

and on a sf.net exist a compile farm.

maybe one can compile a client for mac on it?

http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1

I have a compiled version (based in 2.9.2). I just need an e-mail to get it to you.

[Death]

Originally posted by rogue
I have a compiled version (based in 2.9.2). I just need an e-mail to get it to you.

version of what?
glucas? they have all versions on a site... or is this a modified version?

deadjdona _-_ gmail.com

[rogue]

I misunderstood. I thought you were looking for a build of Glucas, buf if I understand you correctly, you are looking for a build of Glucas that can do primality or PRP tests on Proths. That is a different matter entirely.

[Stricker]

i was just looking at the faq over on TeamPrimeRib's site when i saw the following quote:
"Porting the assembly routines of SB is no easy task... if it were, i would have done it already . I estimate that it would take an expert at least a few months to do it correctly. If you are interested in trying, grab the code from www.mersenne.org/gimps/source22.zip and port the asm files to whatever platform you can. If you port those routines (correctly), I'll release a non-x86 client. Good luck." and it was attributed to louie

[Mystwalker]

Originally posted by Stricker
and it was attributed to louie

I remember him saying this, yes. And this is definitely the point. The underlying math routines are hand-crafted x86 assembler. An emulation would be way slower. Only a manual and well-done port to another architecture's assembler language can keep up - unfortunately, it will take a long time until the code is as matured as GIMPS' is.
I think it's best to port proth_sieve, as AFAIK it doesn't rely that much on assembler code. Moreover, I just remember that there were earlier versions without assembler code in it. Maybe these can be easily ported to OSX computers - they should be written in C...

[Death]

well, if we forget about speed and other, how can I make a working client?
if it's written on C, I can compile it, and THEN we can check the speed.

[royanee]

Actually, if the emulator can spit out the correct assembly for the computer it is running on, wouldn't you be able to run the x86 asm through it and get the non-x86 asm output fairly easily? I mean, instead of sending the commands to the processor, sending them to a file? (I do understand that the program probably doesn't have that option, but am I too far off?)

[maddog1]

Having used emulators for almost any recent or older emulated system, I must say that I have never seen an emulator for any system having an option for what you describe (ie output assembly commands for the host machine in any format)
The furthest they will go is to integrate a debugger so you can see the original assembly code and even that is not THAT frequent.
Additionally, most emulators, especially for any advanced systems, don't interprete directly ASM commands of the emulated machine to the relevant opcode of the host (many times this is impossible). Instead, they use other tricks, which go beyond the scope of this forum. If you are interested in the tricks employed, take a look at the MAME source which is widely available.
So, IMHO, the idea of using an emulated system for SoB the way you describe is wide off scope and not going to happen anytime soon. Pity really...would be interesting :)

[Death]

well, why I can't use C sources. because of lack of them?

G5 64 bit PPC can use gcc optimizations and acquire a speed compared with P4

[Mystwalker]

Originally posted by Death
well, why I can't use C sources. because of lack of them?

(Assumption: You talk about the sieving code.)

Basically yes. I guess the sources still exist, but mklasson has them - and I haven't seen him for a long time. :(

edit:
Maybe here (http://www.rieselsieve.com/phpBB2/viewtopic.php?p=4206#4206) is something very helpful...

[Keroberts1]

That is very surprising to read. I assume those sieve rates he quotes were for the reisel sieve and not SOB what could we expect from the same improvements in SOB?

[ceselb]

I suppose I can talk a bit now, since it's been posted.

7-10 times faster for rieselsieve, should be the same for sob.

Remember that this isn't verified yet. It's in early alpha still. (It looks good, but something could change/ not work as it should)

[Death]

well, guys this it macintosh SOB client thread, macinotosh sieve client thread is here -
http://www.free-dc.org/forum/showthread.php?s=&threadid=7859

but who cares... I have a 7 g5 1600-1800MHz, and 15 g4 various.

ià one can make invisible installer (to avoid users questions) like dnet one, i can switch from ogr to sieve.
huh-huh just imagine....

[vjs]

ceselb,

Since you :sack: took the bag off in this forum I wanted to let you know, that I started sieving the 20m<n<80m dat file.

My rational was based on this logic (and I will take others quotes)

- The project will go beyond 20m
- The current dat file is updated regularly
- Factor density is decreasing
- We have a solid sieve base

It just doesn't make sence to me to only sieve to 20m, if later we will sieve from 20-40 and 40-60, then 60-80, the speed trade off isn't worth it, even with the faster computer, removed k argument. If we get faster clients great we can sieve deeper and the server space required to store the factors is really trivial.

I was thinking it would be time to start sieving to higher n's with the higher T's we are now seeing. How high I don't know and when to start is another question. I was thinking around the time we get to 1000T if not sooner, or once we find another prime.

With the elimination of 1k and an extension of the sieve range the speed decrease wouldn't be that great. So everything after that T (650T for example) could be completed with the new .dat file 1m<n<???m my thoughts were 60m but maybe 80m if we get a new client.

Others could then decide to do a new dual range of 20m<n<60/80m for everything below 650T for example when prp reaches ??? n=18m.

Regardless of the above this is what I've found.

I used Nuri's dat from the yahoo group, he stated that he had already sieved out the first 1G for each of the files he created.

The dat file was 22.4mb once extracted.

After sieving to ~150G with the cmov -u option the dat file has decreased in size to ~18.5m, the client is currently using <40mb of memory.

Inital speeds with proth cmov were anywhere between 10-20 kps for the first few G's but now they are holding stead around 370 kps and increasing slowly.

For comparison this machine a barton core with 1G of ram generally gets around 650 kps with the current dat and a 550T level.

So I have produced the following fact files,
fact.txt >27mb
factexcl.txt >210mb
factrange.txt >21mb

Dat now at ~18.5mb.

My thoughs are to simply remove the majority of the factors from 20m<n<80m incase we decide to extend the range, reduce the dat file size etc.

In any case if you'd like the fact.txt or sob.dat, file etc for testing purposes etc I can e-mail it to you or post it on a server etc.

I'll probably continue with this effort for a few more 100G, 1T max.

[Death]

do you try to submit them?

got to go, so we talk l8r. =)))

[vjs]

Death these are factors beyond 20m, surely anything less than 20m with a p<1T has been found already so it's not worth trying to submit.

Inaddition sieve is not accepting factors for n>20m, i.e. factrange.txt.

[ceselb]

Originally posted by Death
I have a 7 g5 1600-1800MHz, and 15 g4 various.

New client will work on macs too.

[Death]

vjs, but you CAN submit them =))

as for your sieving effort, my main pc is 1.7 cel with 512 mb ram and hardly working, so I can't use it. i got some user machines around, but since we haven't service installer, i don't want to bother myself. got to complete my reserved range =))

and maybe we must hear official word about this? so all sievers move in your direction.

please, create new topic about this, so we can talk about it.

and this is macintosh SOB client topic (I really need one) :cry:

ceselb, what client??? where??? gimme!!!!!

[ceselb]

Originally posted by Death
ceselb, what client??? where??? gimme!!!!!

It's not done yet, read the thread.

[vjs]

A couple fellow user seem to be intereseted in this topic, so I'm bringing the topic into the open here is my conversation with one of them.

Stop sieving 20m<n<100m imediately, Since you are over lapping my efforts from 20m<n<80m from 1G-25G (your current) to 150+G (where I am now).

I will also stop imediately or at some reasonable G I think I'm pretty close to 200G right now so I will stop at 200G.

Create a new *.dat from 80m<n<100m and sieve it from where you are to 200G, it should be pretty fast I can help with this part if you send me a 80-100 dat.

After that we can combine sieve efforts (with factor files???) and have everything sieved out from 20m<n<100m from 0G to 200G in one dat.

At this point we should consider what to do next...

1. Wait for the new client
2. Divide the sieve range 20m<n<60m and 60m<n<100m or 5 k's in one 6k's in the other etc.
3. Divide ranges...

Sobsieve as far as I can tell is alot slower than cmov on my machine and the 20m<n<100m file wouldn't work with cmov.

I didn't want nor have I, put alot of fire power behind this effort, just wanted to start the ball, but it seems as though there are alot of others also interested in the high range sieving and we are quite possibly duplicating efforts. I will post in the main forum at the request of Death, but I won't post names of people I have spoken with and contributed, it will be up to them to voice themselves.

Let's take it from here in the forums...

I'll start a new thread after the above converstaion is straightned out.

[ceselb]

I'd stop everything until we know how fast the new client will be.
I've talked alot with Chuck about it being able to start a new dat. It will have that functionality, just so you know.

If everything works out it will be a snap to make a new dat, if not well... just start from where you are now.

The client won't have the 2^52 limit either, so hold off on those ranges too.

[vjs]

ceselb,

I've talked with chuck as well and sent him all of my factors between 1G and 150G for 20m<n<80m. Another user is also sieving 20m<n<100m and has made it from 1m to 25G.

Chuck also sent me some suggestions, or things to try, double checking a small range etc.

So obviously I'm not the only one to do this and hope that everyone is not doing the same. I'm going to stop my sieve at 175G with the cmov -u option to further reduce my dat.

It's also been pointed out to me that the 20m<n<80m dat wasn't sieved between 1m and 1G... :bang: I must have misread Nuri's post.

Someone also e-mailed me regarding some programs that they have written to remove k/n pairs form the dat based on factors etc. Hopefully they will chime in.

In the mean time I will hold off on the sieving deeper, and we will unify the factors produced between 1m<p<175G from 20m<n<100m and see what happens with the new client.