Shareaza

by **raspopov** » 21 Nov 2009 14:59

What do you think about dropping support of old non-SSE processors i.e. Intel Pentium Pro, Pentium II, AMD Athlon (without XP)? So we would use fast float-point routines and SSE-optimization.

by **diztrancer** » 21 Nov 2009 15:12

Goodbay my Celeron 633Mgz

Use both optimised and not-oprimised routines ?

And is there already SHA1 calulating in x64 assembler ?

by **old_death** » 21 Nov 2009 15:22

Not a bad idea, but only if we can present a bug-free version of Shareaza for those still using these processors. This means +1 from my side after at least v2.5.1.0 has been released and there are no more error reports flooding your SF mailbox.

by **ocexyz** » 21 Nov 2009 15:33

Would be good to know how many users use this kind of hardware?

by **raspopov** » 21 Nov 2009 16:09

by **diztrancer** » 21 Nov 2009 16:20

AMD Athlon also support this.
But anyway - non-MMX must be dropped.

by **raspopov** » 21 Nov 2009 16:33

by **kevogod** » 21 Nov 2009 17:04

How much would Shareaza really benefit from this though?

by **ocexyz** » 21 Nov 2009 17:09

To estimate consquences should be known what number (or %) of users use such harware and what number (or %) of files are shared by those who will be excluded. If 5-10% would be lost then perhaps this would be cost of progress, but if 5-10% only would stay in network in the effect of this then it would be ignoring users.
W/o info this it is not decision making but just taking risk counting on some advatages/benefits of such a decision.
And how other projects of this kind do?

by **ocexyz** » 21 Nov 2009 17:42

by **mojo85** » 22 Nov 2009 05:59

No point in doing this. Those who need a system optimized for their PC can freely compile it themselves ... the complications arising from someone making a post and us doing all sorts of tests to find out they couldn't install because of a processor is not worth the time. In terms of cutting edge speed optimizations it must be the core code the gives the gains not the compiled code that would require a system specific setup.

No added benefit.

by **raspopov** » 22 Nov 2009 10:14

Yeah, but there are no old processors left in the world. So no point in not doing that.

by **old_death** » 22 Nov 2009 10:51

Well, that's not true, there are still some left. But anything prior to Pentium III or a comparable AMD system could not run Shareaza anyway as it simply needs too much CPU res.

by **ocexyz** » 22 Nov 2009 12:56

by **ocexyz** » 22 Nov 2009 13:15

by **old_death** » 22 Nov 2009 16:23

by **ocexyz** » 23 Nov 2009 00:57

Twice bigger installer does not disturb. It can be applied to 64 I think w/o problems even now, but not w/o to 32 IMHO.
This is also question of prices of new staff and how quick older staff will die physically. Nowadays hardware is really less durable I think, but older just more.

by **ailurophobe** » 24 Nov 2009 19:45

I think it would be good to have SSE optimized hashing. The correct way to do this would probably be to have an object that does hashing with a virtual function for hashing. Then on Shareaza start you would initialize this to the correct sub-class of the abstract hashing base class that implements the virtual function. Like "Hashing_with_x86", "Hashing_with_MMX", "Hashing_with_SSE","Hashing_with_SSE2", and so on. This would be more work, but it would avoid all compatibility problems. You could have as many optimized versions of the hashing functions as you wanted without dropping support for older hardware for the cost of some initialization logic and a virtual function redirect.

But pre-SSE CPUs are probably already lost to us since we dropped Win 9X/ME support, so doing a direct replace is fine with me.

by **old_death** » 03 Dec 2009 10:05

by **raspopov** » 03 Dec 2009 18:10

SSE/SSE2 supported only for 32-bit builds.

BTW I mistakenly commited SSE-path... so current 2.5.1.0 is SSE-enabled... :oops:

by **punkmaister** » 10 Dec 2009 21:05

Is the Intel Celeron E1200 @ 1.60 GH fast and compatible enough?
:?:

by **brov** » 10 Dec 2009 22:01

IIRC yes it is.

by **old_death** » 11 Dec 2009 12:42

http://www.google.de/search?client=oper ... 8&oe=utf-8
Yes, it is.

by **ailurophobe** » 15 Dec 2009 22:58

How about SSE for 32bit and SSE 2 for 64bit? If raspopov already accidentally committed SSE and nobody noticed for a long time, seems like there is no reason not to.

by **rolandas** » 18 Dec 2009 20:08

IMO, it should be dropped. Nowadays, you can not even watch youtube clips without SSE, Adobe dropped the support from Flash Players (actually, it works but I can not call it as functional), Microsodt dropped it's support too for the SilverLight technology. If Shareaza was a portable application, which means allowing it install into devices, then there would be problems.
Can you guys give any examples, when Shareaza is run on such old PC's? Everyone even can buy a processor with SSE from ebay just for $15.

by **mojo85** » 18 Dec 2009 20:39

Hey rolandas nice to see you, this has been done now ... but duly noted and I concede my original hesitation.

by **ocexyz** » 18 Dec 2009 21:42

by **rolandas** » 18 Dec 2009 21:56

by **old_death** » 27 Jan 2010 14:58

by **bosanek** » 30 Jan 2010 14:28

Read this topic to see an example of a user who got affected by the SSE revolution:
viewtopic.php?f=7&t=520&p=3419#p3419

And it wasn't only me, but also at least five of my friends.

by **cyko_01** » 06 Feb 2010 17:39

I noticed that rev.8461 enables SSE2 correct? If I am not mistaken that would also eliminate all PIII processors which I think is a big mistake since it is very plausable that they are still in use and running an appropriate OS for shareaza (perhaps as a P2P sharing server). Raspopov, please explain yourself.

by **raspopov** » 06 Feb 2010 17:54

After two month of unexpected SSE1 testing I prefer to release two versions of Shareaza: 1) Blend version (default at download page) for all processors; 2) Optional SSE2-optimized version for Intel Pentium 4, AMD Athlon 64 and above processors.

P.S. Daily builds will be blend also.

by **old_death** » 06 Feb 2010 18:01

by **raspopov** » 06 Feb 2010 18:18

MS Visual Studio 2008 produces too slow 64-bit code for Hash library, so we can try to compile it with Intel C++ Compiler (I have no license for it) or preferred way is to manually convert 32-bit assembler routines to 64-bit.

by **old_death** » 06 Feb 2010 22:46

by **ailurophobe** » 07 Feb 2010 01:47

If someone will compile the 64 bit hash functions with Intel compiler they should also compile versions for different SSE versions in 32 bit and then add wrapper code so Shareaza maps hashing to the correct version. I am curious if it makes a difference in performance.

by **cyko_01** » 07 Feb 2010 01:57

by **kevogod** » 07 Feb 2010 03:14

I doubt even using the Intel compiler for 64-bit HashLib would result in better performance than the hand optimized 32-bit assembly code.

by **raspopov** » 07 Feb 2010 07:33

That why I long time ago added HashTest utility, use it to compare performance with various compilation options.

by **ailurophobe** » 07 Feb 2010 12:52

So you have numbers on how MMX, SSE, and SSE2 versions compare? I am just curious, so a rough estimate would be more than sufficient.

Shareaza

Who is online