Topic: 0.3 almost ready -- please test the Mac version! (Read 24958 times)
Currently the code is heavily little endian so it is not just a recompile to support PPC unfortunately. I wanted to try working on a big endian patch but I couldn't really find a good enough reason to
Laszlo's build is going to be our first Mac release so please test it!
I wish I could 
It's an Intel Arch release only, doesn't support PPC yet/will?
It sounds like the slow block downloading is a problem for some people but not others, regardless of the platform.. I will try to look into it more, thanks for the report.
Downloaded 0.3 for OSX, have to report it's not working very well, the hard disk goes crazy (so much so you can't really open any other apps, unless you want to wait 5 minutes) and it downloads blocks extremely slowly, took me about 4hrs to download 20k before I gave up. The windows one on similar hardware works 10x faster and I had all 66k done in 15-20mins I think it was.
On intel iMac 10.6.4 i5 4gb ram. Oh and it quite often crashes when you quit, is it just me having these problems?
Have tried wiping the database and reinstalling the app with no change.
On intel iMac 10.6.4 i5 4gb ram. Oh and it quite often crashes when you quit, is it just me having these problems?
Have tried wiping the database and reinstalling the app with no change.
I'm running rc4 on xp32/64 and everything seems ok so far,
installed without problems, ~50connections on a forwarded node, 8 on others,
limited to 1(of2) and 1-2(of3) cores, which scales up nicely, but hasnt generated any coins yet.
Hopefully i'll get some tonight.
installed without problems, ~50connections on a forwarded node, 8 on others,
limited to 1(of2) and 1-2(of3) cores, which scales up nicely, but hasnt generated any coins yet.
Hopefully i'll get some tonight.
Laszlo's build is going to be our first Mac release so please test it!
Mac OS version - requires Intel processor and 10.5 (10.4 not supported)
http://heliacal.net/~solar/bitcoin/builds/MacOSX-Intel-0.3/bitcoin-0.3.0.zip
http://heliacal.net/~solar/bitcoin/builds/MacOSX-Intel-0.3/bitcoin-0.3.0.zip
(reverted to rc2)
Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it.
Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it.
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
It is, but generating is more than twice as slow. MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
Maybe best to look at the 4.4.3 compiled disassembly as well and see if there are any differences.
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
Dimitri
MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
I'm not sure why but I noticed that as well - my Win32 build was a lot slower than the linux/mac builds I did. I used MinGW and all that but maybe I made a mistake somewhere.. I probably used a different version of Berkeley DB than Satoshi too so that's why the logs weren't binary compatible.
Changed the version number to 1.3 and removed "Beta".
(links removed, see below)
Uses irc.lfnet.org.
(links removed, see below)
Uses irc.lfnet.org.
The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.
It looks good! The number of hashes per second intermittently disappears for a few seconds at a time. I think it might be triggered by clicking on the file menu multiple times. I'm using the Linux 64-bit build.
Lets try using Laszlo's irc.lfnet.org instead of freenode. Here's RC2, that's the only change in it:
(see below for download links)
(see below for download links)
Thanks virtualcoin, that's a perfect comparison.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.
But look here:
32-bit Linux version on Ubuntu 10.04
4 cores: 2500 khash/s
3 cores: 1900 khash/s
2 cores: 1260 khash/s
1 core: 630 khash/s
64-bit Linux version on Ubuntu 10.04 (new measure)
4 cores: 2880 khash/s
3 cores: 2150 khash/s
2 cores: 1450 khash/s
1 core: 720 khash/s
(Though I never created one coin, yet - but I don't let bitcoin run on 4 cores the whole day, not even on 1 core...)
@Joozero - The Intel i7 860 is @ 2.8 Ghz, isn't it? My Phenom II is @ 3 Ghz, that's another important fact I think. I will try bitcoin on Windows 7 at the same machine later.
/edit
32-bit Win version on Windows 7 64-bit
4 cores: 2310 khash/s
3 cores: 1740 khash/s
2 cores: 1160 khash/s
1 core: 580 khash/s
Linux on an overclocked Pentium D:
- 1 core: 565 khash/s, 1.01 kW h/day
- 2 cores: 1100 khash/s, 1.78 kW h/day
The new version seems to give me an improvement of 20-30 khash/s (with two cores) over SVN 80 with laszlo's patch.
Does anyone know what I have to change in the makefile so that I don't have to add LD_LIBRARY_PATH pointing to the dependency libraries when executing BitCoin? I already have -I and -L pointing to the single, correct location. (This isn't caused by the new version; I've always had this problem.)
- 1 core: 565 khash/s, 1.01 kW h/day
- 2 cores: 1100 khash/s, 1.78 kW h/day
The new version seems to give me an improvement of 20-30 khash/s (with two cores) over SVN 80 with laszlo's patch.
Does anyone know what I have to change in the makefile so that I don't have to add LD_LIBRARY_PATH pointing to the dependency libraries when executing BitCoin? I already have -I and -L pointing to the single, correct location. (This isn't caused by the new version; I've always had this problem.)
Jump to: