SoB! Macintosh Client. 17oB!

[Death]

Yeah.

Really want one of this.

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

[Ken_g6[TA]]

Feel free to write one!

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!

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

That's not funny.

Why do you think I ask????

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 .

[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]

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

It gots native 64 bits integer and floating point registers

[Death]

That's BETTER!!

[scrap]

LOL !

Same fight

[Death]

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

[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

[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=lu...er+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/displa...762&group_id=1

[Death]

http://darwinports.opendarwin.org/po...ame&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: gwright@comcast.net
Categories: math
Platforms: darwin


fftw 2.1.5
Fast C routines to compute the Discrete Fourier Transform
Maintained by: blb@pobox.com
Categories: math devel
Platforms: darwin


fftw-3 3.0.1-fma
Fast C routines to compute the Discrete Fourier Transform
Maintained by: gwright@comcast.net
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/displa...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 is something very helpful...